HTTP request smuggling

What it means

HTTP request smuggling is a flaw that appears when two servers in a chain disagree about where one request ends and the next begins. A proxy or load balancer sees one request. The server behind it sees two, and the second was never inspected by the front end.

The disagreement usually comes from the two ways HTTP/1.1 can state a body's length: the Content-Length header and chunked Transfer-Encoding. If one server trusts the first and the other trusts the second, the leftover bytes become the start of someone else's request.

Why it matters

Whatever the front end enforces, such as sign-in checks, web application firewall rules or path restrictions, can be skipped by the smuggled request. It may also be glued onto the start of another visitor's request, which can expose their session or poison what a cache stores for others.

It is hard to see from the outside, because every individual request looks valid. Teams find out when a researcher reports it, or when strange responses reach the wrong customers. It is rare compared with common flaws, but the impact on a shared proxy can be large.

How it shows up

It shows up where there are two HTTP hops: a CDN, reverse proxy or load balancer in front of an application server, especially from different vendors or versions. Downgrading HTTP/2 from the client to HTTP/1.1 behind the proxy has also produced cases. RFC 9112 describes the risk and tells servers to treat messages with both headers as suspect.

Reduce it by using HTTP/2 end to end where possible, keeping proxy and server software updated, and rejecting ambiguous requests instead of guessing. Do not reuse back-end connections between different users if you can avoid it. Testing needs care, because probing can disturb real visitors, so it is best done on a copy first. See header injection for a related family.