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

Technical summary

The vulnerability stems from parse_options_header in python-multipart applying transparent RFC 2231/5987 decoding to multipart headers using Python's email.message.Message class. RFC 2231/5987 extended parameter syntax allows encoded filenames in the form filename*=charset'lang'value and continuation forms (filename*0, filename*1). When both the plain filename and encoded filename* parameters are present, the decoded value overwrites the plain parameter. RFC 7578 Section 4.2 explicitly prohibits the filename* form in multipart/form-data. Upstream components (WAFs, proxies, gateways) that do not implement this decoding or strictly follow RFC 7578 will see the plain filename parameter, while python-multipart sees the decoded one, creating an interpretation divergence. An attacker leverages this to craft headers that pass inspection at one layer but present different metadata to the backend application. This is classified as an input validation issue (CWE-20) with characteristics of parameter masking (CWE-436).

Business impact

The primary business risk is the ability to bypass security controls and content filtering policies. If your organization relies on WAFs or proxies to validate or restrict uploaded file names, field names, or content types, an attacker could circumvent those controls by uploading malicious files under names that appear benign at the gateway but resolve to dangerous names at the application layer. This could lead to unauthorized file uploads, cross-site scripting via filename vectors, or delivery of unintended payloads to downstream processing. However, the low CVSS score reflects that this requires non-standard header crafting and does not directly cause confidentiality or availability loss. The impact is confined to integrity and depends on the application's file handling logic.

Affected systems

This vulnerability affects fastapiexpert python-multipart versions prior to 0.0.30. The library is used in Python web applications, particularly those built with FastAPI, that handle multipart form data uploads. Any application using an older version of python-multipart for parsing file uploads or form submissions is potentially affected. The vulnerability does not affect the Python standard library's email module itself, but rather how python-multipart wraps it for HTTP multipart handling.

Exploitability

Exploitation requires an attacker to craft and submit a malformed multipart request with extended parameter syntax in the Content-Disposition header. The attack is network-accessible and requires no authentication or user interaction, but the conditions for successful bypass are constrained: the upstream inspector must not decode RFC 2231/5987 syntax while the backend application must use python-multipart's decoded value. Many modern WAFs and proxies are aware of this decoding, reducing the window of vulnerability. The CVSS score of 3.7 (LOW) reflects that while the vector is straightforward to attempt, real-world impact depends on the specific deployment architecture and application logic. No public exploit code or widespread weaponization has been reported.

Remediation

Upgrade python-multipart to version 0.0.30 or later, which fixes the parsing behavior to avoid unintended RFC 2231/5987 decoding in multipart contexts. Version 0.0.30 is the patched release. Organizations should test the upgrade in a non-production environment first, as the parsing changes may affect legitimate requests with extended parameter syntax (though RFC 7578 compliance means such requests should not appear in standards-compliant multipart/form-data). Additionally, ensure that upstream security controls (WAFs, reverse proxies) are also configured to validate file and field names according to your organization's policy.

Patch guidance

Update python-multipart to 0.0.30 or later. The fix modifies parse_options_header to prevent automatic RFC 2231/5987 decoding for multipart/form-data headers. Verify that your application dependencies specify the corrected version. For FastAPI applications, this is typically managed through pip or a requirements.txt file. If you use a package manager with version pinning, ensure the pin is updated and the environment is refreshed (reinstall or rebuild containers). Test file uploads and form submissions in a staging environment to confirm that legitimate user uploads are not affected. The patched version is designed to maintain backward compatibility for RFC 7578–compliant requests.

Detection guidance

Look for Content-Disposition headers in incoming multipart requests that contain encoded filename* or name* parameters using the RFC 2231/5987 syntax (e.g., filename*=UTF-8''filename.txt or filename*0*=...). Monitor application logs for discrepancies between uploaded filename as seen by upstream proxies versus the filename actually stored or processed by the application. Consider adding Web Application Firewall rules to either reject requests with filename* parameters in multipart/form-data or to normalize them before they reach the backend. Check that your logging captures the raw header values to help identify attempted exploitation. Intrusion detection systems may detect suspicious patterns in multipart requests with encoded parameters.

Why prioritize this

While the CVSS score is low, this vulnerability should be addressed within standard patching cycles because it directly undermines the effectiveness of security controls that rely on consistent header interpretation. If your infrastructure includes WAFs or proxies that validate uploads, and your backend uses python-multipart, the vulnerability creates a specific control gap. However, this is not a critical incident requiring immediate response unless you have evidence of active exploitation or rely heavily on filename-based access control. The patch is straightforward and low-risk, making it a good candidate for your next planned maintenance window.

Risk score, explained

The CVSS 3.1 score of 3.7 (LOW) is driven by: Attack Vector = Network (AV:N, full remote accessibility); Attack Complexity = High (AC:H, requiring specific header crafting and environmental conditions); Privileges Required = None (PR:N); User Interaction = None (UI:N); Scope = Unchanged (S:U); Integrity Impact = Low (I:L, potential for bypassing controls or smuggling different filenames); Confidentiality Impact = None (C:N); Availability Impact = None (A:N). The high complexity factor and lack of confidentiality or availability impact result in a low overall score. The vulnerability is real and should be patched, but it is not an emergency.

Frequently asked questions