Key Takeaways
- HTTP smuggling exploits inconsistencies between front-end and back-end servers.
- CL.TE: Front uses Content-Length, back uses Transfer-Encoding.
- Can lead to cache poisoning, request hijacking, and auth bypass.
- PortSwigger's research made this attack class mainstream.
When a proxy and web server disagree on where a request ends, attackers can "smuggle" additional requests inside legitimate ones. This can bypass security controls and poison caches.
The Core Problem
HTTP/1.1 has two ways to specify message length:
- Content-Length: Fixed byte count
- Transfer-Encoding: Chunked encoding
When both headers are present, servers must prefer Transfer-Encoding. But not all do.
CL.TE Attack
POST / HTTP/1.1
Host: vulnerable.com
Content-Length: 13
Transfer-Encoding: chunked
0
GPOISONFront-end (Content-Length): Reads 13 bytes, forwards complete request.
Back-end (Transfer-Encoding): Sees chunk "0" (end), leaves "GPOISON" in buffer for next request!
TE.CL Attack
POST / HTTP/1.1
Host: vulnerable.com
Content-Length: 3
Transfer-Encoding: chunked
8
SMUGGLED
0Front-end (Transfer-Encoding): Reads chunked data, sends all.
Back-end (Content-Length): Only reads 3 bytes, "SMUGGLED" poisones next request!
Impact Examples
- Cache Poisoning: Smuggle malicious response to cache
- Request Hijacking: Steal other users' requests
- Auth Bypass: Add admin headers to smuggled request
- WAF Bypass: Hide malicious payloads
Detection & Prevention
- Normalize request parsing across all tiers
- Reject ambiguous requests (both CL and TE)
- Use HTTP/2 end-to-end (binary framing)
- Deploy consistent load balancer configurations
Frequently Asked Questions
How do I test for HTTP smuggling?
Use Burp Suite's HTTP Request Smuggler extension, or send differential timing requests. PortSwigger's labs are excellent for practice.
Master HTTP-level attacks.
Header Injection Guide