Cybersecurity glossary
What is HTTP Request Smuggling?
Learn what HTTP request smuggling is, how conflicting Content-Length and Transfer-Encoding parsing desynchronizes proxies and origins, and how it differs from request splitting.
Definition
HTTP request smuggling is an attack in which inconsistent HTTP/1.1 message-boundary parsing between a frontend (proxy, CDN, WAF) and a backend causes one TCP stream to be interpreted as multiple requests, enabling cache poisoning, credential theft, and security bypass.
Why HTTP request smuggling matters
Most production sites sit behind at least one reverse proxy, CDN, or WAF. Each layer must parse HTTP/1.1 messages the same way. When they do not, attackers can slip a second request into a connection that security controls never evaluate as a separate message.
HTTP request smuggling is the classic desync pattern built on conflicting Content-Length and Transfer-Encoding handling. The impact ranges from cache poisoning to stealing other users’ credentials from pipelined connections.
How request smuggling works
Find a parsing mismatch
Identify a frontend that honors Content-Length while the backend honors Transfer-Encoding, or the reverse.
Craft an ambiguous message
Send a request with both length fields or malformed chunk boundaries that each layer interprets differently.
Frontend consumes partial bytes
The proxy treats trailing bytes as body or connection padding and forwards the connection for reuse.
Backend sees a second request
The origin parses leftover bytes as the start of a new HTTP request queued on the same connection.
Exploit the desync
Poison caches, bypass WAF rules, or prepend attacker-controlled requests ahead of victim traffic.
Harden the parser chain
Reject ambiguity, align parsers, patch known CVEs, and retest through the real edge path.
Common attack variants
CL.TE
Frontend uses Content-Length; backend uses chunked encoding. Short CL leaves smuggled bytes for the origin.
TE.CL
Frontend honors Transfer-Encoding; backend trusts Content-Length. Chunk tricks hide a second request.
TE.TE
Both sides support chunked encoding but normalize obfuscated Transfer-Encoding values differently.
HTTP/2 downgrade
Gateways translate HTTP/2 to HTTP/1.1 and reintroduce boundary ambiguity at the origin.
Smuggling vs splitting vs response attacks
| Term | Direction | Typical mechanism |
|---|---|---|
| HTTP request smuggling | Inbound (client → server) | CL/TE or TE/TE parsing disagreement between proxy and origin |
| HTTP request splitting | Inbound | CRLF injection or unsafe concatenation creating multiple requests in one stream |
| HTTP response smuggling | Outbound (server → client) | Desync on response boundaries so clients or caches see extra responses |
| HTTP response splitting | Outbound | Injected CRLF in response headers splits one response into two messages |
Prevention checklist
- Reject requests that contain both Content-Length and Transfer-Encoding unless your stack has a single, documented resolution rule.
- Normalize and validate HTTP/1.1 messages once at a trusted edge before backends see them.
- Disable connection reuse on paths where frontend and backend parsers cannot be proven equivalent.
- Keep reverse proxies, CDNs, WAFs, and origin servers patched for known desync CVEs.
- Prefer HTTP/2 end-to-end where possible; harden every HTTP/2-to-HTTP/1.1 translation point.
- Never build raw HTTP requests with string concatenation from untrusted input.
- Include desync and smuggling tests in authorized penetration tests that traverse the production edge.
- Monitor for unexpected internal route hits, chained requests, and cache integrity anomalies.
Limits and pitfalls
Request smuggling defenses fail when only one layer is patched. A hardened origin behind a lenient CDN still desyncs. HTTP/2 on the client edge does not help if the origin speaks HTTP/1.1 with ambiguous reuse.
Teams also confuse request smuggling with request splitting. Splitting describes the outcome (multiple requests in one stream); smuggling names the CL/TE-style intermediary disagreement that causes it. Both are serious, but remediation and test payloads differ.
The practical takeaway
HTTP request smuggling turns parser disagreement into a covert second request. When a proxy and an origin do not share one definition of where a message ends, attackers queue malicious traffic that WAFs never inspect and caches may store.
Treat your CDN-to-origin path as a single security-critical parser chain: reject ambiguity, align behavior, patch intermediaries, and verify with authorized tests on the real infrastructure—not only on a local dev server.
Related security terms
HTTP Request Splitting
A related technique that injects extra requests via CRLF or unsafe concatenation rather than CL/TE ambiguity.
Web Cache Poisoning
A common impact when smuggled requests poison shared caches.
Reverse Proxy
An intermediary whose parsers must agree with the origin on request boundaries.
Web Application Firewall (WAF)
A security layer that can disagree with the origin about where a request ends.
Frequently asked questions
What is HTTP request smuggling in simple terms?
Request smuggling happens when a proxy and an origin server disagree about where one HTTP request ends. Attackers craft a single message so the proxy sees one request while the origin sees two, hiding a malicious second request in the stream.
How is request smuggling different from request splitting?
Request splitting is the broader outcome—one stream interpreted as multiple requests—often via CRLF injection or unsafe string concatenation. Request smuggling specifically exploits inconsistent Content-Length and Transfer-Encoding parsing between intermediaries and backends.
What is a CL.TE attack?
CL.TE means the frontend honors Content-Length while the backend honors Transfer-Encoding: chunked. The attacker sets a short Content-Length so the proxy stops early, leaving bytes the backend treats as a new request.
What is a TE.CL attack?
TE.CL is the reverse: the frontend uses chunked encoding while the backend trusts Content-Length. The attacker crafts chunk boundaries so leftover bytes become a smuggled request on the origin side.
Does HTTP/2 stop request smuggling?
HTTP/2’s binary framing removes classic HTTP/1.1 CL/TE ambiguity on that hop, but gateways that downgrade to HTTP/1.1, legacy origins, and translation bugs can reintroduce desync risk.
How do you prevent HTTP request smuggling?
Reject ambiguous requests, normalize HTTP at a single trusted edge, disable HTTP/1.1 connection reuse when parsers disagree, keep proxies patched, and test the real CDN-to-origin path in authorized assessments.
References
Explore authoritative guidance and frameworks related to http request smuggling.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.