HTTP Request Smuggling: How It Works and How to Prevent It

HTTP Request Smuggling: How It Works and How to Prevent It

HTTP request smuggling is a vulnerability that exploits inconsistencies in how different components of a web infrastructure parse the boundaries between HTTP requests. When a frontend proxy (load balancer, CDN, reverse proxy) and a backend server disagree about where one request ends and the next begins, an attacker can 'smuggle' a partial request into the start of another user's request — hijacking their session, bypassing security controls, or achieving cache poisoning at scale.

Check your web application's security headers and configuration with ZeriFlow — 80+ automated checks, free.

The Root Cause: Two Headers, One Ambiguity

HTTP/1.1 provides two ways to specify the length of a request body:

• Content-Length (CL): Specifies the exact byte count of the body
• Transfer-Encoding: chunked (TE): Splits the body into chunks, each preceded by its size in hex, terminated by a zero-length chunk

RFC 7230 says if both headers are present, Transfer-Encoding takes precedence and Content-Length must be ignored. But not every server or proxy implements this rule identically — and that disagreement is the entire attack surface.

Attack Type 1: CL.TE (Content-Length Frontend, Transfer-Encoding Backend)

The frontend proxy uses Content-Length to determine the request boundary. The backend uses Transfer-Encoding: chunked.

Attack request:

POST / HTTP/1.1
Host: target.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

What the frontend sees: A 13-byte body (`0

SMUGGLED`). It forwards the entire request to the backend.

What the backend sees: A chunked request with a zero-length chunk (end of request), followed by SMUGGLED — which it treats as the beginning of the *next* request.

Now SMUGGLED is prepended to the next request that arrives. If the next request belongs to another user, the smuggled prefix poisons it.

Attack Type 2: TE.CL (Transfer-Encoding Frontend, Content-Length Backend)

Reversed scenario. The frontend strips the Transfer-Encoding header or normalizes it; the backend reads Content-Length.

Attack request:

POST / HTTP/1.1
Host: target.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

What the frontend sees: Chunked encoding — processes `8 SMUGGLED 0

` as the full body.

What the backend sees: Content-Length: 3, so it reads only 8 as the body. The remaining `SMUGGLED 0

` is left in the buffer and prepended to the next request.

Attack Type 3: TE.TE (Obfuscated Transfer-Encoding)

Both servers support Transfer-Encoding, but one can be tricked into ignoring it via obfuscation:

Transfer-Encoding: xchunked
Transfer-Encoding: chunked
Transfer-Encoding: CHUNKED
Transfer-Encoding: x
Transfer-Encoding: x
Transfer-Encoding: chunked

If the frontend processes the obfuscated header and the backend ignores it (or vice versa), you get a CL.TE or TE.CL situation by stealth.

What Attackers Can Do with Request Smuggling

Bypassing Security Controls

Smuggle a request to an admin endpoint that the frontend proxy would normally block:

SMUGGLED: GET /admin HTTP/1.1
Host: backend-internal
...

The backend processes it as a legitimate internal request.

Session Hijacking

Prepend a capture endpoint to the next victim's request, causing their credentials or session token to be appended to the attacker's request body:

GET /capture?x= HTTP/1.1
Host: target.com
...

When the victim's request arrives, its headers (including cookies and authorization tokens) are appended to the attacker's query parameter.

Cache Poisoning

Smuggle a response that gets cached against a URL the attacker chooses, affecting all future visitors.

Reflected XSS Amplification

Combine with existing reflected XSS to deliver exploits to users without a phishing link.

HTTP/2: The Recommended Mitigation

HTTP/2 uses a binary framing layer where each message has an explicit length field in the frame header. There is no ambiguity between Content-Length and Transfer-Encoding because the framing layer defines message boundaries.

H2.CL and H2.TE: However, if your infrastructure downgrades HTTP/2 to HTTP/1.1 at a hop boundary (e.g., the CDN speaks HTTP/2 to the client but HTTP/1.1 to the backend), smuggling vulnerabilities can re-emerge at the HTTP/1.1 segment. This is 'HTTP/2 request smuggling via desync'.

The full mitigation is: 1. Use HTTP/2 end-to-end where possible 2. Reject ambiguous requests (both CL and TE headers present) at the frontend 3. Normalize requests at the proxy layer before forwarding

Detection and Testing

Manual Testing

Use Burp Suite's HTTP Request Smuggler extension (by James Kettle). It automates CL.TE and TE.CL probe requests and observes timing differences or response anomalies.

Manual probe for CL.TE (timing-based):

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

1
A
X

If the response is delayed (the backend is waiting for more of what it thinks is a longer body), CL.TE smuggling is likely present.

Confirming Without Impacting Other Users

Always use a unique, non-reusable path (/uniquepath12345) and a confirming second request. Never test smuggling against live production traffic — it will affect real users.

Prevention: Infrastructure Hardening

1. 1Use HTTP/2 end-to-end: Eliminate the HTTP/1.1 parsing layer where possible.

1. 1Reject duplicate/conflicting headers: Configure your frontend to drop or reject requests that contain both Content-Length and Transfer-Encoding. Nginx: ignore_invalid_headers on.

1. 1Normalize at the edge: Have the frontend rewrite all requests to a canonical form before forwarding to the backend. Strip Transfer-Encoding and calculate a fresh Content-Length from the body.

1. 1Keep proxies and servers updated: Request smuggling vulnerabilities are regularly found in specific versions of HAProxy, Apache, Nginx, and cloud load balancers. Apply security patches promptly.

1. 1Use consistent server implementations: Mixing a Python backend with a Node.js proxy, or an old Apache with a modern CDN, increases the risk of parsing discrepancies.

FAQ

Q: Is HTTP request smuggling theoretical or used in real attacks?

A: It is actively exploited. James Kettle's research at PortSwigger demonstrated smuggling attacks against Akamai, Amazon, and Cloudflare infrastructure. Bug bounty reports for smuggling vulnerabilities regularly pay $10,000–$40,000+.

Q: Can a WAF detect HTTP request smuggling?

A: WAFs themselves are often vulnerable to request smuggling, or can be bypassed by it. A WAF positioned between the client and the backend is exactly the frontend/backend pair that smuggling targets. WAFs are not an effective defense for this attack class.

Q: Does HTTP/2 completely eliminate request smuggling?

A: HTTP/2 eliminates the specific CL vs. TE ambiguity because it uses binary framing. However, H2.CL and H2.TE attacks exist when infrastructure components downgrade to HTTP/1.1. Full HTTP/2 end-to-end deployment is the best available mitigation.

Q: How does request smuggling differ from SSRF?

A: SSRF (Server-Side Request Forgery) causes the server to make requests to unintended destinations. Request smuggling manipulates how the server pipeline processes incoming requests. They are different attack classes, though both can be used to access internal services.

Conclusion

HTTP request smuggling exploits a fundamental ambiguity in the HTTP/1.1 specification that has persisted for decades. The attack is infrastructure-level, bypasses application-layer security controls, and can affect every user of a vulnerable system simultaneously.

The path forward is clear: adopt HTTP/2 end-to-end, harden your proxy configuration to reject ambiguous requests, and keep your infrastructure components updated and well-matched.

Use ZeriFlow to audit your web security headers and configuration and identify the risks in your stack.