CVE-2026-53540

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.

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.

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.

TuxCare rebuilt python-multipart to address 1 CVE. Fixed in 0.0.6.post4+tuxcare.

These are all security issues fixed in the python311-python-multipart-0.0.32-1.1 package on the GA media of openSUSE Tumbleweed.

This update for python-python-multipart fixes the following issues

• CVE-2026-53537: multipart/form-data with extended parameters can lead to file or parameter smuggling (bsc#1268506).
• CVE-2026-53538: urlencoded requests containing semicolons can lead to form field smuggling (bsc#1268496).
• CVE-2026-53539: small crafted body can cause a denial of service (bsc#1268500).
• CVE-2026-53540: crafted request buffers can lead to degrading availability (bsc#1268488).

This update for python-python-multipart fixes the following issues

• CVE-2026-53537: multipart/form-data with extended parameters can lead to file or parameter smuggling (bsc#1268506).
• CVE-2026-53538: urlencoded requests containing semicolons can lead to form field smuggling (bsc#1268496).
• CVE-2026-53539: small crafted body can cause a denial of service (bsc#1268500).
• CVE-2026-53540: crafted request buffers can lead to degrading availability (bsc#1268488).