HTTP Request Smuggling
detect, understand, remediate
HTTP request smuggling exploits discrepancies between how front-end proxies and back-end servers parse HTTP requests, allowing attackers to smuggle malicious requests that bypass security controls.
No credit card required. Free plan available forever.
What is HTTP request smuggling?
HTTP request smuggling is a technique that exploits discrepancies in how front-end servers (load balancers, reverse proxies, CDNs) and back-end servers parse HTTP requests. Classified under CWE-444, this vulnerability allows an attacker to "smuggle" a hidden request inside what appears to be a single legitimate request. The front-end server sees one request, while the back-end server interprets the same data as two separate requests, enabling the attacker to bypass security controls, poison caches, and hijack other users' sessions.
The root cause lies in ambiguous HTTP message framing. HTTP/1.1 offers two methods for specifying the body length of a request: the Content-Length header and Transfer-Encoding: chunked. When both headers are present, or when they are processed differently by the front-end and back-end servers, the boundary between requests becomes ambiguous. Attackers exploit this ambiguity to inject a second request that the back-end processes in the context of the next legitimate user's connection, leading to cache poisoning, credential theft, and request hijacking.
HTTP request smuggling is a particularly dangerous vulnerability because it operates below the application layer, making it invisible to most application-level security controls. Web application firewalls, authentication middleware, and access control logic all operate on the request as parsed by the front-end server, while the smuggled request bypasses all of these protections. Detection requires specialized testing that probes the interaction between infrastructure components, which is why external scanning with protocol-level awareness is essential for identifying these flaws.
How it works
Identify proxy/server chain
The attacker maps the infrastructure to identify front-end proxies, load balancers, or CDNs sitting in front of back-end application servers. Any multi-tier HTTP architecture is a potential target.
Craft ambiguous headers
The attacker sends a request with conflicting Content-Length and Transfer-Encoding headers, or with malformed chunked encoding, designed to be interpreted differently by the front-end and back-end servers.
Desync request parsing
The front-end server processes the request using one header (e.g., Content-Length) while the back-end uses the other (e.g., Transfer-Encoding). This desynchronization causes leftover bytes to be treated as the start of the next request.
Smuggle malicious request
The leftover bytes form a complete HTTP request that the back-end server processes as if it came from the next legitimate user. This smuggled request can access restricted endpoints, steal credentials, or poison cached responses.
Common causes
Proxy/server interpretation differences
Front-end and back-end servers implement the HTTP specification differently, particularly around edge cases in Transfer-Encoding parsing, chunked encoding termination, and Content-Length precedence when both headers are present.
Ambiguous header handling
Servers that accept malformed Transfer-Encoding headers (e.g., "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked\n", or duplicate headers) create parsing discrepancies that attackers exploit to desynchronize request boundaries.
HTTP/1.1 connection reuse
Keep-alive connections between front-end proxies and back-end servers allow multiple requests to be sent over a single TCP connection. When request boundaries are ambiguous, leftover data from one request contaminates the next.
Mixed HTTP version infrastructure
Architectures that downgrade HTTP/2 to HTTP/1.1 between the front-end and back-end introduce additional desynchronization opportunities, as HTTP/2 framing is fundamentally different from HTTP/1.1 message delimiting.
How to detect it
Automated detection
- SecPortal's external scanner sends specially crafted requests with conflicting Content-Length and Transfer-Encoding headers to detect parsing desynchronization between infrastructure layers
- Timing-based detection techniques measure response delays caused by smuggled requests to identify CL.TE, TE.CL, and TE.TE smuggling variants without causing visible disruption to the target
- SecPortal's security header analysis identifies missing or misconfigured headers that indicate vulnerable HTTP parsing configurations in the server chain
Manual testing
- Send requests with both Content-Length and Transfer-Encoding headers set to conflicting values and observe whether the response timing or content differs from normal requests
- Use differential response analysis by sending smuggled requests that trigger a 404 or redirect, then check whether the next legitimate request receives the smuggled response
- Test HTTP/2 downgrade scenarios by comparing behavior when connecting directly to the back-end versus through the front-end proxy, looking for parsing discrepancies
How to fix it
Normalize HTTP parsing across all servers
Ensure that all servers in the request chain (proxies, load balancers, application servers) use identical rules for processing Content-Length and Transfer-Encoding headers. Reject requests that contain both headers or that have ambiguous encoding.
Disable connection reuse between tiers
Configure front-end proxies to use separate connections for each back-end request rather than multiplexing requests over persistent connections. This eliminates the request boundary confusion that enables smuggling, though it comes with a performance cost.
Use HTTP/2 end-to-end
HTTP/2 uses binary framing with explicit message length fields, eliminating the Content-Length versus Transfer-Encoding ambiguity entirely. Deploy HTTP/2 between all infrastructure components, not just between clients and the front-end proxy.
Deploy WAF rules for smuggling detection
Configure web application firewalls to reject requests with conflicting Content-Length and Transfer-Encoding headers, malformed chunked encoding, and other request smuggling indicators. Update these rules regularly as new bypass techniques are discovered.
Ensure consistent server configurations
Standardize the HTTP server software and configuration across your infrastructure. When using different software (e.g., Nginx as proxy with Apache as back-end), test their combined behavior with smuggling payloads and apply vendor-specific hardening guidelines.
Compliance impact
Related vulnerabilities
Detect HTTP desync vulnerabilities
SecPortal tests for CL.TE, TE.CL, and TE.TE request smuggling across your proxy infrastructure. Start free.
No credit card required. Free plan available forever.