Introduction
Imagine an attack capable of bypassing your WAF, stealing other users' sessions, and compromising your infrastructure, all without triggering a single alert. This isn't science fiction, it's HTTP Request Smuggling.
This attack technique, rediscovered and refined in recent years by researchers like James Kettle from PortSwigger, exploits inconsistencies between frontend servers (reverse proxies, load balancers, CDNs) and backend servers in their interpretation of HTTP requests.
In 2024-2025, with the multiplication of distributed architectures and CDNs, this vulnerability is more relevant than ever. Yet it remains unknown to most development teams.
How does HTTP Request Smuggling work?
The fundamental problem
The HTTP/1.1 protocol allows two methods to define request length:
- Content-Length (CL): Specifies the exact body size in bytes
- Transfer-Encoding: chunked (TE): The body is sent in chunks, terminated by a size 0 chunk
RFC 2616 states that if both headers are present, Transfer-Encoding should take precedence. But in practice? Each server implements this rule differently.
Attack variants
CL.TE (Content-Length then Transfer-Encoding)
The frontend uses Content-Length, the backend uses Transfer-Encoding.
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
The frontend reads 13 bytes and transmits everything. The backend sees chunk 0\r\n\r\n as end of request, and SMUGGLED becomes the start of a new request.
TE.CL (Transfer-Encoding then Content-Length)
The frontend uses Transfer-Encoding, the backend uses Content-Length.
TE.TE (Transfer-Encoding Obfuscation)
Both servers support Transfer-Encoding, but one can be tricked by obfuscation.
Real exploitation scenarios in 2025
1. WAF and security controls bypass
Context: An application protected by Cloudflare/AWS WAF blocks requests containing malicious patterns.
The request to /admin bypasses the WAF because it's never analyzed as a separate request by the frontend.
Real impact: In 2024, this technique allowed bypassing protections of several major SaaS platforms to access administration endpoints.
2. User session theft (Request Hijacking)
Context: The attacker "poisons" the request pipeline to capture another user's request, exposing their cookies, tokens, and authentication headers.
3. Cache Poisoning via Smuggling
Context: A CDN caches responses based on URL.
The attacker can cache a malicious response for a legitimate JavaScript file, infecting all subsequent visitors with malicious code.
4. Microservices architecture exploitation
Modern context: API Gateway → Load Balancer → Backend Services
Cloud native architectures multiply HTTP interpretation points, increasing attack surface.
Detection: How to identify this vulnerability?
Timing detection technique
If the server is vulnerable CL.TE, it waits for the next chunk → observable timeout.
Detection tools
- Burp Suite Pro: "HTTP Request Smuggler" extension by James Kettle
- smuggler.py: Open-source automated detection tool
- h2csmuggler: For HTTP/2 → HTTP/1.1 downgrade variants
HTTP/2 Smuggling: The new frontier
HTTP/2 was supposed to eliminate smuggling thanks to its binary framing. But when an HTTP/2 frontend translates to an HTTP/1.1 backend, new vulnerabilities appear.
Real case: CVE-2023-25950 (HAProxy)
HAProxy, used by millions of sites, was vulnerable to smuggling via malformed HTTP/2 headers, allowing ACL bypass.
Correction and prevention
1. Server configuration
Configure Nginx, HAProxy, and Apache with strict mode and request validation.
2. Architecture
- Standardize servers: Use the same stack everywhere if possible
- HTTP/2 end-to-end: Avoid downgrade to HTTP/1.1
- WAF in strict mode: Reject any request with both CL and TE
3. Application validation
Reject requests containing both Transfer-Encoding and Content-Length headers.
4. Regular testing
Integrate smuggling tests in your CI/CD pipeline.
Security checklist
| Check | Action |
|---|---|
| CL+TE requests rejected | Configure server |
| Obfuscated TE headers rejected | Strict validation |
| HTTP/2 without downgrade | Modern architecture |
| WAF in strict mode | Security configuration |
| Automated smuggling tests | CI/CD pipeline |
| Malformed request monitoring | Alerting |
Conclusion
HTTP Request Smuggling represents a particularly dangerous class of attacks because it operates at a level that most security tools ignore. In a world where distributed architectures are becoming the norm, understanding and testing this vulnerability is essential.
At RedSentinel, our security audits systematically include Request Smuggling tests across your entire HTTP processing chain. We identify desynchronizations between your different layers and help you implement lasting fixes.
Additional resources
- HTTP Desync Attacks - PortSwigger Research
- HTTP/2: The Sequel is Always Worse - James Kettle
- RFC 7230 - HTTP/1.1 Message Syntax
Need help on this topic?
Our experts can assist you with this issue.