https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 18:19:02 +0000 https://db.gcve.eu/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://db.gcve.eu/vuln/ghsa-82w8-qh3p-5jfq