Hi,
The following vulnerabilities were published for python-multipart.
CVE-2026-53537[0]:
| Python-Multipart is a streaming multipart parser for Python. Prior
| to 0.0.30, parse_options_header parsed Content-Disposition (and
| Content-Type) headers with email.message.Message, which
| transparently applies RFC 2231/5987 decoding. The extended parameter
| syntax (filename*=charset'lang'value, name*=..., and the
| filename*0/filename*1 continuation form) is decoded and surfaced
| under the bare filename/name key, and overrides the plain parameter
| when both are present. RFC 7578 §4.2 explicitly forbids the
| filename* form in multipart/form-data. Components that follow RFC
| 7578, or that do not implement RFC 2231/5987 decoding for
| multipart/form-data (WAFs, proxies, gateways), may interpret such a
| header differently. An attacker can exploit that difference to
| smuggle a different field name or filename past an upstream
| inspector to the backend. This vulnerability is fixed in 0.0.30.
CVE-2026-53538[1]:
| Python-Multipart is a streaming multipart parser for Python. Prior
| to 0.0.30, QuerystringParser treated ; as a field separator in
| application/x-www-form-urlencoded bodies, in addition to &. The
| WHATWG URL standard, modern browsers, and Python's urllib.parse
| (since the CVE-2021-23336 fix) treat only & as a separator. This
| creates a parser differential: the same bytes are tokenized into
| different fields than a WHATWG compliant intermediary would produce,
| allowing an attacker to smuggle extra form fields past an upstream
| body inspecting component. This vulnerability is fixed in 0.0.30.
CVE-2026-53539[2]:
| Python-Multipart is a streaming multipart parser for Python. Prior
| to 0.0.30, when parsing application/x-www-form-urlencoded bodies,
| QuerystringParser located the field separator with a two step
| lookup: it first scanned the entire remaining buffer for &, and only
| when no & existed anywhere ahead did it fall back to scanning for ;.
| For a body that uses ; as the separator and contains no &, every
| field iteration performed a full failed & scan over the entire
| remaining buffer before locating the nearby ;. With N semicolon
| separated fields in a chunk of size B, this yields O(B^2) byte
| comparisons per chunk. An attacker can submit a small crafted body
| of the form a;a;a;... and cause the parser to spend seconds of CPU
| per request. A handful of concurrent requests can exhaust worker
| processes. This vulnerability is fixed in 0.0.30.
CVE-2026-53540[3]:
| Python-Multipart is a streaming multipart parser for Python. Prior
| to 0.0.31, parse_form() did not validate the Content-Length header
| before using it to bound its chunked read of the request body. A
| negative Content-Length turned the bounded read into a read-until-
| EOF, so the entire body was loaded into memory in a single read
| instead of in fixed-size chunks. This vulnerability is fixed in
| 0.0.31.
More details are in the respective GHSA's tracked in the
debian-security-tracker.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2026-53537
https://www.cve.org/CVERecord?id=CVE-2026-53537
https://github.com/Kludex/python-multipart/security/advisories/GHSA-vffw-93wf-4j4q
[1] https://security-tracker.debian.org/tracker/CVE-2026-53538
https://www.cve.org/CVERecord?id=CVE-2026-53538
https://github.com/Kludex/python-multipart/security/advisories/GHSA-6jv3-5f52-599m
[2] https://security-tracker.debian.org/tracker/CVE-2026-53539
https://www.cve.org/CVERecord?id=CVE-2026-53539
https://github.com/Kludex/python-multipart/security/advisories/GHSA-5rvq-cxj2-64vf
[3] https://security-tracker.debian.org/tracker/CVE-2026-53540
https://www.cve.org/CVERecord?id=CVE-2026-53540
https://github.com/Kludex/python-multipart/security/advisories/GHSA-v9pg-7xvm-68hf
Regards,
Salvatore