Answer in brief
CVE-2026-53538 records a Low severity (CVSS 3.7) vulnerability in python-multipart: Semicolon treated as querystring field separator enables parameter smuggling. The current sources do not mark it as known exploited. The current feed maps python-multipart (pip), python-multipart (pypi). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 3.7. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps python-multipart (pip), python-multipart (pypi). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| python-multipartpip | <0.0.30 | 0.0.30 |
| python-multipartpypi | >=0 <0.0.30 | 0.0.30 |
Published upstream
Jun 15, 2026
Evidence: source:osv:source_dates:source-dates:recordSource modified
Sep 10, 2026
Evidence: source:osv:source_dates:source-dates:recordFirst seen by HOL
Jun 19, 2026
### Summary `QuerystringParser` treated `;` as a field separator in `application/x-www-form-urlencoded` bodies, in addition to `&`. The [WHATWG URL standard](https://url.spec.whatwg.org/#urlencoded-parsing), 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. ### Details In `python_multipart/multipart.py`, the `FIELD_NAME` and `FIELD_DATA` states located the next separator by scanning for `&` and, failing that, for `;`: ```python sep_pos = data.find(b"&", i) if sep_pos == -1: sep_pos = data.find(b";", i) ``` As a result, `;` acted as a field boundary. Because the fallback only triggered when no `&` remained in the current chunk, tokenization also depended on unrelated bytes later in the buffer and on how the body was split across `write()` calls. This is the same class of issue as CVE-2021-23336 in CPython's `urllib.parse`. For example, a body inspecting WAF or gateway that follows the WHATWG rule (only `&` separates fields) receives: ``` role=user&x=;role=admin ``` The upstream parses two fields, `role=user` and `x=";role=admin"`, sees a benign `role=user`, and forwards the request. `QuerystringParser` parsed the same bytes as three fields: `role="user"`, `x=""`, and `role="admin"`. The application (for example via Starlette/FastAPI `request.form()`, where the last value wins) then received `role=admin`, a value the upstream validator never saw. The parser is reachable through the public `QuerystringParser` class, the high level `FormParser`, `create_form_parser`, and `parse_form` APIs, and Starlette/FastAPI `request.form()` for url encoded bodies. ### Impact Interpretation conflict / HTTP parameter pollution. An attacker can smuggle extra or overriding form fields past an upstream component that applies the WHATWG separator rule, reaching the backend with parameters the intermediary did not observe. ### Mitigation Upgrade to `python-multipart` `0.0.30` or later, which treats only `&` as a field separator per the [WHATWG URL standard](https://url.spec.whatwg.org/#urlencoded-parsing). `;` is parsed as ordinary field data, matching `urllib.parse`, browsers, and other compliant parsers.
Quoted source text, attributed separately from HOL analysis.