GHSA-mpf4-983q-p7j4
Tornado: Urlencoded body parsing omits max_num_fields, so one request can stall the event loop
Quick fix
GHSA-mpf4-983q-p7j4 — tornado: upgrade to the fixed version with the command below.
pip install --upgrade 'tornado>=6.5.8'Details
## Summary
Tornado parses `application/x-www-form-urlencoded` bodies with `urllib.parse.parse_qs` and does not pass `max_num_fields`. A body made almost entirely of separators produces tens of millions of fields, and the parse happens on the event loop before the handler runs, so a single request stalls the whole server.
## Where it is
`tornado/escape.py`, at HEAD `e530031405e2154654dedc4c84d5656b557ea310`:
```python result = urllib.parse.parse_qs( qs, keep_blank_values, strict_parsing, encoding="latin1", errors="strict" ) ```
`max_num_fields` is the parameter CPython added for exactly this, and it is absent.
The path to it is entirely server-side and pre-dispatch. `RequestHandler._execute` parses the body at `tornado/web.py:1821`, which reaches `HTTPServerRequest._parse_body` at `tornado/httputil.py:636`, and the urlencoded branch of `parse_body_arguments` calls `parse_qs_bytes` at `tornado/httputil.py:1030`.
The size that reaches it is bounded only by the body cap, which defaults to the stream's `max_buffer_size` of 104857600 at `tornado/iostream.py:239`, applied as the request body default at `tornado/http1connection.py:136-140`. A 100 MB body of separators is around fifty million fields.
## Impact
Denial of service against the whole process, not one request. Tornado is single-threaded and the parse is synchronous on the event loop, so every other connection waits. No authentication is needed if any route accepts a form post, which is the normal case.
## Suggested fix
Pass a bound:
```python result = urllib.parse.parse_qs( qs, keep_blank_values, strict_parsing, encoding="latin1", errors="strict", max_num_fields=max_num_fields, ) ```
with a conservative default and a way for applications to raise it. CPython raises `ValueError` when the limit is exceeded, which maps cleanly onto a 400.
Lowering the default body cap for urlencoded specifically would help too, since 100 MB of form fields is not a shape any real client sends.
## Why I do not think this is a duplicate
The published tornado advisories cover out-of-bounds access in the C extension, unbounded accumulation of decompressed chunks in `AsyncHTTPClient`, the Authorization header surviving cross-origin redirects, credential leakage on curl handle reuse, and cookie attribute validation. The decompression one is the nearest in spirit and is on the client side; this is the server parsing a request body. The call is unchanged at HEAD.
Are you affected?
Enter the version of the package you're using.
Affected packages
References
- https://github.com/tornadoweb/tornado/security/advisories/GHSA-mpf4-983q-p7j4[WEB]
- https://nvd.nist.gov/vuln/detail/CVE-2026-82397[ADVISORY]
- https://github.com/tornadoweb/tornado/pull/3704[WEB]
- https://github.com/tornadoweb/tornado/commit/8d6363ed7b69d5f0da806efe34d256627a2191de[WEB]
- https://github.com/tornadoweb/tornado[PACKAGE]
- https://github.com/tornadoweb/tornado/releases/tag/v6.5.8[WEB]