HTTP request smuggling: how it works, how testers prove it, how to fix it

What is HTTP request smuggling?#

HTTP request smuggling is a flaw where two servers in the same request path disagree about where one HTTP request ends and the next begins. A front-end (a CDN, reverse proxy or load balancer) and a back-end (the application server) share one connection, and the attacker sends bytes that the front-end counts as one request and the back-end counts as a request plus the start of another. The back-end then glues that leftover onto the next request on the connection, which can belong to another user. CWE-444 calls this inconsistent interpretation of HTTP requests.

The rule in RFC 9112 shows where the disagreement starts. A message with both Transfer-Encoding and Content-Length should be handled as an error, because Transfer-Encoding overrides Content-Length and the pair "might indicate an attempt to perform request smuggling". Servers that apply the rule differently, or that parse a malformed header differently, produce a desync.

Testing for smuggling needs written authorization from the system owner. A bad probe can disturb real users.

How does HTTP request smuggling work?#

Request smuggling works because HTTP/1.1 has two ways to give a body length, Content-Length and Transfer-Encoding: chunked, and a chain of servers may pick different ones. If the front-end uses one and the back-end uses the other, the byte stream splits at different points.

Attacker sends one request on a shared connection:

  [ POST /search ... body ... | leftover bytes "GET /404 ..." ]
   ^---- front-end sees ONE request (uses Content-Length)
   ^---- back-end sees TWO: the POST (uses chunked, ends at "0"), then the start of a request

Next user's request arrives on the same back-end connection:

  [ leftover "GET /404 HTTP/1.1 Foo: x" + "GET /account HTTP/1.1 ..." ]
   -> the back-end reads one merged request

POST /search HTTP/1.1
Host: shop.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49
Transfer-Encoding: chunked

e
q=smuggling&x=
0
GET /404 HTTP/1.1
Foo: x

POST /search HTTP/1.1
Host: shop.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

q=widgets

Browsers and HTTP/2 changed the picture. PortSwigger's research HTTP/2: The Sequel is Always Worse (5 August 2021) showed that front-ends which accept HTTP/2 and rewrite it to HTTP/1.1 for the back-end create new desync types. Browser-Powered Desync Attacks (10 August 2022) showed desyncs that a victim's own browser can trigger, without a special proxy in the path.

Which variants of request smuggling exist?#

The main variants are named after the front-end and back-end behavior: CL.TE, TE.CL, TE.TE, CL.0, H2.CL and H2.TE. In each name, the first part is the header the front-end uses and the second is the header the back-end uses.

PortSwigger's 2022 research calls CL.0 a known but lesser-explored attack class, and its Academy page notes that sites using HTTP/2 end to end are immune to the classic attacks because HTTP/2 has one mechanism for message length. TE.TE depends on a header that one server rejects and another accepts, and it is a parser quirk of the specific products in the chain, so we do not list obfuscated header variants here.

Which real cases and CVEs involve request smuggling?#

Both CVEs below are in widely deployed server software, and the research dates show when the classes became known. Each entry links to NVD or the original post.

The Apache case shows that the vulnerable component can be a rewrite rule and not a bug in a parser: a configuration pattern put user input into the proxied request line. Check your own rewrite and proxy rules for user input in the request target.

Which parts of your stack can cause a desync?#

A desync needs two HTTP/1.1 hops, so list every hop between the client and the application code, and check each one. The risk sits at the boundaries, so each row is a boundary.

Configuration lines that help:

# nginx: speak HTTP/1.1 to the upstream so keepalive works predictably.
# The nginx docs say the default changed to 1.1 in 1.29.7; earlier versions defaulted to 1.0.
location / {
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_pass http://app_backend;
}

# HAProxy: speak HTTP/2 to the back-end so message length has one definition.
backend app
    server app1 10.0.0.10:8443 ssl verify required ca-file /etc/ssl/ca.pem alpn h2 proto h2

Use these only after you confirm that your back-end supports HTTP/2. The HAProxy manual documents the proto keyword for forcing the protocol on a server connection. The alpn setting must match what the back-end offers.

PortSwigger's prevention advice adds four points. Use HTTP/2 end to end and disable downgrading if possible. Make the front-end normalize ambiguous requests, and make the back-end reject any that remain. Never assume requests have no body, which is the root of CL.0 and client-side desync. Close the connection if the server hits an exception while handling a request. Disabling back-end connection reuse helps against some attacks, but PortSwigger notes it does not stop request tunnelling.

How do penetration testers detect and prove request smuggling?#

Testers detect smuggling with a timing probe, confirm it with a differential probe on their own connection, and record the evidence. PortSwigger calls timing the most generally effective detection method, and Burp Scanner automates it. The OWASP Web Security Testing Guide covers the topic in WSTG-INPV-15.

The CL.TE timing probe from PortSwigger's guide:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 4

1
A
X

The front-end forwards only part of the body and omits the X. A CL.TE back-end processes the first chunk and waits for the next, so the response is delayed. The TE.CL probe reverses the idea: the front-end uses the chunked body, and a TE.CL back-end waits for more bytes than it received.

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 6

0

X

PortSwigger advises running the CL.TE test first and the TE.CL test only if the first one fails, to be stealthy and minimize disruption.

The steps:

1. Get written authorization, a staging environment that mirrors production, and a test window.
2. Map the hops: CDN, load balancer, proxy, app server, and the HTTP version at each.
3. Send the timing probes and record the delay against a baseline measured several times.
4. Confirm with a differential probe: an attack request, then a normal request on the same connection, as in the demo above. Use your own session and a path that you created for the test.
5. Run controls: the same requests without the smuggled part, and a request to a nonexistent path, to show that the odd response comes from the desync.
6. Save the raw requests and responses with timestamps.

Burp Scanner automates the timing probes. Our method also applies here: a finding needs a real, reproduced effect, and we do not report a delay alone as a confirmed vulnerability. Poisoning a shared connection on a production system is out of bounds unless the owner approves the risk in writing.

How do you prevent HTTP request smuggling?#

Use HTTP/2 end to end, reject ambiguous HTTP/1.1 requests, and patch every proxy and server in the path. These steps are the same on any stack, so apply them at the edge first.

1. Run HTTP/2 between the front-end and the back-end. HTTP/2 gives each message one length mechanism.
2. Configure the front-end to reject requests that carry both Content-Length and Transfer-Encoding, as RFC 9112 advises treating them as an error, and to reject malformed header lines.
3. Keep proxies, load balancers and language runtimes on fixed versions. CVE-2022-32213 was fixed in new releases of Node.js's parser, and CVE-2023-25690 in Apache 2.4.56.
4. Review rewrite and proxy rules so user input never fills part of the proxied request line.
5. Turn off back-end connection reuse across users if you cannot move to HTTP/2.
6. Close the connection after a server-level error.

A WAF rule that blocks one probe does not remove the parsing disagreement. Patch the parsers.

Request smuggling testing checklist#

1. Draw the request path and the HTTP version of each hop.
2. Confirm authorization, a test window and a staging copy.
3. Check which hops downgrade HTTP/2 to HTTP/1.1.
4. Send the CL.TE timing probe, then the TE.CL probe only if needed.
5. Test H2.CL and H2.TE where the front-end accepts HTTP/2.
6. Test CL.0 on endpoints that normally take no body, such as static files and redirects.
7. Confirm with a differential probe on your own connection.
8. Run controls and record the baseline.
9. Check cache behavior and response queues for effects on other requests, in staging only.
10. Verify versions of proxies and servers against NVD.

When should you get a professional test?#

Get a professional test when you run more than one HTTP layer in front of the application, such as a CDN, a load balancer and a reverse proxy, or when you recently changed proxies or enabled HTTP/2. Smuggling needs careful scoping, because probes can touch shared connections. A web application penetration test covers the whole path, including how the layers handle requests, and an API penetration test covers API gateways. Related reading: web cache poisoning and host header injection.