CVE-2026-53537: Python-Multipart Header Parsing Vulnerability

CVE-2026-53537 Overview

CVE-2026-53537 affects python-multipart, a streaming multipart parser for Python, in versions prior to 0.0.30. The vulnerability allows an attacker to smuggle field names or filenames past upstream inspectors such as Web Application Firewalls (WAFs), proxies, and gateways. The flaw stems from inconsistent handling of RFC 2231/5987 extended parameter syntax in Content-Disposition and Content-Type headers, which RFC 7578 §4.2 explicitly forbids in multipart/form-data. This input validation weakness is classified under [CWE-20]. The maintainers fixed the issue in version 0.0.30.

Critical Impact
Attackers can bypass upstream security inspectors by smuggling alternate field names or filenames that the backend parser interprets differently than the WAF or proxy.

Affected Products

python-multipart versions prior to 0.0.30
Python applications relying on parse_options_header for multipart parsing
Frameworks and services depending on python-multipart (such as Starlette and FastAPI applications)

Discovery Timeline

2026-06-22 - CVE-2026-53537 published to NVD
2026-06-23 - Last updated in NVD database

Technical Details for CVE-2026-53537

Vulnerability Analysis

The vulnerability resides in the parse_options_header function within python-multipart. The function delegates header parsing to Python's email.message.Message class, which transparently applies RFC 2231 and RFC 5987 decoding. This decoding handles extended parameter syntax including filename*=charset'lang'value, name*=..., and the filename*0/filename*1 continuation form.

When such extended parameters are present, the decoded value is surfaced under the bare filename or name key. The extended form overrides the plain parameter when both are present in the same header. This behavior contradicts RFC 7578 §4.2, which explicitly forbids the filename* form in multipart/form-data content.

Root Cause

The root cause is a parser disagreement (request smuggling at the header semantics layer). Components that strictly follow RFC 7578, or that do not implement RFC 2231/5987 decoding for multipart/form-data, interpret the same header differently than python-multipart. An upstream WAF sees one filename or field name in the plain parameter, while the backend application sees a different value extracted from the extended parameter.

Attack Vector

An attacker crafts a multipart request that includes both a plain filename (or name) parameter and an extended filename* parameter with conflicting values. The upstream inspector evaluates the plain value against its policy and allows the request. The backend parses the extended value, processing attacker-controlled input that the inspector never validated. This enables policy bypass for file upload filters, content-type restrictions, and field-name allowlists.

No verified proof-of-concept code is published. Refer to the GitHub Security Advisory for technical details from the maintainers.

Detection Methods for CVE-2026-53537

Indicators of Compromise

Multipart request bodies containing both filename= and filename*= parameters within the same Content-Disposition header
Presence of name*= extended parameter syntax in multipart/form-data requests, which RFC 7578 forbids
filename*0/filename*1 continuation parameters in HTTP upload requests

Detection Strategies

Inspect HTTP request logs for Content-Disposition headers containing the *= extended parameter syntax in multipart submissions
Compare filename and field-name values logged at the WAF or proxy against values recorded by the backend application to identify parser disagreements
Apply signature-based detection at the gateway for any occurrence of filename*, name*, or continuation forms in multipart/form-data payloads

Monitoring Recommendations

Capture full multipart headers (not just parsed values) at the perimeter to enable retrospective analysis
Alert on uploads where backend-logged filenames diverge from filenames observed in WAF telemetry
Track dependency versions of python-multipart across services and flag any service still running a release below 0.0.30

How to Mitigate CVE-2026-53537

Immediate Actions Required

Upgrade python-multipart to version 0.0.30 or later across all Python services and dependent frameworks
Audit transitive dependencies in FastAPI, Starlette, and other ASGI applications that bundle python-multipart
Add WAF rules to reject multipart requests containing filename*, name*, or continuation parameters until patching is complete

Patch Information

The maintainers fixed the vulnerability in python-multipart version 0.0.30. The fix removes RFC 2231/5987 extended parameter handling for multipart/form-data, aligning parser behavior with RFC 7578 §4.2. See the GitHub Security Advisory GHSA-vffw-93wf-4j4q for the official advisory.

Workarounds

Configure upstream WAFs or reverse proxies to strip or reject Content-Disposition headers containing *= extended parameters before they reach the backend
Wrap calls to parse_options_header with custom validation that rejects headers containing filename* or name* parameters when handling multipart/form-data
Restrict accepted Content-Type and upload field names with strict allowlists enforced after parsing, not before

bash

# Upgrade python-multipart to the patched release
pip install --upgrade 'python-multipart>=0.0.30'

# Verify installed version
python -c "import multipart; print(multipart.__version__)"