BIPI
BIPI

HTTP Request Smuggling: Modern Variants in HTTP/2 and CDN Stacks

Cybersecurity

CL.TE and TE.TE are 2019 attacks. The 2024-2025 variants live in HTTP/2 downgrade paths, CDN-to-origin desync, and header processing differences between modern web servers and reverse proxies.

By Arjun Raghavan, Security & Systems Lead, BIPI · September 19, 2024 · 8 min read

#http-smuggling#web-security

The HTTP smuggling we found in a Fortune 500's API gateway last year wasn't classic. The CDN spoke HTTP/2 to clients and HTTP/1.1 to origin. When a client sent an HTTP/2 request with a smuggled Content-Length header in the trailer, the CDN passed it to origin as HTTP/1.1, which interpreted the Content-Length and desynced the connection. The next legitimate request was prefixed with the attacker's payload.

The bug was in the CDN's HTTP/2-to-1.1 translation layer. Their vendor patched it within a week of disclosure. Six other tenants on the same CDN were vulnerable to the same attack. We had three weeks of front-row seat to one of the more interesting smuggling classes of the decade.

Why request smuggling exists

Smuggling happens when two HTTP-parsing components disagree about where one request ends and the next begins. A CDN parses a request and decides Content-Length: 100 means the next 100 bytes are this request's body. The origin parses the same bytes and uses Transfer-Encoding: chunked instead, ending the request earlier. The leftover bytes get treated as the start of the next request. Whoever sends that next request sees their request prefixed with the attacker's smuggled bytes.

Classic CL.TE (CDN uses CL, origin uses TE), TE.CL, and TE.TE variants are well-documented. Modern stacks have layered new variants on top: HTTP/2 downgrade, HTTP/2 stream multiplexing bugs, websocket upgrade desync, and connection coalescing on long-lived TLS sessions.

The HTTP/2 downgrade vector

HTTP/2 has its own framing and shouldn't be susceptible to header-based smuggling. But when the CDN talks HTTP/2 to clients and HTTP/1.1 to origin (which is most CDN deployments), it has to translate HTTP/2 frames into HTTP/1.1 messages. This translation is where the bugs live.

James Kettle's PortSwigger research from 2021 onward documented multiple variants: HTTP/2 messages with embedded CR/LF in headers that get serialised into HTTP/1.1 verbatim, header splitting via : characters in pseudo-header values, and trailer-based smuggling where the HTTP/2 trailer becomes an HTTP/1.1 header that the origin treats as a primary header.

Detection and exploitation

Detection is timing-based. Send a request that, if smuggling worked, would cause the next request on the same connection to hang or get an unexpected response. Measure the timing. If your malicious request gets a fast 200 but the next request takes 5+ seconds (because it's now waiting for body bytes that never come), you have smuggling.

Burp Suite's HTTP Request Smuggler extension automates this. Run it against any internet-facing app behind a CDN or load balancer. It tests dozens of variants automatically. Modern bug bounty hunters run it as a baseline check against every new asset; if you don't, they will.

Defences that actually help

Use HTTP/2 end-to-end where possible. CDN to origin over HTTP/2 eliminates the downgrade translation layer. Most cloud load balancers (ALB, GCP LB, Cloudflare) support this in 2024 onward; configure it.

Strict header parsing on origin. Reject requests with both Content-Length and Transfer-Encoding. Reject requests with malformed chunked encoding. Reject requests with multiple Content-Length headers. Most modern web servers (nginx 1.21+, Caddy, recent Apache) do this by default; legacy stacks (older Tomcat, F5, custom Go HTTP servers with hand-rolled parsing) often don't.

  • Reject ambiguous CL+TE combinations at the proxy and origin
  • Use HTTP/2 end-to-end between CDN and origin
  • Disable HTTP/1.1 connection reuse on edge if smuggling can't be ruled out
  • Run HTTP Request Smuggler in CI against every public endpoint
  • Subscribe to your CDN's security advisories; smuggling fixes ship monthly

What we tell our clients

If you have a CDN in front of an origin, you have a smuggling threat model whether you know it or not. The good news: the specific smuggling vulnerabilities are vendor bugs and they get patched. The bad news: new variants land every six months because every parser disagreement is a potential bug.

Treat smuggling like XSS in the early 2010s: an attack class that requires ongoing investment, not a one-time fix. Run automated tests, monitor your CDN vendor advisories, and have a runbook for emergency CDN configuration changes. The next variant is already being researched.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.