https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 16:31:31 +0000 https://cve.radiocsirt.org/vuln/brew-aider-cve-2026-54283 <p><strong>Affected:</strong> Homebrew: aider</p> <p>### Summary `request.form()` accepts `max_fields` and `max_part_size` to bound resource consumption while parsing form data. These limits are enforced for `multipart/form-data`, but silently ignored for `application/x-www-form-urlencoded`. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply.</p> <p>### Details `request.form()` dispatches to a different parser depending on the `Content-Type`. For `multipart/form-data` the `max_files`, `max_fields`, and `max_part_size` limits are forwarded to the parser, but for `application/x-www-form-urlencoded` the parser is constructed without them. It has no `max_fields` or `max_part_size` parameter to receive them, and it appends every field with no count check and accumulates each field&#39;s name and value with no size check. The configured limits are therefore both unreachable and unenforced for url-encoded bodies.</p> <p>Because the url-encoded parser does its work synchronously between stream reads, the two attack shapes have different effects:</p> <p>- **Field count** drives CPU and event-loop blocking. A body of ~1,000,000 fields (a sub-10MB payload such as `f0=v&amp;f1=v&amp;...`) blocks the worker&#39;s event loop for several seconds while parsing, during which the worker serves no other request. - **Field size** drives memory. A single large field value (e.g. a 50MB value) is buffered in full to build the `Fo…</p> <p><strong>Affected:</strong> Homebrew: aider</p> <p>### Summary `request.form()` accepts `max_fields` and `max_part_size` to bound resource consumption while parsing form data. These limits are enforced for `multipart/form-data`, but silently ignored for `application/x-www-form-urlencoded`. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply.</p> <p>### Details `request.form()` dispatches to a different parser depending on the `Content-Type`. For `multipart/form-data` the `max_files`, `max_fields`, and `max_part_size` limits are forwarded to the parser, but for `application/x-www-form-urlencoded` the parser is constructed without them. It has no `max_fields` or `max_part_size` parameter to receive them, and it appends every field with no count check and accumulates each field&#39;s name and value with no size check. The configured limits are therefore both unreachable and unenforced for url-encoded bodies.</p> <p>Because the url-encoded parser does its work synchronously between stream reads, the two attack shapes have different effects:</p> <p>- **Field count** drives CPU and event-loop blocking. A body of ~1,000,000 fields (a sub-10MB payload such as `f0=v&amp;f1=v&amp;...`) blocks the worker&#39;s event loop for several seconds while parsing, during which the worker serves no other request. - **Field size** drives memory. A single large field value (e.g. a 50MB value) is buffered in full to build the `Fo…</p> https://cve.radiocsirt.org/vuln/brew-aider-cve-2026-54283 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-al63130 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: litellm-database</p> <p>Package litellm-database version 1.96.0-r0 fixes 5 vulnerabilities: CVE-2026-54282, CVE-2025-62727, CVE-2026-48818, CVE-2026-54283, CVE-2025-54121</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: litellm-database</p> <p>Package litellm-database version 1.96.0-r0 fixes 5 vulnerabilities: CVE-2026-54282, CVE-2025-62727, CVE-2026-48818, CVE-2026-54283, CVE-2025-54121</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-al63130 https://cve.radiocsirt.org/vuln/euvd-2026-329322 EUVD-2026-329322 https://cve.radiocsirt.org/vuln/euvd-2026-329322 https://cve.radiocsirt.org/vuln/fkie_cve-2026-54283 <p>Starlette is a lightweight ASGI framework/toolkit. From 0.4.1 until 1.3.1, request.form() accepts max_fields and max_part_size to bound resource consumption while parsing form data. These limits are enforced for multipart/form-data, but silently ignored for application/x-www-form-urlencoded. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply. This vulnerability is fixed in 1.3.1.</p> <p>Starlette is a lightweight ASGI framework/toolkit. From 0.4.1 until 1.3.1, request.form() accepts max_fields and max_part_size to bound resource consumption while parsing form data. These limits are enforced for multipart/form-data, but silently ignored for application/x-www-form-urlencoded. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply. This vulnerability is fixed in 1.3.1.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-54283 https://cve.radiocsirt.org/vuln/ghsa-82w8-qh3p-5jfq <p><strong>Affected:</strong> PyPI: starlette</p> <p>### Summary `request.form()` accepts `max_fields` and `max_part_size` to bound resource consumption while parsing form data. These limits are enforced for `multipart/form-data`, but silently ignored for `application/x-www-form-urlencoded`. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply.</p> <p>### Details `request.form()` dispatches to a different parser depending on the `Content-Type`. For `multipart/form-data` the `max_files`, `max_fields`, and `max_part_size` limits are forwarded to the parser, but for `application/x-www-form-urlencoded` the parser is constructed without them. It has no `max_fields` or `max_part_size` parameter to receive them, and it appends every field with no count check and accumulates each field&#39;s name and value with no size check. The configured limits are therefore both unreachable and unenforced for url-encoded bodies.</p> <p>Because the url-encoded parser does its work synchronously between stream reads, the two attack shapes have different effects:</p> <p>- **Field count** drives CPU and event-loop blocking. A body of ~1,000,000 fields (a sub-10MB payload such as `f0=v&amp;f1=v&amp;...`) blocks the worker&#39;s event loop for several seconds while parsing, during which the worker serves no other request. - **Field size** drives memory. A single large field value (e.g. a 50MB value) is buffered in full to build the `Fo…</p> <p><strong>Affected:</strong> PyPI: starlette</p> <p>### Summary `request.form()` accepts `max_fields` and `max_part_size` to bound resource consumption while parsing form data. These limits are enforced for `multipart/form-data`, but silently ignored for `application/x-www-form-urlencoded`. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply.</p> <p>### Details `request.form()` dispatches to a different parser depending on the `Content-Type`. For `multipart/form-data` the `max_files`, `max_fields`, and `max_part_size` limits are forwarded to the parser, but for `application/x-www-form-urlencoded` the parser is constructed without them. It has no `max_fields` or `max_part_size` parameter to receive them, and it appends every field with no count check and accumulates each field&#39;s name and value with no size check. The configured limits are therefore both unreachable and unenforced for url-encoded bodies.</p> <p>Because the url-encoded parser does its work synchronously between stream reads, the two attack shapes have different effects:</p> <p>- **Field count** drives CPU and event-loop blocking. A body of ~1,000,000 fields (a sub-10MB payload such as `f0=v&amp;f1=v&amp;...`) blocks the worker&#39;s event loop for several seconds while parsing, during which the worker serves no other request. - **Field size** drives memory. A single large field value (e.g. a 50MB value) is buffered in full to build the `Fo…</p> https://cve.radiocsirt.org/vuln/ghsa-82w8-qh3p-5jfq https://cve.radiocsirt.org/vuln/opensuse-su-2026:21053-1 <p>Security update for python-starlette</p> <p>Security update for python-starlette</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:21053-1 https://cve.radiocsirt.org/vuln/pysec-2026-249 <p><strong>Affected:</strong> PyPI: starlette</p> <p>Starlette is a lightweight ASGI framework/toolkit. From 0.4.1 until 1.3.1, request.form() accepts max_fields and max_part_size to bound resource consumption while parsing form data. These limits are enforced for multipart/form-data, but silently ignored for application/x-www-form-urlencoded. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply. This vulnerability is fixed in 1.3.1.</p> <p><strong>Affected:</strong> PyPI: starlette</p> <p>Starlette is a lightweight ASGI framework/toolkit. From 0.4.1 until 1.3.1, request.form() accepts max_fields and max_part_size to bound resource consumption while parsing form data. These limits are enforced for multipart/form-data, but silently ignored for application/x-www-form-urlencoded. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply. This vulnerability is fixed in 1.3.1.</p> https://cve.radiocsirt.org/vuln/pysec-2026-249 https://cve.radiocsirt.org/vuln/rhsa-2026:36005 <p>giflib: giflib: Denial of Service via buffer overflow in EGifGCBToExtension gnutls: GnuTLS: Denial of Service via DTLS zero-length fragment gnutls: GnuTLS: Denial of Service via heap buffer overflow in DTLS handshake fragment reassembly vLLM: vLLM: Denial of Service due to excessive video frame processing vllm: vLLM: Denial of Service via excessively large &#39;n&#39; parameter in OpenAI-compatible API vim: arbitrary command execution via modeline sandbox bypass vllm: vLLM: Arbitrary code execution via malicious HuggingFace model gnutls: gnutls: Denial of Service via DTLS packet reordering vulnerability gnutls: gnutls: Authentication Bypass via NUL Character in Username vllm: starlette: vLLM: Critical authentication bypass allows unauthorized API access vllm: vLLM: Denial of Service due to improper floating-point validation starlette: Starlette: request.form() limits silently ignored for application/x-www-form-urlencoded enable DoS</p> <p>giflib: giflib: Denial of Service via buffer overflow in EGifGCBToExtension gnutls: GnuTLS: Denial of Service via DTLS zero-length fragment gnutls: GnuTLS: Denial of Service via heap buffer overflow in DTLS handshake fragment reassembly vLLM: vLLM: Denial of Service due to excessive video frame processing vllm: vLLM: Denial of Service via excessively large &#39;n&#39; parameter in OpenAI-compatible API vim: arbitrary command execution via modeline sandbox bypass vllm: vLLM: Arbitrary code execution via malicious HuggingFace model gnutls: gnutls: Denial of Service via DTLS packet reordering vulnerability gnutls: gnutls: Authentication Bypass via NUL Character in Username vllm: starlette: vLLM: Critical authentication bypass allows unauthorized API access vllm: vLLM: Denial of Service due to improper floating-point validation starlette: Starlette: request.form() limits silently ignored for application/x-www-form-urlencoded enable DoS</p> https://cve.radiocsirt.org/vuln/rhsa-2026:36005 https://cve.radiocsirt.org/vuln/suse-su-2026:22360-1 <p>Security update for python-starlette</p> <p>Security update for python-starlette</p> https://cve.radiocsirt.org/vuln/suse-su-2026:22360-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54283 <p><strong>Affected:</strong> Ubuntu:22.04:LTS: starlette, Ubuntu:24.04:LTS: starlette, Ubuntu:25.10: starlette, Ubuntu:26.04:LTS: starlette</p> <p>Starlette is a lightweight ASGI framework/toolkit. From 0.4.1 until 1.3.1, request.form() accepts max_fields and max_part_size to bound resource consumption while parsing form data. These limits are enforced for multipart/form-data, but silently ignored for application/x-www-form-urlencoded. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply. This vulnerability is fixed in 1.3.1.</p> <p><strong>Affected:</strong> Ubuntu:22.04:LTS: starlette, Ubuntu:24.04:LTS: starlette, Ubuntu:25.10: starlette, Ubuntu:26.04:LTS: starlette</p> <p>Starlette is a lightweight ASGI framework/toolkit. From 0.4.1 until 1.3.1, request.form() accepts max_fields and max_part_size to bound resource consumption while parsing form data. These limits are enforced for multipart/form-data, but silently ignored for application/x-www-form-urlencoded. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply. This vulnerability is fixed in 1.3.1.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-54283