CVE-2025-67725

What it actually does

The flaw is an algorithmic complexity denial-of-service issue in Tornado's HTTP header handling. When Tornado receives an HTTP request containing many repeated instances of the same header name, its header coalescing logic can perform quadratic work as it repeatedly combines values. A remote unauthenticated client can therefore cause disproportionate CPU consumption and request-processing delays with relatively small crafted requests. The impact is availability degradation of Tornado-based HTTP services; it does not directly provide code execution, data disclosure, authentication bypass, or privilege escalation.

Why it matters to the business

Publicly reachable services built on affected Tornado versions may become slow or unavailable if attackers send crafted HTTP requests with large numbers of duplicate headers. This can affect customer-facing applications, APIs, internal dashboards, automation services, and any upstream systems that depend on those endpoints. The CVSS score is high for availability impact, but the current EPSS is low and the vulnerability is not listed in CISA KEV, so broad exploitation is not currently indicated; however, the issue is simple in concept and should be remediated during normal patch cycles, with higher urgency for internet-facing Tornado deployments or services without protective reverse proxies.

How an attack unfolds

An attacker identifies an HTTP service implemented with or backed by a vulnerable Tornado version. The attacker then sends specially crafted HTTP requests containing a very large number of repeated header fields, often using the same header name many times. As Tornado parses and coalesces those repeated headers, the vulnerable logic consumes CPU in a quadratic pattern relative to the number of repeated headers. By sustaining multiple such connections or sending repeated requests, the attacker can tie up request-processing capacity, increase latency, exhaust worker resources, and potentially make the service unavailable to legitimate users. No valid credentials or application-specific knowledge are generally required if the vulnerable endpoint is reachable over the network.

How to fix it

Upgrade Tornado to a version that includes commit 38014ddb51520ff7762c1d55535925dba2cdbe31 or to the first official release containing that fix when available through the package manager in use. For source-based deployments, ensure the tornadoweb/tornado Git dependency is pinned at or after commit 38014ddb51520ff7762c1d55535925dba2cdbe31. Rebuild and redeploy all applications, containers, serverless artifacts, and virtual environments that vendor or bundle Tornado. As compensating controls, enforce limits on maximum request-header count and total header size at edge proxies, load balancers, API gateways, and WAFs; drop requests with excessive duplicate header names; apply connection and request-rate limits; and ensure Tornado services are not directly exposed when a hardened reverse proxy can enforce protocol limits first.

How to confirm the fix worked

Confirm the runtime Tornado version or source commit used by deployed applications and verify it includes commit 38014ddb51520ff7762c1d55535925dba2cdbe31 or a later fixed release. Inspect dependency lockfiles, container images, vendored libraries, and build artifacts to ensure no vulnerable Tornado copy remains. Validate edge controls by sending a benign test request with an intentionally high number of duplicate headers in a non-production or controlled environment and confirming that the proxy rejects or limits the request before it reaches Tornado, or that the patched Tornado service handles it without abnormal CPU growth. Monitor CPU utilization, request latency, 4xx rejection rates, and application error rates during validation to confirm the mitigation behaves as expected.

Typical attack path

1. Discover a reachable HTTP or HTTPS endpoint served by a Tornado-based application.
2. Confirm the endpoint accepts requests directly or through a proxy that forwards many duplicate headers.
3. Send requests containing unusually high counts of repeated HTTP headers with the same header name.
4. Increase request rate, connection count, or duplicate-header count to maximize CPU cost on the server.
5. Maintain the traffic pattern until application latency increases, health checks fail, workers saturate, or the service becomes unavailable.

How to detect it

To determine whether exploitation has already occurred, review edge proxy, load balancer, WAF, web server, and Tornado application logs for requests with unusually large numbers of headers or repeated instances of the same header name from the same source IP, autonomous system, user agent, or URI pattern. Look for correlated spikes in application CPU utilization, request latency, upstream timeout errors, connection resets, 400/413/431 responses, and health-check failures without a corresponding increase in normal request volume. If full request headers are logged by a proxy or WAF, search for individual requests containing dozens or hundreds of duplicate header names such as repeated X-Forwarded-For, Forwarded, Cookie, Accept, Accept-Encoding, X-Real-IP, or custom X-* headers. In application telemetry, investigate periods where Tornado processes show high CPU with low throughput, increased event-loop latency, or worker saturation. Packet captures or HTTP access logs from the suspected window can be used to confirm whether requests contained excessive duplicate headers. Because the vulnerability is a denial-of-service condition, successful exploitation may leave limited host artifacts beyond traffic logs and resource-utilization telemetry.

• HTTP requests with repeated header name: X-Forwarded-For
• HTTP requests with repeated header name: Forwarded
• HTTP requests with repeated header name: X-Real-IP
• HTTP requests with repeated header name: Accept
• HTTP requests with repeated header name: Accept-Encoding
• HTTP requests with repeated header name: Cookie
• HTTP requests with repeated header name: User-Agent
• HTTP requests with repeated header name: X-Requested-With
• HTTP status 431
• Request Header Fields Too Large
• upstream timed out
• upstream prematurely closed connection
• Tornado
• tornado.access
• tornado.application

What your security team should do

• Inventory applications and services using Tornado, including direct dependencies, transitive dependencies, vendored source, and container images.
• Prioritize patching internet-facing Tornado services, high-traffic APIs, and services that do not sit behind a proxy enforcing header-count and header-size limits.
• Upgrade Tornado to a fixed commit or fixed release containing 38014ddb51520ff7762c1d55535925dba2cdbe31, then rebuild and redeploy affected artifacts.
• Configure reverse proxies, load balancers, API gateways, and WAFs to reject requests with excessive total headers, excessive header size, or abnormal duplicate-header counts.
• Add monitoring for spikes in CPU usage, request latency, open connections, 400/431 responses, and requests containing unusually many repeated header names.
• Review recent web, proxy, and application logs for evidence of repeated-header request floods or unexplained short-lived CPU saturation events.
• Include this condition in HTTP-layer DoS test cases and regression tests for Tornado-based services.