Tornado CVE-2026-82397

No special conditions are required beyond the ability to send an HTTP POST request to a Tornado application. Any endpoint that accepts a request body - including default Tornado RequestHandler subclasses - is vulnerable because body parsing occurs unconditionally in RequestHandler._execute before handler dispatch, regardless of whether the handler logic uses the parsed form data. The only natural limit is max_buffer_size (default 104,857,600 bytes / 100 MB), which itself bounds but does not prevent the attack. Limiting factors: the attacker must be able to reach the Tornado server over the network; if Tornado is not internet-facing (e.g., internal microservice behind authenticated API gateway), exploitation requires network access to that internal segment. No authentication, no specific feature flag, and no non-default configuration is needed - the vulnerable code path executes on every POST with an application/x-www-form-urlencoded content type.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H scores 7.5 (High) and accurately reflects the threat model: any network-reachable Tornado endpoint accepting POST bodies can be targeted by an unauthenticated attacker with no complexity barrier. The availability impact is total for the duration of the attack, as the single-threaded event loop cannot process other requests while parsing runs. No EPSS score was provided in the intelligence data, so exploitation probability cannot be quantified numerically. No active exploitation is recorded in CISA KEV and no public proof-of-concept code is listed, which moderates the urgency somewhat. However, the attack is conceptually trivial - generating a 100 MB body of ampersand-separated key=value pairs requires only standard tools - making the effective exploit barrier very low even without a published PoC. The combination of network reachability, zero privilege requirement, and complete availability loss against an inherently single-threaded architecture represents a genuine operational priority for any internet-facing Tornado deployment.

An attacker sends a single HTTP POST request to any Tornado endpoint - no authentication or session required - with a Content-Type of application/x-www-form-urlencoded and a body filled with millions of ampersand-separated key=value pairs up to the 100 MB max_buffer_size limit. Tornado's synchronous parse_qs call processes all fields before routing the request, monopolizing the event loop thread and rendering the server unresponsive to all other clients for the duration of processing. The attack can be repeated in a loop to maintain continuous denial of service, and the low complexity means it requires no specialized tooling beyond curl or a simple Python script.