HTTP request smuggling
HTTP request smuggling is an attack that exploits disagreement between two servers on a connection about where one request ends and the next begins. A front end forwards what it considers one request, the back end reads it as two, and the attacker’s leftover bytes are prefixed onto whoever uses that connection next.
The disagreement comes from the two ways a request body can be delimited. One server trusts the declared content length, the other trusts chunked transfer encoding, and a request that carries both is parsed differently by each. Variations exist where both servers agree to use the same header but reach that agreement by different rules, and where a request downgraded from HTTP/2 to HTTP/1.1 by an intermediary carries a length the downgrade recalculates incorrectly.
The consequence is not subtle. The prefix lands on another user’s request, so responses can be captured, requests can be routed to paths the front end would have blocked, and a cached response can be poisoned for everyone. Any control enforced only at the edge, including a web application firewall and the routing rules of a CDN, is bypassed by definition, because the back end never saw the request the edge inspected.
It is delicate to test safely. On a live estate the requests are timed to land outside business hours where possible, the probe is stopped at proof of desync rather than run to capture live traffic, and the report records the exact header combination and the two products involved, because the fix is a configuration or version change in one of them, not in the application. This is part of the web application testing where proxy chains are probed for desync.