CVE-2026-82397 in Tornado
Summary
by MITRE • 08/31/2026
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.parse_qs in tornado/escape.py without passing max_num_fields. RequestHandler._execute in tornado/web.py parses the body before handler dispatch through HTTPServerRequest._parse_body and parse_body_arguments 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 max_buffer_size, which defaults to 104857600 bytes. This issue is fixed in version 6.5.8.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/31/2026
Tornado is a widely used Python web framework that provides asynchronous networking capabilities and handles high-concurrency HTTP requests through an event loop architecture. A critical vulnerability exists within the parsing logic for application/x-www-form-urlencoded request bodies prior to version 6.5.8 of Tornado. The flaw resides in how the library processes form data, specifically involving the interaction between tornado/escape.py and tornado/web.py during the initial stages of HTTP request handling. When a client submits an HTTP POST or PUT request with content type application/x-www-form-urlencoded, Tornado invokes urllib.parse.parse_qs to decode the body into key-value pairs. However, this parsing function is called without specifying a limit on the number of fields allowed in the payload.
The operational impact of this design flaw is severe due to the synchronous nature of the parsing operation within an asynchronous framework. In standard Python web servers using Tornado's default configuration, the event loop operates on a single thread for handling incoming connections and executing application logic. When a malicious actor sends a request body containing millions of separator-delimited fields, such as thousands or millions of ampersand-separated key-value pairs, the parse_qs function must iterate through each field to build the resulting dictionary. This process is CPU-intensive and blocks the event loop entirely while it executes. Because the parsing happens before the request reaches the specific handler logic via HTTPServerRequest._parse_body and parse_body_arguments in tornado/httputil.py, the entire server instance becomes unresponsive during this period.
This behavior effectively creates a Denial of Service condition against all active connections on the affected Tornado instances. Since the event loop is blocked by the synchronous parsing task, no other requests can be processed, leading to significant latency and eventual timeouts for legitimate users. The vulnerability is particularly dangerous because it does not require authentication; any unauthenticated client can trigger this resource exhaustion simply by crafting a large form-encoded payload. Furthermore, while there are limits on total buffer size controlled by max_buffer_size which defaults to approximately 104 megabytes, an attacker can still construct payloads that fit within this byte limit but contain an excessive number of fields relative to their character count, thereby maximizing the computational overhead without exceeding memory constraints.
From a classification perspective, this vulnerability aligns with CWE-787 Out-of-bounds Write in terms of resource consumption logic and more accurately maps to CWE-400 Uncontrolled Resource Consumption. In the context of the MITRE ATT&CK framework, this technique corresponds to T1496 Resource Hijacking or potentially Denial of Service via application layer attacks such as Slowloris variants where resources are exhausted through inefficient processing rather than just connection holding. The lack of a field count limit allows attackers to exploit the computational complexity of string parsing operations to degrade service availability.
To mitigate this vulnerability, organizations running Tornado versions prior to 6.5.8 must upgrade immediately to version 6.5.8 or later where the fix has been implemented. The patch introduces proper limits on the number of fields parsed during request body processing, preventing the synchronous stall of the event loop when faced with excessively large form payloads. Additionally, until an upgrade is performed, administrators can implement reverse proxy configurations using Nginx or Apache to enforce stricter limits on POST body sizes and field counts before requests reach the Tornado application server. This defense-in-depth approach ensures that malformed or maliciously crafted requests are rejected at the network edge rather than consuming backend resources. Monitoring for unusually large form-encoded payloads with high key-value ratios can also aid in detecting potential exploitation attempts during the transition period to patched versions.