CVE-2026-82397: Tornado: Urlencoded body parsing omits max_num_fields, so one request can stall the event loop
Summary
Tornado parses application/x-www-form-urlencoded bodies with urllib.parse.parseqs and does not pass maxnumfields. 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.parseqs( qs, keepblankvalues, strictparsing, encoding="latin1", errors="strict" )
maxnumfields 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.parsebody at tornado/httputil.py:636, and the urlencoded branch of parsebodyarguments calls parseqsbytes at tornado/httputil.py:1030.
The size that reaches it is bounded only by the body cap, which defaults to the stream's maxbuffersize 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.parseqs( qs, keepblankvalues, strictparsing, encoding="latin1", errors="strict", maxnumfields=maxnumfields, )
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.
Other sources
Tornado is a Python web framework and asynchronous networking library. Prior to 6.5.8, Tornado parses application/x-www-form-urlencoded request bodies with urllib.parse.parseqs in tornado/escape.py without passing maxnumfields. RequestHandler.execute in tornado/web.py parses the body before handler dispatch through HTTPServerRequest.parsebody and parsebodyarguments in tornado/httputil.py, so an unauthenticated request body containing millions of separator-delimited fields can synchronously stall the single-threaded event loop and delay every connection. The body is bounded only by maxbuffersize, which defaults to 104857600 bytes. This issue is fixed in version 6.5.8.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/tornadoto a version that resolves this vulnerability.Fixed in 6.5.8 - Upgrade
Upgrade
tornadoto a version that resolves this vulnerability.Fixed in 6.5.8 - Configuration
Ensure Tornado urlencoded request body parsing passes a max_num_fields bound to urllib.parse.parse_qs/parse_qs_bytes (so an attacker cannot force tens of millions of fields and stall the event loop). Tornado 6.5.8 is stated as the fix for omitting max_num_fields.
Tornado urlencoded body parsing max_num_fields = bounded (pass max_num_fields into urllib.parse.parse_qs/parse_qs_bytes)
Event History
Frequently Asked Questions
Which deployments are exposed to this denial-of-service condition?
Tornado deployments running versions prior to 6.5.8 are affected when they accept application/x-www-form-urlencoded request bodies. The issue occurs before handler dispatch, so endpoints do not need to explicitly parse form data for the event loop to be stalled.
What does an attacker need to exploit it?
An attacker needs only network access to send an unauthenticated HTTP request with a URL-encoded body containing millions of separator-delimited fields. No privileges or user interaction are required.
Are default settings sufficient to limit the impact?
No. The request body is limited by max_buffer_size, but its default is 104857600 bytes, which can still accommodate enough fields to synchronously stall the single-threaded event loop and delay all connections.
How can this be remediated?
Upgrade Tornado to version 6.5.8, which fixes the missing max_num_fields limit during URL-encoded body parsing.