chore(deps): [oracle-bigquery-mcp-agent] Update vulnerabilityAlerts to v0.0.32 [SECURITY] - autoclosed

[renovate-bot]

This PR contains the following updates:

Package	Change	Age	Confidence
python-multipart (changelog)	0.0.31 → 0.0.32

---

python-multipart: Quadratic-time querystring parsing with semicolon separators causes CPU denial of service

CVE-2026-53539 / GHSA-5rvq-cxj2-64vf

More information

Details

Summary

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.

Details

In python_multipart/multipart.py, both the FIELD_NAME and FIELD_DATA states located the next separator like this:

sep_pos = data.find(b"&", i)
if sep_pos == -1:
    sep_pos = data.find(b";", i)

data.find(b"&", i) scans from i to the end of the buffer and returns -1 only when there is no & anywhere in the remainder. For a ; separated body with no &, this failed full buffer scan repeats once per field, making parsing quadratic in the body length.

For example, a 1 MiB url encoded body consisting of a; repeated ~500,000 times, submitted with Content-Type: application/x-www-form-urlencoded, causes the parser to perform on the order of 10^11 byte comparisons, consuming several seconds of CPU for a single request. Cost scales quadratically with chunk size.

The parser is reachable through the public QuerystringParser class and through the high level FormParser, create_form_parser, and parse_form APIs for url encoded bodies. It is also the parser Starlette and FastAPI use for application/x-www-form-urlencoded request bodies via request.form().

Impact

Uncontrolled CPU consumption (denial of service). Parsing is synchronous, so a single small crafted form body occupies the handling worker for seconds, blocking any other work on that worker until parsing finishes. Sustained concurrent requests keep workers continuously busy, degrading or denying service.

Mitigation

Upgrade to python-multipart 0.0.30 or later, which treats only & as a field separator (per the WHATWG URL standard) using a single bounded scan, making parsing linear in the body length.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/Kludex/python-multipart/security/advisories/GHSA-5rvq-cxj2-64vf
• https://github.com/Kludex/python-multipart

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

python-multipart: Semicolon treated as querystring field separator enables parameter smuggling

CVE-2026-53538 / GHSA-6jv3-5f52-599m

More information

Details

Summary

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.

Details

In python_multipart/multipart.py, the FIELD_NAME and FIELD_DATA states located the next separator by scanning for & and, failing that, for ;:

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. ; is parsed as ordinary field data, matching urllib.parse, browsers, and other compliant parsers.

Severity

• CVSS Score: 3.7 / 10 (Low)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

References

• https://github.com/Kludex/python-multipart/security/advisories/GHSA-6jv3-5f52-599m
• https://github.com/Kludex/python-multipart

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

python-multipart: Content-Disposition parameter smuggling via RFC 2231/5987 extended parameters

CVE-2026-53537 / GHSA-vffw-93wf-4j4q

More information

Details

Summary

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.

Details

Given both a plain and an extended parameter, the extended value won. For example:

Content-Disposition: form-data; name="comment"; name*=utf-8''role

An inspector following RFC 7578 sees the field comment, while the returned value was name=role. The same applies to filenames:

Content-Disposition: form-data; name="upload"; filename="safe.txt"; filename*=utf-8''evil.php

The inspector sees safe.txt, while the returned value was filename=evil.php. Continuation parameters (filename*0, filename*1, and so on) were likewise reassembled into a filename invisible to a plain filename= match, and percent encoded sequences in the extended value were decoded (so ..%2F, %00, and similar appeared in the returned filename).

This affects the high level parse_options_header, FormParser, create_form_parser, and parse_form APIs, and reaches Starlette/FastAPI through request.form(), where the smuggled value is exposed as the form field name or UploadFile.filename.

Impact

This is an interpretation conflict (CWE-436) with other multipart/form-data parsers. An attacker able to submit multipart/form-data can present a different field name or filename to an upstream body inspecting component than the one delivered to the application. Concrete consequences depend on how the application uses these values, and may include bypassing a field name or filename based access/upload control, or, for an application that builds filesystem paths from the parsed filename without sanitization, path traversal via decoded ..%2F sequences. Decoded control bytes such as %00 can likewise cause confusion between an upstream validator and the backend. The File class applies os.path.basename, so file writing through it is not directly affected.

Mitigation

Upgrade to python-multipart 0.0.30 or later, which ignores RFC 2231/5987 extended parameters (name*, filename*, and their continuations) so the plain name/filename parameter remains authoritative. RFC 7578 §4.2 forbids filename* for multipart/form-data; name* and the continuation forms are dropped for the same reason, since they are not valid multipart/form-data parameters either.

Severity

• CVSS Score: 3.7 / 10 (Low)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

References

• https://github.com/Kludex/python-multipart/security/advisories/GHSA-vffw-93wf-4j4q
• https://github.com/Kludex/python-multipart

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

python-multipart: Negative Content-Length in parse_form buffers the entire body in memory

CVE-2026-53540 / GHSA-v9pg-7xvm-68hf

More information

Details

Summary

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.

Details

parse_form() reads the input stream in chunks, never reading more than the remaining Content-Length at a time. The per-chunk size is computed as min(content_length - bytes_read, chunk_size). The header value was parsed to an integer without checking its sign, so a Content-Length of -1 made this expression negative, and input_stream.read(-1) reads until end of stream. The intended bounded, chunked read therefore collapsed into a single unbounded read of the whole stream. The amount read is still bounded by what the client actually sends.

Impact

This only affects code that calls parse_form() directly with a Content-Length header taken from attacker-controlled input and without normalizing a negative value first. No known package is affected:

• Starlette and FastAPI drive MultipartParser directly from the ASGI receive() stream and do not call parse_form().
• Known parse_form() consumers either do not forward Content-Length to it, recompute it from the already-read body, or run behind a layer (such as Werkzeug) that normalizes a negative Content-Length to 0.

The realistic exposure is limited to bespoke WSGI or http.server handlers that forward raw client headers into parse_form(). In that case a crafted request buffers the body in memory at once, degrading availability under concurrent requests rather than causing a complete denial of service.

Mitigation

Upgrade to version 0.0.31 or later, which rejects a negative Content-Length with a ValueError before reading the stream.

Severity

• CVSS Score: 3.7 / 10 (Low)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

References

• https://github.com/Kludex/python-multipart/security/advisories/GHSA-v9pg-7xvm-68hf
• https://github.com/Kludex/python-multipart

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

Kludex/python-multipart (python-multipart)

v0.0.32

Compare Source

• Speed up partial-boundary scanning for CR/LF-dense part data #​300.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.