HTTP request smuggling: when two servers disagree on where a request ends

The HTTP/1.1 rules on message length and smuggling are in RFC 9112, sections 6 and 11.2.

Over one HTTP/1.1 connection, requests follow each other with nothing in between. The receiver works out where a request body ends from one of two headers: Content-Length, which gives the size in bytes, or Transfer-Encoding: chunked, which sends the body in pieces and ends with an empty piece.

If a request carries both, RFC 9112 says Transfer-Encoding wins, and that such a message might be an attempt at request smuggling and ought to be handled as an error. Not every server follows that rule the same way, and the gap between two servers that differ is the whole attack.

Front-ends reuse a few connections to the back-end for requests from many users. The attacker sends a request whose length is ambiguous:

• CL.TE. The front-end uses Content-Length and forwards the whole body. The back-end uses Transfer-Encoding, stops at the empty chunk, and treats the rest as the start of the next request.
• TE.CL. The front-end uses Transfer-Encoding; the back-end uses Content-Length, reads fewer bytes, and leaves the rest waiting.
• TE.TE. Both support Transfer-Encoding, but one of them can be made to ignore an oddly written header, which turns the case into one of the two above.

The smuggled leftover sits at the start of the back-end connection. When the next request arrives, possibly from another user, the back-end reads the attacker's prefix first and the real request as its continuation.

• Bypass front-end controls. A smuggled request never passes the front-end's checks, because the front-end thought it was body data.
• Capture other users' requests. A smuggled prefix that stores data can swallow the next user's request, cookies included.
• Poison caches. A response meant for the smuggled request is stored under a normal address and served to everyone.
• Deliver other attacks. Reflected XSS or open redirects, delivered to users who never clicked anything.

The relation to CRLF injection is close: both exploit how HTTP marks boundaries. CRLF injection writes new header lines into a message; smuggling exploits disagreement about where a message ends.

HTTP/2 frames carry their own length, so end-to-end HTTP/2 does not have this ambiguity. The risk returns when a front-end speaks HTTP/2 to the browser and rewrites requests as HTTP/1.1 for the back-end. If it copies a Content-Length or Transfer-Encoding header from the client without checking it, the back-end sees the same ambiguous message as before.

That is why the fix is about the whole chain, not one hop: every server that turns one format into another has to validate what it writes.

1. Refuse ambiguous requests at the front. Both Content-Length and Transfer-Encoding, repeated or malformed length headers, odd spacing: reject, do not normalise and forward.
2. Use HTTP/2 end to end where possible. Or validate every header when downgrading to HTTP/1.1.
3. Keep front-end and back-end parsers up to date. Most real cases are parser bugs fixed in later versions.
4. Close the back-end connection after an error. A connection that saw a bad request should not carry the next user's.
5. Avoid reusing back-end connections across users where you can. It removes the queue that smuggling relies on, at some cost in performance.

A request filter is itself a front-end, so it is either the defence or part of the problem. One that refuses messages with conflicting length headers removes the most common variants before they reach the back-end. One that parses differently from the server behind it creates a new gap.

Smuggling is also a reason to keep the origin reachable only through the front-end: a back-end that also accepts connections directly has two front doors with different rules.