HTTP request smuggling exploits disagreements between a front-end server (such as a load balancer or CDN) and a back-end server about where one request ends and the next begins. An attacker can "smuggle" a hidden request that the back end processes as part of another user's request.

How it happens

Requests can declare their length with Content-Length or Transfer-Encoding: chunked. If the front end trusts one header and the back end trusts the other, a single crafted request is split differently by each. Variants include CL.TE, TE.CL, CL.0 and HTTP/2 downgrade attacks.

Why it matters

• Bypass of front-end security controls.
• Hijacking other users' requests and sessions.
• Web cache poisoning that serves malicious content to many users.

How to prevent it

• Use HTTP/2 end to end where possible.
• Configure the front end to normalise ambiguous requests and reject those with both length headers.
• Keep proxies, load balancers and servers updated.
• Use the same server software, or thoroughly tested combinations, at each tier.

How Vooki Pro helps

• Tests for CL.TE, TE.CL, CL.0 and HTTP/2 smuggling variants, h2c upgrades and protocol downgrades.
• Also checks for web cache poisoning and web cache deception.
• Detects when a WAF blocks part of the scan and tells you, so you know the coverage you actually got.
• Shows the exact raw request used, for your infrastructure team.

Frequently asked questions

What causes HTTP request smuggling?

A front-end server and back-end server disagree on where a request ends, usually because one trusts Content-Length and the other trusts Transfer-Encoding.

Does HTTP/2 fix request smuggling?

End-to-end HTTP/2 removes the classic ambiguity, but downgrading HTTP/2 to HTTP/1.1 at a proxy can introduce new smuggling variants.

Related: Insecure deserialization · Open redirect vulnerabilities