HTTP request smuggling exploits a fundamental weakness in layered web architecture: when a frontend proxy and backend server disagree about where one HTTP request ends and another begins, an attacker can hide a second request inside what appears to be a single transmission. The proxy forwards what it believes is one benign request, while the backend interprets the payload as two separate requests—the second one attacker-controlled and unseen by security filters.

The Protocol Ambiguity

HTTP/1.1 offers two mechanisms for determining request boundaries: Content-Length headers specify exact byte counts, while Transfer-Encoding: chunked uses length-prefixed segments. The problem emerges when both appear in the same request, or when intermediaries implement parsing logic differently.

Consider a request with both headers. RFC 7230 states that Transfer-Encoding should take precedence, but not every HTTP implementation follows this strictly. A proxy might honor Content-Length while the backend respects Transfer-Encoding. This disagreement creates a desynchronization—the proxy sees one request ending at position X, while the backend thinks it ends at position Y. Everything after position X becomes orphaned bytes that the backend interprets as the start of a new request.

CL.TE and TE.CL Variants

The two primary attack patterns correspond to which system prioritizes which header. In CL.TE smuggling, the frontend uses Content-Length while the backend uses Transfer-Encoding. An attacker crafts a request where the Content-Length covers only part of the chunked payload. The frontend forwards everything, believing it to be a single request body. The backend processes the chunked encoding and discovers additional data—which it queues as the beginning of the next request.

TE.CL attacks reverse this: the frontend processes chunked encoding while the backend falls back to Content-Length. The attacker sends a chunked request that claims to be zero bytes when interpreted via Content-Length. The frontend sees a complete chunked transmission and forwards it. The backend reads only the Content-Length bytes and leaves the rest in the TCP stream, where it gets prepended to the next legitimate user’s request.

Request Routing and Poisoning

The practical impact extends beyond simple injection. Because connection reuse is standard in HTTP/1.1, a smuggled request doesn’t just affect the attacker’s own session—it hijacks the connection socket itself. The next request from any user sharing that backend connection will have the attacker’s injected prefix.

This enables request routing attacks where a smuggled Host header or path can redirect the next user to attacker-controlled endpoints. It bypasses frontend access controls since the malicious routing happens at the backend after authentication and authorization checks. Cache poisoning becomes possible when the smuggled request targets cacheable resources with attacker-controlled headers, serving malicious responses to subsequent users.

Defense Through Strict Parsing

Mitigation requires eliminating ambiguity. Proxies and application servers should reject requests containing both Content-Length and Transfer-Encoding, rather than attempting to prioritize one. HTTP/2 eliminates this class of vulnerability entirely by using length-prefixed frames with unambiguous boundaries, though HTTP/2 downgrade to HTTP/1.1 can reintroduce risk if not carefully managed.

Web application firewalls positioned inline can normalize requests, but this only works if the WAF’s parsing logic exactly matches the backend’s—otherwise the WAF itself becomes an exploitable desynchronization point. The most reliable approach is defense in depth: disable connection reuse for untrusted requests, implement strict HTTP parsing libraries that reject malformed edge cases, and configure timeouts to prevent orphaned data from persisting across requests.

Modern infrastructure increasingly defaults to HTTP/2 and HTTP/3, which remove the ambiguous framing that enables smuggling. But legacy HTTP/1.1 deployments remain widespread, particularly in complex proxy chains involving CDNs, load balancers, and reverse proxies. Each hop in the chain represents a potential parsing inconsistency. Understanding how protocol-level ambiguity translates to exploitable behavior is essential for operating web infrastructure that can’t simply assume well-formed input.