https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 10:28:29 +0000 https://cve.radiocsirt.org/vuln/brew-cycode-cve-2026-53540 <p><strong>Affected:</strong> Homebrew: cycode</p> <p>### Summary</p> <p>`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.</p> <p>### Details</p> <p>`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.</p> <p>### Impact</p> <p>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:</p> <p>* 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`.</p> <p>The realistic exposure is limited to bespoke WSGI or `http.server` handle…</p> <p><strong>Affected:</strong> Homebrew: cycode</p> <p>### Summary</p> <p>`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.</p> <p>### Details</p> <p>`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.</p> <p>### Impact</p> <p>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:</p> <p>* 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`.</p> <p>The realistic exposure is limited to bespoke WSGI or `http.server` handle…</p> https://cve.radiocsirt.org/vuln/brew-cycode-cve-2026-53540 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0933 certfr-2026-avi-0933 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0933 https://cve.radiocsirt.org/vuln/cleanstart-2026-eh47852 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: litellm-database</p> <p>Multiple security vulnerabilities affect the litellm-database package. These issues are resolved in later releases. See references for individual vulnerability details.</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: litellm-database</p> <p>Multiple security vulnerabilities affect the litellm-database package. These issues are resolved in later releases. See references for individual vulnerability details.</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-eh47852 https://cve.radiocsirt.org/vuln/euvd-2026-329038 EUVD-2026-329038 https://cve.radiocsirt.org/vuln/euvd-2026-329038 https://cve.radiocsirt.org/vuln/fkie_cve-2026-53540 <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-53540 https://cve.radiocsirt.org/vuln/ghsa-v9pg-7xvm-68hf <p><strong>Affected:</strong> PyPI: python-multipart</p> <p>### Summary</p> <p>`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.</p> <p>### Details</p> <p>`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.</p> <p>### Impact</p> <p>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:</p> <p>* 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`.</p> <p>The realistic exposure is limited to bespoke WSGI or `http.server` handle…</p> <p><strong>Affected:</strong> PyPI: python-multipart</p> <p>### Summary</p> <p>`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.</p> <p>### Details</p> <p>`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.</p> <p>### Impact</p> <p>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:</p> <p>* 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`.</p> <p>The realistic exposure is limited to bespoke WSGI or `http.server` handle…</p> https://cve.radiocsirt.org/vuln/ghsa-v9pg-7xvm-68hf https://cve.radiocsirt.org/vuln/opensuse-su-2026:11099-1 <p>python311-python-multipart-0.0.32-1.1 on GA media</p> <p>python311-python-multipart-0.0.32-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:11099-1 https://cve.radiocsirt.org/vuln/pysec-2026-3040 <p><strong>Affected:</strong> PyPI: python-multipart</p> <p>### Summary</p> <p>`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.</p> <p>### Details</p> <p>`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.</p> <p>### Impact</p> <p>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:</p> <p>* 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`.</p> <p>The realistic exposure is limited to bespoke WSGI or `http.server` handle…</p> <p><strong>Affected:</strong> PyPI: python-multipart</p> <p>### Summary</p> <p>`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.</p> <p>### Details</p> <p>`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.</p> <p>### Impact</p> <p>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:</p> <p>* 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`.</p> <p>The realistic exposure is limited to bespoke WSGI or `http.server` handle…</p> https://cve.radiocsirt.org/vuln/pysec-2026-3040 https://cve.radiocsirt.org/vuln/suse-su-2026:22372-1 <p>Security update for python-python-multipart</p> <p>Security update for python-python-multipart</p> https://cve.radiocsirt.org/vuln/suse-su-2026:22372-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-53540 <p><strong>Affected:</strong> Ubuntu:Pro:22.04:LTS: python-multipart, Ubuntu:Pro:24.04:LTS: python-multipart, Ubuntu:25.10: python-multipart, Ubuntu:26.04:LTS: python-multipart</p> <p>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.</p> <p><strong>Affected:</strong> Ubuntu:Pro:22.04:LTS: python-multipart, Ubuntu:Pro:24.04:LTS: python-multipart, Ubuntu:25.10: python-multipart, Ubuntu:26.04:LTS: python-multipart</p> <p>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.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-53540