PYSEC-2026-3040
Vulnerability from pysec - Published: 2026-07-13 15:46 - Updated: 2026-07-13 16:06Summary
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
MultipartParserdirectly from the ASGIreceive()stream and do not callparse_form(). - Known
parse_form()consumers either do not forwardContent-Lengthto it, recompute it from the already-read body, or run behind a layer (such as Werkzeug) that normalizes a negativeContent-Lengthto0.
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.
| Name | purl | python-multipart | pkg:pypi/python-multipart |
|---|
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "python-multipart",
"purl": "pkg:pypi/python-multipart"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.31"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"0.0.1",
"0.0.10",
"0.0.11",
"0.0.12",
"0.0.13",
"0.0.14",
"0.0.15",
"0.0.16",
"0.0.17",
"0.0.18",
"0.0.19",
"0.0.2",
"0.0.20",
"0.0.21",
"0.0.22",
"0.0.23",
"0.0.24",
"0.0.25",
"0.0.26",
"0.0.27",
"0.0.28",
"0.0.29",
"0.0.3",
"0.0.30",
"0.0.4",
"0.0.5",
"0.0.6",
"0.0.7",
"0.0.8",
"0.0.9"
]
}
],
"aliases": [
"CVE-2026-53540",
"GHSA-v9pg-7xvm-68hf"
],
"details": "### Summary\n\n`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.\n\n### Details\n\n`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.\n\n### Impact\n\nThis 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:\n\n* Starlette and FastAPI drive `MultipartParser` directly from the ASGI `receive()` stream and do not call `parse_form()`.\n* 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`.\n\nThe 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.\n\n### Mitigation\n\nUpgrade to version `0.0.31` or later, which rejects a negative `Content-Length` with a `ValueError` before reading the stream.",
"id": "PYSEC-2026-3040",
"modified": "2026-07-13T16:06:05.374002Z",
"published": "2026-07-13T15:46:17.309964Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Kludex/python-multipart/security/advisories/GHSA-v9pg-7xvm-68hf"
},
{
"type": "PACKAGE",
"url": "https://github.com/Kludex/python-multipart"
},
{
"type": "PACKAGE",
"url": "https://pypi.org/project/python-multipart"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-v9pg-7xvm-68hf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53540"
}
],
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "python-multipart: Negative Content-Length in parse_form buffers the entire body in memory"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.