Description

Tornado before 6.3.3 contains an HTTP request smuggling vulnerability due to improper parsing of Content-Length headers accepting non-standard characters. Attackers can send crafted HTTP requests with these characters to bypass proxy validation and smuggle requests when deployed behind certain proxies.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-15T16:17:05.777Z",
  "pubdate": "2026-09-15T16:17:05.777Z",
  "executiveSummary": "Tornado versions prior to 6.3.3 are susceptible to an HTTP request smuggling vulnerability arising from improper parsing of the Content-Length header. The flaw exists in how the library handles non-standard characters within the header value, leading to discrepancies in request boundary interpretation between the Tornado server and upstream proxy servers.\nThe vulnerability allows an attacker to bypass proxy-based security controls by crafting malicious HTTP requests that manipulate the request framing. By injecting non-standard characters, an attacker can cause the proxy and the backend server to disagree on the boundaries of a request. This desynchronization enables the smuggling of subsequent requests, potentially leading to unauthorized data access, security filter bypass, or cache poisoning.\nThis vulnerability is particularly critical for deployments where Tornado is situated behind a reverse proxy or load balancer. Successful exploitation does not typically require prior authentication, relying instead on the interaction between the proxy's parsing logic and Tornado's flawed header processing. Organizations utilizing Tornado in such architectures are at risk of compromised request integrity, necessitating an immediate upgrade to version 6.3.3 or higher to remediate the parsing logic error.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the HTTP request parsing logic within Tornado, specifically concerning the validation and interpretation of the Content-Length header. HTTP/1.1 specifications mandate that the Content-Length field must contain a sequence of digits representing the decimal value of the entity-body length. However, Tornado's parser was found to incorrectly accept and process non-standard characters within this field.\nIn a typical deployment scenario involving a reverse proxy, the proxy parses the incoming request and forwards it to the backend Tornado server. The security posture of the application often relies on the proxy's ability to accurately determine request boundaries. When a request contains a malformed Content-Length header with non-standard characters, the proxy may reject the request or interpret it according to its strict RFC compliance, while Tornado may inadvertently parse the header and incorrectly calculate the body size.\nThe exploitation flow functions as follows: An attacker sends a specially crafted request containing a malformed Content-Length header designed to trigger a desynchronization condition. For instance, the attacker might include characters that lead the proxy to interpret the request length differently than Tornado. If the proxy perceives a single request where Tornado perceives two (or vice-versa), the backend server might append the 'smuggled' portion of the request to the next legitimate request arriving from another user. This can result in the execution of unauthorized commands, leakage of sensitive data contained in subsequent requests, or the bypassing of path-based access controls enforced by the proxy.\nThe vulnerability persists throughout all Tornado versions prior to 6.3.3. It is not dependent on application-level authentication, as the parsing error occurs at the transport layer of the HTTP protocol stack before the application logic processes the request. The network exposure is broad, assuming the service is reachable via the vulnerable proxy infrastructure. The impact is significant, as it effectively breaks the trust model between the proxy and the backend, allowing attackers to tunnel malicious requests into the application's internal context, circumventing existing infrastructure-level security policies or firewall rules."
}