HTTP request smuggling exploits a desync between a front-end (proxy/load balancer) and back-end server that disagree on request boundaries - rooted in ambiguity between the Content-Length and Transfer-Encoding headers. The classic variants: CL.TE, TE.CL, TE.TE. A crafted request the front-end sees as one and the back-end splits as two lets the attacker prepend content to the next user's request - enabling session/credential capture, WAF and access-control bypass, and cache poisoning. It's typically high/critical when confirmed. The strongest fixes are architectural: HTTP/2 end to end, identical boundary parsing, rejecting ambiguous requests, and patching. Detail below.
// 01 How the desync happens
Most web apps sit behind a chain: a front-end (CDN, load balancer, reverse proxy) forwards requests to a back-end server, often reusing a single connection for many users' requests. For that to work, both must agree on where each request ends. HTTP gives two ways to state a request body's length: the Content-Length header (a byte count) and Transfer-Encoding: chunked (the body is sent in chunks with its own end marker). Trouble begins when a request contains both, or an obfuscated version, and the two servers resolve the ambiguity differently - one honours Content-Length, the other Transfer-Encoding. Now they disagree about where the request ends. The attacker exploits that gap: they send a request the front-end reads as one message but the back-end reads as two. The leftover “second” message is smuggled - it waits on the connection and gets glued to whatever request comes next, which may be another user's.
// 02 The variants: CL.TE, TE.CL, TE.TE
Front CL, back TE
Front-end honours Content-Length, back-end honours Transfer-Encoding. The back-end sees an extra chunked request the front-end didn't.
Front TE, back CL
The reverse - front-end reads chunked, back-end reads Content-Length - producing a different split.
Both TE, one fooled
Both support Transfer-Encoding, but an obfuscated header induces one to ignore it, recreating the mismatch.
HTTP/2 downgrade
Modern variants abuse HTTP/2-to-HTTP/1 downgrades at the front-end to reintroduce ambiguity.
The naming is simply which server honours which header. Each mismatch gives the attacker a reliable way to make the two ends interpret one request differently - the whole game.
// 03 What an attacker gains
Request smuggling is dangerous because it operates below the application and affects other users' traffic. With a working desync an attacker can: capture other users' requests - including their session tokens and credentials - by making the victim's request complete the attacker's smuggled prefix and reflect back; bypass front-end security controls, slipping a request to a restricted path or past WAF rules the front-end enforces but the back-end doesn't re-check; poison the web cache, so a malicious response gets stored and served to many users; and perform request hijacking and response-queue poisoning. Because a single flaw can compromise other users at scale and defeat perimeter defences, confirmed smuggling is rated high or critical - and it's exactly the kind of infrastructure-level chain a manual tester pursues that a scanner won't.
// 04 How to test for it
Detection is careful and timing-based. The tester sends deliberately ambiguous requests - both Content-Length and Transfer-Encoding, or obfuscated TE headers - and observes for evidence of a desync: characteristically, a time delay when the back-end waits for bytes that never arrive (the smuggled request “holds” the connection), or a differential response where a follow-up request returns something influenced by the smuggled prefix. Confirmation must be done safely, because probing a live shared connection can affect real users - so testing is controlled and scoped in the rules of engagement. Specialist tooling automates detecting CL.TE/TE.CL/TE.TE and HTTP/2 variants, but interpreting the timing signals and proving impact without disrupting production is the human part - part of every thorough web application test.
// 05 How to fix it
The durable fixes are architectural, because smuggling is a parsing-agreement problem. Best of all: use HTTP/2 end to end where possible - its unambiguous, length-prefixed framing removes the Content-Length/Transfer-Encoding ambiguity that enables classic smuggling (and avoid HTTP/2-to-HTTP/1 downgrades that reintroduce it). Where HTTP/1 remains: make the front-end and back-end parse boundaries identically and reject ambiguous requests that contain both headers rather than guessing; disable connection reuse between front-end and back-end where feasible so a smuggled request can't reach another user; normalise or reject malformed requests at the edge; and keep servers and proxies patched, since vendors regularly fix parsing discrepancies. Together these close the seam the attack lives in. Engagements follow our methodology, with findings reproduced safely and mapped to concrete fixes.
// 06 Frequently asked questions
What is HTTP request smuggling?
An attack exploiting inconsistencies in how a chain of servers - typically a front-end proxy and a back-end server - parse the boundaries between HTTP requests. When they disagree about where one request ends, an attacker crafts an ambiguous request the front-end sees as one and the back-end splits into two; the extra portion is prepended to the next user's request. It arises from ambiguity between Content-Length and Transfer-Encoding.
What are the CL.TE, TE.CL and TE.TE variants?
They describe which header each server honours when both Content-Length (CL) and Transfer-Encoding (TE) are present. CL.TE: front-end uses CL, back-end uses TE; TE.CL: the reverse; TE.TE: both use TE but one is induced to ignore it via obfuscation. Each mismatch lets an attacker construct a request the two servers interpret differently. Modern tools automate detection.
What can an attacker do with it?
Capture other users' requests including credentials or session tokens, bypass front-end controls like access restrictions and WAF rules, poison web caches to serve malicious content to other users, and perform request hijacking or response-queue poisoning. Because it operates at the infrastructure layer and affects other users' traffic, it's typically high or critical when confirmed.
How do you prevent it?
Use HTTP/2 end to end where possible - its unambiguous framing removes the header ambiguity; ensure front-end and back-end parse boundaries identically and reject ambiguous requests with both headers; disable connection reuse between front-end and back-end where feasible; and keep servers and proxies patched. Normalising or rejecting malformed requests at the edge closes most avenues.
// 07 Related reading
- Session management testing — what smuggling steals.
- OWASP Top 10 in real engagements and subdomain takeover.
- Web application penetration testing and our methodology.