Safeguard
Vulnerability Analysis•

CVE-2026-27953: High Validation Bypass in ormar ORM for Python

CVE-2026-27953 lets a crafted JSON body skip field validation in ormar 0.23.0 and below. Upgrade to 0.23.1 and use separate request models in FastAPI.

Safeguard Security Team
5 min read

CVE-2026-27953 is a high severity validation bypass (CVSS 7.1) in ormar, an async mini ORM for Python. In versions 0.23.0 and below, a crafted JSON request body can skip field validation and persist unvalidated data. Upgrade to 0.23.1. The record does not mark it as exploited in the wild.

What's affected

ormar, the PyPI package, versions 0.23.0 and below. The fixed version is 0.23.1, per the record and the project's release notes.

The record says the issue affects ormar's canonical FastAPI integration pattern, where an ormar.Model class is used directly as a request body parameter. Applications written that way, as shown in the project's documentation, are the ones to check.

How to check if you're exposed

Find the installed version and look for the pattern.

pip show ormar
pip freeze | grep -i ormar

Then search your FastAPI route handlers for functions that take an ormar model class as the body parameter. Those are the exposed endpoints. Handlers that take a separate Pydantic model and copy fields into an ormar model are less exposed.

Check lockfiles, requirements files and container images as well.

What to do now

  1. Upgrade ormar to 0.23.1 or later.
  2. Review route handlers that use an ormar model directly as a request body and switch them to a dedicated request schema where you can.
  3. Check stored data written by those endpoints for fields that should have failed validation, such as empty emails or roles.
  4. Add database level constraints for values that must never be empty or out of range.
  5. Scan your Python dependencies for other outdated packages at https://gold.safeguard.sh/scan.

Why it matters

The record says the model constructor accepts internal control parameters from a JSON body. Supplying them lets a caller skip Pydantic validation and persist data directly, and a second internal parameter can null out chosen fields such as email or role. The result can be privilege escalation, broken data integrity and bypassed business logic. NVD classifies the flaw as CWE-20 (Improper Input Validation) and CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes).

The lesson is about mass assignment. A request body should map to a schema that lists exactly the fields a client may set. Using a database model as that schema makes every constructor argument part of your public API.

What mass assignment looks like in a Python API

FastAPI and Pydantic make it easy to declare a request body as a class. The convenient move is to reuse the database model as the request body. The record says ormar's own documented FastAPI pattern does exactly that, and that the model constructor accepted internal control parameters from the JSON body. Those parameters let a caller skip field validation or blank out fields such as email or role.

The fix in 0.23.1 closes the constructor path. The design lesson still stands. A request schema should list the fields a client may set and nothing else.

Finding affected endpoints

Search for route functions where the body parameter is an ormar model. For each one, ask what a caller could set that they should not, such as role, ownership, status or timestamps.

Cleaning up data

Because the bug allowed unvalidated data to reach the database, review rows written by affected endpoints before and after the fix. Look for empty required fields, roles you did not assign and values outside their expected range. Database constraints such as not null and check constraints act as a last line of defence and are worth adding where they are missing.

After upgrading

Confirm that pip show ormar reports 0.23.1 or later in every environment. Add tests that post unexpected fields to your endpoints and expect them to be ignored or rejected.

Why this class keeps coming back

Frameworks that map request bodies onto objects save time, and they also make it easy to expose fields by accident. The same issue appears in many ecosystems under the name mass assignment. A habit of one schema per input, with an explicit list of fields, avoids most of it and makes code review easier.

Writing it up for your team

Note the fixed version, the endpoints that use an ormar model as a body, and the owner of each. Add a task to introduce dedicated request schemas and a task to review stored data. Put the dates in the same note so the work does not stall after the version bump.

Try it yourself

Severity alone does not tell you what to fix first. This demo shows how an exploitability check changes the order.

Click through it at your own pace, or open it full screen.

Quick check

Do I need to be logged in to be affected?

The record says any unauthenticated user can send the request, but your endpoint's own access rules still apply to who can reach it. The CVSS vector lists low privileges required.

What is the fixed version?

0.23.1.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.