CVE-2024-52804

What it actually does

Tornado versions prior to 6.4.2 use an HTTP cookie parsing algorithm that can exhibit quadratic-time behavior when processing specially crafted Cookie headers. Because Tornado performs this parsing in the event loop thread, a single request with a pathological cookie header can consume excessive CPU and block the event loop, delaying or preventing the application from processing other requests. The flaw affects availability rather than confidentiality or integrity; it does not directly enable code execution, authentication bypass, or data theft.

Why it matters to the business

Publicly reachable services built on vulnerable Tornado versions may be slowed or made unavailable by low-cost HTTP requests, causing user-facing outages, API timeouts, failed transactions, degraded service-level objectives, and increased infrastructure load. The issue is not listed in CISA KEV and has low EPSS at the time of assessment, but the exploit concept is simple and targets availability, so internet-facing Tornado applications should still be prioritized for upgrade, especially where downtime has material operational or revenue impact.

How an attack unfolds

An attacker identifies an HTTP endpoint served by a vulnerable Tornado application and sends requests containing maliciously structured Cookie headers designed to trigger inefficient parsing behavior. Tornado attempts to parse the cookie string on the main event loop thread; as the header size or structure grows, parsing time can increase disproportionately. While the event loop is occupied parsing the crafted header, normal request handling is blocked or delayed. Repeating these requests, or sending them concurrently, can drive CPU utilization high and cause broad request latency, timeouts, health-check failures, or service unavailability. No authentication is typically required if the targeted endpoint accepts unauthenticated HTTP requests and reaches Tornado's request parsing path.

How to fix it

Upgrade Tornado to version 6.4.2 or later. For source-based deployments using the upstream Git repository, ensure the code includes commit a5ecfab15e52202a46d34638aad93cddca86d87b or a later commit containing the fix. Rebuild and redeploy all affected applications, containers, virtual environments, and packaged services that include Tornado. As compensating controls until upgrades are complete, enforce reasonable maximum request header sizes at reverse proxies and load balancers, limit Cookie header length, rate-limit repeated requests with oversized Cookie headers, and ensure edge infrastructure can reject abnormal headers before traffic reaches Tornado. These mitigations reduce exposure but should not be treated as a substitute for upgrading.

How to confirm the fix worked

Confirm dependency versions in all runtime artifacts, not only source repositories. Use package inventory, lockfiles, container image scans, SBOMs, and runtime checks such as `python -c "import tornado; print(tornado.version)"` to verify Tornado is 6.4.2 or later. For Git-based vendored deployments, verify that commit a5ecfab15e52202a46d34638aad93cddca86d87b or a later fixed revision is present. Validate edge controls by sending benign test requests with oversized Cookie headers in a controlled environment and confirming they are rejected or handled without event-loop stalls, CPU spikes, or broad request latency. After remediation, monitor CPU utilization, request latency, 4xx/5xx rates, and reverse-proxy header rejection logs to confirm the service remains stable under abnormal Cookie traffic.

Typical attack path

1. Discover an application or API endpoint served by Tornado prior to version 6.4.2.
2. Send HTTP requests with unusually large or malformed Cookie headers crafted to trigger worst-case parsing complexity.
3. Cause Tornado's event loop thread to spend excessive CPU time parsing cookies.
4. Repeat or parallelize requests to sustain CPU saturation and event-loop blocking.
5. Induce user-visible latency, request timeouts, failed health checks, or denial of service.

How to detect it

Investigate whether the application experienced unexplained CPU saturation, event-loop lag, latency spikes, or availability incidents correlated with HTTP requests containing unusually large, repetitive, or malformed Cookie headers. Useful log sources include reverse-proxy access logs, WAF/API gateway logs, load balancer logs, application access logs, APM traces, host CPU metrics, container metrics, and error logs showing request timeouts or upstream failures. Search for requests with very large `Cookie:` header values, repeated cookie delimiters, unusually high cookie counts, long runs of semicolons or equals signs, and repeated requests from the same source IPs or autonomous systems immediately preceding service degradation. Because exploitation does not require a persistent payload, file artifact, or spawned process, detection is primarily behavioral: correlate abnormal Cookie headers with CPU spikes, event-loop blocking, increased response times, and elevated 5xx/timeout responses. If edge devices do not log request headers by default, review sampled request captures, WAF event details, APM request metadata, or packet captures where available.

• Cookie:
• ; ; ; ;
• Cookie header length
• request header too large
• large Cookie header
• oversized Cookie header
• upstream timed out
• upstream prematurely closed connection
• HTTP 502
• HTTP 503
• HTTP 504
• tornado.application
• tornado.access
• tornado.version < 6.4.2
• tornado==6.4.1
• tornado==6.4.0
• tornado==6.3.3
• tornado==6.3.2
• tornado==6.3.1
• tornado==6.3
• tornado==6.2
• tornado==6.1
• tornado==6.0

What your security team should do

• Inventory all applications, containers, serverless packages, and Python environments that include Tornado and identify versions prior to 6.4.2.
• Prioritize remediation for internet-facing Tornado services, authentication entry points, APIs, and services with strict availability requirements.
• Upgrade Tornado to 6.4.2 or later, or ensure Git-based deployments include commit a5ecfab15e52202a46d34638aad93cddca86d87b or later.
• Deploy temporary controls at reverse proxies, WAFs, API gateways, and load balancers to cap Cookie header size and reject abnormal request headers before they reach Tornado.
• Add monitoring and alerting for spikes in Cookie header length, repeated requests with oversized Cookie headers, elevated CPU, event-loop latency, request timeouts, and sudden increases in 499/500/502/503/504 responses.
• Review access logs and performance telemetry for historical signs of attempted denial-of-service activity using oversized or unusual Cookie headers.
• Include this vulnerability in dependency governance so builds fail or alert when Tornado versions older than 6.4.2 are introduced.