Python‑Multipart, a Python streaming multipart parser, incorrectly handles RFC 2231/5987 extended parameters such as filename*=…, name*=…, and the continuation forms filename*0/filename*1 when parsing Content‑Disposition and Content‑Type headers. The canonical parameter (filename or name) is overridden by the extended form, which is explicitly forbidden for multipart/form‑data by RFC 7578 §4.2. Consequently an attacker can craft a multipart request that delivers a field name or filename to the backend that differs from what upstream components, such as web application fires, log or filter, expect. This mismatch can allow sensitive data to bypass validation or trigger unintended processing paths.

The vulnerability exists in Kludex’s python‑multipart package in all releases before 0.0.30. Any Python application that uses python‑multipart for parsing multipart/form‑data—e.g., file upload handlers, API endpoints, or services that rely on the library’s parsing logic—is potentially impacted.

The CVSS score of 3.7 reflects the moderate impact of this issue. The EPSS score is not available, and the vulnerability is not listed in CISA’s KEV catalog. The likely attack vector is an HTTP multipart/form‑data upload where the attacker controls the Content‑Disposition header. Exploitation requires crafting a request with an RFC 2231/5987 encoded parameter that upstream filters do not reject, allowing the attacker to smuggle a different field name or filename to the backend. Once the backend receives the tampered metadata, it may process or store the payload under an unintended field, potentially leading to data leakage or integrity violations. Because the problem is limited to parsing logic, the overall risk remains moderate, but applying the available fix removes the parsing flaw entirely.