CVE-2024-14029: Tornado HTTP Request Smuggling Vulnerability

CVE-2024-14029 Overview

CVE-2024-14029 is an HTTP Request Smuggling vulnerability affecting the Tornado Python web framework in versions prior to 6.4.1. Tornado ignores duplicate Transfer-Encoding: chunked headers and treats the affected requests as having no message body. The framework then parses the chunked body as a subsequent request on the same connection. When Tornado is deployed behind a front-end proxy that interprets the headers differently, attackers can desynchronize the two parsers. The mismatch enables access control bypass, cache poisoning, and connection hijacking against other users sharing the proxy connection.

Critical Impact
Remote, unauthenticated attackers can smuggle HTTP requests through fronting proxies to bypass security controls, poison shared caches, and hijack in-flight requests from other clients.

Affected Products

Tornado web framework versions prior to 6.4.1
Applications deploying Tornado behind HTTP proxies or load balancers
Python services using Tornado's built-in HTTP server for request parsing

Discovery Timeline

2026-09-15 - CVE-2024-14029 published to the National Vulnerability Database
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2024-14029

Vulnerability Analysis

The vulnerability is classified as HTTP Request Smuggling under [CWE-444], Inconsistent Interpretation of HTTP Requests. Tornado's HTTP parser accepts a request that contains more than one Transfer-Encoding: chunked header instead of rejecting it. When duplicates are present, Tornado discards the transfer-encoding semantics and treats the request as having no body. The bytes that were intended as the chunked payload remain in the connection buffer and are then parsed as a separate, attacker-controlled HTTP request.

A fronting proxy that honors the first Transfer-Encoding header forwards the full chunked body to Tornado. Because the two parsers disagree on where one request ends and the next begins, the attacker gains the ability to prepend arbitrary requests to the traffic of the next client using the same upstream connection. This class of desynchronization has historically enabled authentication bypass, WAF evasion, and cache poisoning against downstream users.

Root Cause

The root cause is lenient parsing of duplicate Transfer-Encoding headers. RFC 7230 requires that any message with a Transfer-Encoding header be processed with chunked semantics or rejected. Tornado versions prior to 6.4.1 silently ignored the header when it appeared more than once, leaving the framework and any upstream proxy in disagreement about request boundaries.

Attack Vector

Exploitation requires network access to a Tornado application deployed behind a reverse proxy or load balancer that does not itself normalize duplicate Transfer-Encoding headers. The attacker sends a crafted request containing two Transfer-Encoding: chunked headers and a chunked body that encodes a smuggled second request. No authentication or user interaction is required. Full technical details are available in the GitHub Security Advisory GHSA-753j and the VulnCheck Tornado HTTP Request Smuggling Advisory.

// No verified proof-of-concept code is published for CVE-2024-14029.
// Refer to the linked security advisories for technical details.

Detection Methods for CVE-2024-14029

Indicators of Compromise

HTTP requests containing more than one Transfer-Encoding header, particularly duplicate chunked values
Unexpected HTTP verbs, paths, or Host headers appearing in access logs immediately following a chunked POST request on the same connection
Cache entries serving responses that do not match the requested URL or user context
Proxy and application logs showing mismatched request counts on the same upstream connection

Detection Strategies

Inspect front-end proxy logs for requests with duplicated Transfer-Encoding headers and alert on any occurrence
Compare request counts and byte offsets between the reverse proxy and Tornado application logs to identify desynchronization
Deploy request-smuggling detection signatures from your web application firewall or intrusion detection system
Review cache poisoning telemetry for anomalous cache keys or content-length mismatches

Monitoring Recommendations

Enable verbose HTTP header logging at the proxy tier for at least the duration of patch rollout
Alert on any client that submits requests containing multiple Transfer-Encoding headers
Monitor for spikes in HTTP 400 responses from Tornado after upgrading, which indicate the stricter parser rejecting malformed traffic
Correlate authentication and authorization decisions with source connection identifiers to detect smuggled requests bypassing access controls

How to Mitigate CVE-2024-14029

Immediate Actions Required

Upgrade Tornado to version 6.4.1 or later on all servers exposing HTTP endpoints
Audit reverse proxies, CDNs, and load balancers to confirm they reject or normalize duplicate Transfer-Encoding headers
Restart long-lived Tornado processes after upgrading to ensure the patched parser is loaded
Review recent access logs for evidence of smuggling attempts prior to patching

Patch Information

The Tornado maintainers fixed the parser in version 6.4.1 to reject requests containing conflicting or duplicated Transfer-Encoding headers. Users on any 6.x release below 6.4.1 must upgrade. Details are provided in the GitHub Security Advisory GHSA-753j.

Workarounds

Configure the fronting proxy to drop or reject any HTTP request containing more than one Transfer-Encoding header before it reaches Tornado
Terminate HTTP/1.1 keep-alive connections between the proxy and Tornado to limit the blast radius of desynchronization
Deploy a web application firewall rule that blocks requests presenting both Content-Length and Transfer-Encoding or duplicated Transfer-Encoding values

bash

# Example nginx configuration to reject duplicate Transfer-Encoding headers
# before proxying traffic to a Tornado upstream
http {
    map $http_transfer_encoding $bad_te {
        default          0;
        "~*chunked.*chunked" 1;
    }

    server {
        listen 443 ssl;

        if ($bad_te) {
            return 400;
        }

        location / {
            proxy_http_version 1.1;
            proxy_set_header Connection "";
            proxy_pass http://tornado_upstream;
        }
    }
}