CVE-2026-115927: 
Python vulnerability analysis and mitigation

CVE-2026-115927 is a Denial of Service vulnerability in the Tornado Python web framework caused by improper handling of HTTP/1.1 chunked transfer encoding. Prior to version 6.6.0, Tornado processes all arriving chunked body data without yielding to the event loop, allowing a remote unauthenticated attacker to send millions of one-byte chunks to monopolize the process event loop and stall all other connections. Additionally, non-streaming handlers store each chunk as a separate object, consuming roughly 20 times the received body size in memory. The vulnerability affects all Tornado versions before 6.6.0 and was fixed in version 6.6.0, released October 21, 2026. It carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, Tornado Release).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). Tornado's _read_chunked_body method in http1connection.py processes each arriving chunk synchronously without yielding control back to the asyncio event loop, meaning a client sending millions of 1-byte chunks (each costing approximately 6µs to parse) can block the event loop for the entire body duration — potentially close to a minute with the default 100 MB max_body_size. For handlers not using @stream_request_body, each chunk was stored as a separate Python bytes object in a list, consuming approximately 120 bytes of overhead per 1-byte chunk (~20x amplification). SimpleAsyncHTTPClient is also affected when reading responses from a malicious server. The fix (PR #3773, commit ceab335) introduces periodic event loop yields every 256 KB, coalesces small chunks before delivery, and accumulates non-streaming bodies in a bytearray instead of a list (GitHub Advisory, Fix Commit, Fix PR).

Successful exploitation causes a denial of service affecting all connections served by the targeted Tornado process: the event loop is monopolized for the duration of body parsing, rendering the application completely unresponsive to other clients. For handlers not using @stream_request_body, memory exhaustion is an additional risk due to the ~20x memory amplification from per-chunk object storage. An attacker can repeat or parallelize requests to sustain the denial of service, and there is no confidentiality or integrity impact — only availability is affected (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the disclosure date. The vulnerability requires no authentication and no user interaction, making it trivially exploitable by any remote attacker who can send HTTP requests to a Tornado server. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The CVE status is listed as "Deferred" in the NVD (GitHub Advisory).

1. Reconnaissance: Identify internet-facing services running Tornado versions prior to 6.6.0 (e.g., via HTTP response headers, error pages, or framework fingerprinting tools like whatweb).
2. Craft malicious request: Construct an HTTP/1.1 POST request using chunked transfer encoding (Transfer-Encoding: chunked) with a body composed of millions of 1-byte chunks (e.g., 1\r\nx\r\n repeated millions of times, terminated with 0\r\n\r\n).
3. Send to target: Transmit the crafted request to any endpoint that reads the request body (i.e., any handler that does not reject the request before body parsing). No credentials are required.
4. Event loop starvation: The Tornado process begins parsing chunks synchronously without yielding to the event loop. With the default max_body_size of 100 MB, this can block the process for close to a minute, stalling all other connections.
5. Amplify attack: Repeat or parallelize requests from multiple connections to sustain the denial of service and exhaust server memory through chunk object accumulation (GitHub Advisory, Fix PR).

• Network: High volume of HTTP/1.1 POST (or other body-bearing) requests with Transfer-Encoding: chunked headers from a single or small set of source IPs; unusually long-lived HTTP connections with slow, fragmented body delivery.
• Application Behavior: Tornado process becomes unresponsive or severely degraded for all clients during active requests; event loop latency spikes observable via application monitoring.
• Logs: Tornado access logs showing requests with chunked bodies that take an abnormally long time to complete (approaching or exceeding 60 seconds); repeated requests from the same source IP targeting body-reading endpoints.
• System Resources: Sudden spikes in Python process memory consumption disproportionate to expected traffic volume; high CPU utilization in the Tornado worker process sustained over extended periods (GitHub Advisory).

Upgrade Tornado to version 6.6.0 or later, which fixes the issue by yielding to the event loop every 256 KB during body reads, coalescing small chunks, and using bytearray for body accumulation (Tornado Release). As a temporary workaround, deploy Tornado behind a reverse proxy (e.g., nginx, HAProxy) configured to buffer request bodies and forward them with a Content-Length header instead of chunked encoding, which prevents the malicious chunked body from reaching Tornado directly. Additionally, lowering max_body_size (globally or per-handler) reduces the maximum blocking duration and memory impact per request, though it does not fully eliminate the vulnerability (GitHub Advisory).

The vulnerability was reported by security researcher uttej-badwane and disclosed via GitHub's security advisory system by Tornado maintainer bdarnell. The fix was developed with assistance from Claude Opus 5.5 (AI-assisted development), as noted in the commit messages. No significant broader media coverage or notable community controversy has been identified beyond the standard advisory and release notes (GitHub Advisory, Fix PR).