CVE-2026-27953: 
Python vulnerability analysis and mitigation

CVE-2026-27953 is a Pydantic validation bypass vulnerability in the ormar async ORM library, allowing unauthenticated attackers to skip all field validation by injecting "__pk_only__": true into a JSON request body. A secondary injection vector using __excluded__ can selectively nullify arbitrary model fields during construction. All versions of ormar up to and including 0.23.0 are affected; the issue was patched in version 0.23.1. The vulnerability was disclosed on March 19, 2026, with a CVSS v3.1 base score of 9.8 (Critical) per Feedly threat intelligence data, though the official GitHub advisory rates it 7.1 (High) (GitHub Advisory).

The root cause lies in NewBaseModel.__init__ (ormar/models/newbasemodel.py, line 128), which pops __pk_only__ directly from user-supplied **kwargs before any Pydantic validation occurs (CWE-20: Improper Input Validation; CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes). When __pk_only__ is True, the constructor bypasses __pydantic_validator__.validate_python() entirely and writes raw, unvalidated data directly to self.__dict__, after which .save() persists it to the database via table.insert().values(**self_fields) with no re-validation. The __pk_only__ flag was originally an internal optimization for creating lightweight FK placeholder instances, but because it was extracted from **kwargs via .pop() with a False default, any external caller passing user-controlled data could inject it. The secondary __excluded__ injection (line 292) follows the same pattern, allowing an attacker to nullify arbitrary fields by setting them to None. The canonical FastAPI + ormar pattern (async def create_item(item: Item)) is directly vulnerable because FastAPI deserializes the JSON body into a dict and calls the model constructor, where the injected key is consumed before Pydantic ever inspects it — even extra='forbid' would not prevent this (GitHub Advisory, Patch Commit).

Successful exploitation allows an unauthenticated remote attacker to persist arbitrary, unvalidated data to the application's database, bypassing all type checks, max_length constraints, choices enforcement, @field_validator/@model_validator decorators, and required-field checks. This enables privilege escalation (e.g., setting role="superadmin" by bypassing a validator that restricts values), data integrity violations (persisting invalid types or out-of-range values), business logic bypass (skipping custom validation logic such as email format or age range checks), and field nullification via __excluded__ injection (setting audit fields, tracking fields, or required business fields to NULL). Every application using ormar's canonical FastAPI integration pattern is affected, which is the primary usage pattern documented in ormar's official examples (GitHub Advisory).

A proof-of-concept exploit consisting of concrete curl commands with specific JSON payloads is publicly available in the GitHub security advisory, demonstrating the full attack against a real FastAPI + ormar application (GitHub Advisory). The vulnerability requires no authentication, no special privileges, and no user interaction, making it trivially exploitable over the network. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.00133 (low probability of exploitation in the near term), and the vulnerability is not listed in the CISA KEV catalog. The vulnerability is detectable by Nessus (plugin 303256) and Qualys (QID 692275).

1. Reconnaissance: Identify FastAPI applications using ormar as their ORM (versions ≤ 0.23.0) by examining public repositories, API documentation, or response headers that may reveal the technology stack.
2. Identify a target endpoint: Locate a POST/PUT endpoint that accepts an ormar model directly as a request body parameter (e.g., async def create_user(user: User)), which is the canonical pattern from ormar's official documentation.
3. Craft the bypass payload: Construct a JSON body that includes "__pk_only__": true alongside the desired field values that would normally be rejected by validation:

curl -X POST http://target/users/ \
  -H "Content-Type: application/json" \
  -d '{"__pk_only__": true, "name": "", "email": "not-an-email", "role": "superadmin", "balance": -99999}'

4. Observe bypass: The server returns 200 OK and persists all unvalidated data to the database — empty name, invalid email, unauthorized role, and negative balance — all of which would normally be rejected with a 422 Validation Error.
5. Optional — field nullification: Use the __excluded__ injection to selectively nullify fields (e.g., audit trails or security-relevant fields):

curl -X POST http://target/users/ \
  -H "Content-Type: application/json" \
  -d '{"__excluded__": ["email", "role"], "name": "attacker", "email": "will-be-nullified@example.com"}'

6. Leverage persisted data: Use the injected data (e.g., elevated role value) to escalate privileges or exploit downstream business logic that trusts database-stored values (GitHub Advisory).

• Network: Unexpected HTTP POST/PUT requests to ormar-backed API endpoints containing __pk_only__ or __excluded__ keys in the JSON body; requests that return 200 OK for data that should produce 422 Validation Error responses.
• Logs: Application access logs showing successful 200 responses to requests with JSON bodies containing __pk_only__ or __excluded__ fields; absence of 422 errors for requests with clearly invalid data (e.g., strings in integer fields, values exceeding max_length).
• Database: Records containing data that violates defined model constraints — empty required fields, values exceeding max_length, invalid enum/choices values (e.g., unexpected role values like superadmin), negative values in fields with ge=0 constraints, or NULL values in fields that should be required; records with timestamps inconsistent with normal application flow.
• File System: No specific file artifacts expected for this vulnerability type, as exploitation is purely in-memory and database-level.

Upgrade ormar to version 0.23.1 or later, which fixes the vulnerability by removing __pk_only__ and __excluded__ from the public __init__ **kwargs interface and replacing them with keyword-only parameters (_pk_only, _excluded) prefixed with _ that cannot be injected via JSON deserialization or Model(**user_dict) unpacking (Patch Commit). As a defense-in-depth measure, implement independent input validation at the API layer (e.g., using a separate Pydantic schema for request parsing before passing data to ormar models) to avoid relying solely on ormar's validation. After patching, review database records created before the upgrade for anomalies such as invalid data types, constraint violations, or unexpected role/privilege values that may indicate prior exploitation (GitHub Advisory).

The vulnerability was reported by security researcher Mistz1 and acknowledged by ormar maintainer collerek, who released the patch in version 0.23.1 with a release note urging immediate upgrade (Patch Commit). The advisory was picked up by vulnerability tracking platforms including VulnDB, Wiz vulnerability database, and Tenable Nessus shortly after disclosure. A Bluesky post from cyberhub.blog noted the vulnerability approximately two weeks after disclosure, indicating moderate community awareness.