Skip to main content
Application Security Standards
Category: Attack Techniques

HTTP Request Smuggling

Also known as: HRS, HTTP desync attack, request smuggling
Simply put

HTTP request smuggling is a web attack that exploits differences in how two or more servers (such as a front-end proxy and a back-end server) interpret where one HTTP request ends and the next one begins. By crafting a specially formed request, an attacker can cause the front-end and back-end to disagree on request boundaries, effectively "smuggling" a hidden request past security controls. This can lead to bypassing access controls, poisoning web caches, hijacking other users' requests, or enabling further attacks like cross-site scripting.

Formal definition

HTTP Request Smuggling is a class of vulnerabilities arising from inconsistencies in how chained HTTP processors (typically a front-end proxy or load balancer and a back-end origin server) parse request boundaries. In the classic HTTP/1.1 variant, the attack exploits ambiguity between the Content-Length and Transfer-Encoding headers: when two intermediaries disagree on which header delimits the message body, an attacker can craft a request such that the front-end forwards bytes that the back-end interprets as the beginning of a subsequent, attacker-controlled request. Common variants include CL.TE (front-end uses Content-Length, back-end uses Transfer-Encoding), TE.CL (the reverse), and TE.TE (both use Transfer-Encoding but can be manipulated via header obfuscation to process it differently). Successful exploitation may result in security control bypass, web cache poisoning, session hijacking of co-located users, credential theft, or chaining with other attack classes such as XSS. While HTTP/2's binary framing eliminates the specific Content-Length versus Transfer-Encoding ambiguity of HTTP/1.1, request smuggling vulnerabilities have been demonstrated in HTTP/2 environments as well, particularly where HTTP/2-to-HTTP/1.1 downgrading occurs or through implementation-specific flaws in HTTP/2 parsers themselves. Mitigations typically include normalizing request parsing across all layers, rejecting ambiguous requests, disabling HTTP/1.0 and connection reuse where feasible, and ensuring consistent protocol handling end-to-end, though no single measure fully eliminates the risk across all deployment configurations.

Why it matters

HTTP Request Smuggling poses a significant threat because it undermines the fundamental trust model of layered web architectures. Modern web applications almost universally rely on chains of HTTP processors, including load balancers, reverse proxies, CDNs, and web application firewalls, all sitting in front of back-end origin servers. When an attacker can cause these components to disagree on where one request ends and the next begins, the consequences cascade: security controls enforced at the front-end layer can be bypassed entirely, allowing smuggled requests to reach the back-end as if they were legitimate. This means that access controls, authentication checks, and WAF rules may all be rendered ineffective against a well-crafted smuggling payload.

The impact extends beyond a single attacker's session. Because smuggled requests can be prepended to other users' legitimate requests on shared persistent connections, exploitation can result in session hijacking, credential theft, and the ability to serve poisoned content from web caches to a broad population of users. Cache poisoning, in particular, can amplify the attack's reach dramatically, turning a single smuggled request into a persistent threat affecting every visitor who receives the poisoned cached response. The attack can also be chained with other vulnerability classes such as cross-site scripting (XSS) or open redirects, increasing overall severity.

The risk is not confined to legacy HTTP/1.1 deployments. While HTTP/2's binary framing removes the specific Content-Length versus Transfer-Encoding ambiguity that defines the classic HRS variants, request smuggling vulnerabilities have been demonstrated in HTTP/2 environments as well, particularly in scenarios involving HTTP/2-to-HTTP/1.1 downgrading and through implementation-specific flaws in HTTP/2 parsers themselves. This means that organizations cannot assume migration to HTTP/2 alone is sufficient to eliminate the attack surface.

Who it's relevant to

Web Application Developers
Developers building applications that sit behind reverse proxies, CDNs, or load balancers need to understand how their code interacts with upstream infrastructure. Ensuring that applications reject ambiguous requests, avoid reliance on assumptions about request boundaries, and handle edge cases in header parsing reduces exposure to smuggling attacks.
Infrastructure and Platform Engineers
Teams responsible for deploying and configuring reverse proxies, load balancers, and CDN layers must ensure consistent HTTP parsing behavior across all components in the request chain. This includes keeping proxy software up to date, normalizing request handling, disabling connection reuse where feasible, and rejecting requests with conflicting Content-Length and Transfer-Encoding headers.
Application Security Engineers and Penetration Testers
Security practitioners need to include request smuggling in their testing methodologies for any application served through layered HTTP infrastructure. Detecting HRS typically requires specialized tooling and manual analysis, as standard DAST scanners may not reliably identify desync conditions. Understanding the classic CL.TE, TE.CL, and TE.TE variants, as well as HTTP/2-specific smuggling vectors, is essential for thorough assessment.
WAF and Security Control Vendors
Vendors building inline HTTP security products must account for the possibility that their parsing of request boundaries may differ from that of the back-end servers they protect. A WAF that processes Content-Length differently from the origin server can itself become the front-end component that enables a smuggling attack rather than preventing one.
DevSecOps and Cloud Architects
Teams designing deployment pipelines and cloud-native architectures should evaluate the HTTP parsing behavior of every component in the request path, including service meshes, API gateways, and serverless function invocation layers. Protocol downgrading from HTTP/2 to HTTP/1.1 at any point in the chain introduces potential smuggling vectors that require explicit mitigation.

Inside HRS

Content-Length / Transfer-Encoding Ambiguity
The core mechanism in HTTP/1.1 smuggling, where an attacker crafts a request containing both Content-Length and Transfer-Encoding headers (or malformed variants) so that a front-end server and a back-end server disagree on where one request ends and the next begins.
CL.TE and TE.CL Variants
Classification of smuggling attacks based on which header the front-end and back-end servers prioritize. In a CL.TE attack, the front-end uses Content-Length while the back-end uses Transfer-Encoding. In TE.CL, the roles are reversed. Each variant exploits the parsing discrepancy differently.
TE.TE Obfuscation
A variant where both servers support Transfer-Encoding, but the attacker obfuscates the header (e.g., with extra whitespace, unusual casing, or duplicate headers) so that one server processes it and the other ignores it, falling back to Content-Length.
Request Boundary Desynchronization
The fundamental effect of a smuggling attack: the front-end proxy and the back-end server parse different boundaries between HTTP requests on a shared TCP connection, allowing the attacker to prepend or inject content into another user's request.
Connection Reuse (Keep-Alive / Pipelining)
Smuggling typically requires that the TCP connection between the front-end and back-end is reused for multiple requests. Without connection reuse, the smuggled content has no subsequent request stream to corrupt.
Impact Payloads
Once desynchronization is achieved, attackers may poison web caches, bypass access controls, hijack other users' requests, or perform credential theft by causing a victim's request to be appended to an attacker-controlled prefix.

Common questions

Answers to the questions practitioners most commonly ask about HRS.

Doesn't using a single server or proxy eliminate HTTP request smuggling risks?
Not necessarily. While the classic attack exploits disagreements between two or more HTTP processors (such as a front-end proxy and a back-end server), smuggling-like vulnerabilities can arise wherever HTTP message boundaries are parsed. Even architectures with a single visible proxy may involve internal components, load balancers, or embedded parsing layers that interpret requests differently. The core risk exists whenever more than one entity parses the same HTTP stream, and in complex deployments this is common even when the architecture appears simple.
Does adopting HTTP/2 end-to-end eliminate HTTP request smuggling?
HTTP/2's binary framing removes the specific Content-Length versus Transfer-Encoding ambiguity that enables classic HTTP/1.1 smuggling. However, HTTP/2 does not eliminate request smuggling as a category. Practical smuggling vulnerabilities have been demonstrated in pure HTTP/2 implementations (for example, CVE-2021-21295, CVE-2021-21409, and CERT VU#357312). These arise from issues such as improper handling of pseudo-headers, header validation flaws, or protocol downgrade behaviors. Additionally, many HTTP/2 front ends still translate requests to HTTP/1.1 for back-end communication, reintroducing the classic attack surface. HTTP/2 adoption reduces but does not remove the risk.
How can I test my infrastructure for HTTP request smuggling vulnerabilities?
Testing typically involves sending crafted requests with conflicting Content-Length and Transfer-Encoding headers, or malformed chunked encoding, and observing whether the front-end and back-end disagree on message boundaries. Specialized tools such as Burp Suite's HTTP Request Smuggler extension and smuggler.py automate common probe techniques. Static analysis tools generally cannot detect these vulnerabilities because the issue depends on runtime behavior across multiple deployed components. Testing should cover CL.TE, TE.CL, and TE.TE desync variants, and should also probe HTTP/2 environments for header-based smuggling vectors. False negatives are common when timing-based detection is used, since network conditions can obscure desync signals.
What specific configuration steps help prevent HTTP request smuggling at the proxy layer?
Key steps include configuring front-end proxies to normalize and strictly validate incoming requests before forwarding, rejecting ambiguous requests that contain both Content-Length and Transfer-Encoding headers, and ensuring that all components in the chain use identical HTTP parsing behavior. Where possible, configure proxies to use HTTP/2 or unique per-request connections to back ends to limit connection reuse as an attack vector. Disabling connection reuse between the front-end and back-end eliminates some smuggling variants but may impose a performance cost. Each proxy and server product has its own parsing quirks, so testing specific deployments remains essential.
Which categories of HTTP request smuggling are hardest to detect with automated scanning?
TE.TE variants, where both the front-end and back-end support Transfer-Encoding but differ in how they handle obfuscated or malformed chunked encoding, are typically the hardest to detect. The number of possible obfuscation techniques (extra whitespace, capitalization variations, trailing characters) creates a large search space. HTTP/2-specific smuggling vectors that exploit header validation inconsistencies are also poorly covered by most automated tools as of current generations. False negatives are a known limitation: scanners may miss vulnerabilities that only manifest under specific timing conditions or with particular back-end implementations.
How should development and operations teams coordinate to mitigate HTTP request smuggling?
Development teams should ensure that application-level code does not rely on raw HTTP parsing and should use well-maintained HTTP libraries that reject ambiguous requests. Operations teams should enforce strict HTTP parsing configurations on all proxies, load balancers, and web servers, and should ensure that all components in the request chain are updated consistently, since patches to one component may change parsing behavior relative to others. Joint testing during deployment changes is important because smuggling vulnerabilities are emergent properties of how specific component versions interact in a given configuration. Monitoring for anomalous request patterns, such as unexpected request boundaries or duplicated headers in access logs, can help detect exploitation attempts.

Common misconceptions

Adopting HTTP/2 end-to-end eliminates request smuggling vulnerabilities entirely.
While HTTP/2's binary framing removes the specific Content-Length vs. Transfer-Encoding ambiguity of HTTP/1.1, request smuggling vulnerabilities have been demonstrated in pure HTTP/2 implementations (e.g., CVE-2021-21295, CVE-2021-21409, CERT VU#357312). HTTP/2 downgrade scenarios, where a front-end speaks HTTP/2 but translates to HTTP/1.1 for back-end communication, also introduce smuggling risks. HTTP/2 reduces but does not eliminate the attack surface.
A WAF or reverse proxy in front of the application is sufficient to prevent request smuggling.
WAFs and reverse proxies can themselves be one side of the parsing disagreement that enables smuggling. If the WAF parses request boundaries differently from the back-end server, it may actually be the component that makes smuggling possible. Mitigation requires consistent parsing across all components in the request chain, not just the addition of another intermediary.
Request smuggling only matters for applications that handle sensitive data or authentication.
Smuggling can be leveraged for web cache poisoning, which affects all users of the cache regardless of authentication state. It can also be chained with other vulnerabilities such as open redirects or reflected XSS to escalate impact. Any application behind a multi-tier HTTP architecture may be at risk.

Best practices

Normalize HTTP parsing behavior across all components in the request chain (load balancers, reverse proxies, application servers) by using the same HTTP parsing library or by configuring each component to reject ambiguous requests containing both Content-Length and Transfer-Encoding headers.
Configure front-end servers to reject requests with duplicate, malformed, or obfuscated Transfer-Encoding headers rather than attempting to interpret them, reducing the attack surface for TE.TE variants.
Disable HTTP connection reuse (keep-alive) between the front-end and back-end where feasible, or use per-request connection isolation for sensitive endpoints, recognizing that this may have performance trade-offs.
Deploy active smuggling detection by sending crafted differential requests (CL.TE and TE.CL probes) in pre-production testing environments to identify parsing discrepancies before they reach production.
When using HTTP/2 at the edge with HTTP/1.1 back-ends, ensure the translation layer strictly validates and rewrites request framing rather than passing through ambiguous header combinations. Be aware that even pure HTTP/2 deployments may have implementation-specific smuggling vulnerabilities and should be kept up to date with security patches.
Monitor for anomalous request patterns in server logs, such as unexpected request prefixes, malformed chunked encoding, or requests that appear to contain embedded secondary requests, as these may indicate smuggling attempts or successful exploitation.