What Is HTTP Request Smuggling?

HTTP Request Smuggling is a web attack that exploits how two servers, usually a front-end proxy and a back-end server, disagree about where one HTTP request ends and the next one begins. An attacker crafts a single request that each server reads differently, hiding a second request inside it. That smuggled request slips past security controls and lands in another visitor’s traffic. The payoff for the attacker can be session theft, cache poisoning, or a full proxy bypass. This guide walks through how the attack works, the main variants such as CL.TE and TE.CL, the damage it causes, and the exact steps that shut it down. First, the mechanics.

Key Takeaways

• HTTP Request Smuggling abuses parsing differences between a front-end proxy and a back-end server that share one connection.
• The root cause is conflicting Content-Length and Transfer-Encoding headers that each server interprets in its own way.
• The main variants are CL.TE, TE.CL, and TE.TE, named after which length header each server chooses to trust.
• One smuggled request can poison caches, hijack sessions, capture credentials, and bypass a web application firewall.
• HTTP/2 downgrade smuggling revives the attack on newer stacks that translate requests back to HTTP/1.1 before the origin.
• The strongest fix is to normalize every request and reject any message that carries both length headers at once.
• Detection leans on timing anomalies, malformed request logs, and careful differential testing against your own stack.

How HTTP Request Smuggling Works

HTTP Request Smuggling works by sending one ambiguous request that a front-end server and a back-end server split into a different number of requests. The mismatch is the whole attack.

Most sites put a chain of machines between the visitor and the application. A reverse proxy or CDN sits out front, forwards traffic to an origin, and reuses the same TCP connection for many requests to save round trips. That reuse is the point. It also creates a seam, and the seam is where things break when the two ends count bytes differently.

The attacker sends a request whose body is deliberately ambiguous. The front-end reads it as one clean request and passes it along. The back-end reads the same bytes and sees one request plus the start of a second one. That leftover fragment waits in the connection buffer, then gets glued to the front of whatever request arrives next. Often that next request belongs to a real user, which is what makes the attack so nasty. A reverse proxy protected by an advanced web application firewall or a load balancing tier is exactly where this desync can occur, because it sits between two parsers that were never guaranteed to agree.

1. The attacker opens a connection through the front-end proxy and sends a crafted request with conflicting length information.
2. The front-end forwards what it believes is a single, complete request to the back-end.
3. The back-end interprets the bytes differently and treats part of the message as the beginning of a new request.
4. The orphaned fragment sits in the buffer and prefixes the next legitimate request on that connection.
5. The victim’s request now carries the attacker’s payload, and the response goes to the wrong place.

You might be thinking this only affects exotic setups. It does not. Any architecture with a shared front-end and a separate origin can desync, and that describes the majority of production web stacks. Understanding the disagreement between servers matters, so the next question is why they disagree at all.

Transfer-Encoding vs Content-Length

The desync comes from two HTTP headers that both describe the length of a request body: Content-Length and Transfer-Encoding. When a single request contains both, the servers have to pick one, and they do not always pick the same one.

Content-Length states the body size as a fixed number of bytes. Transfer-Encoding: chunked says the body arrives in sized chunks and ends when a zero-length chunk shows up. The HTTP specification tells servers to reject or normalize a request that carries both, but plenty of proxies and origins bend that rule for compatibility. That tolerance is the opening. Careful HTTP header configuration at the edge closes most of it before a request ever reaches your application.

Here is the analogy that makes it click. Think of two shipping clerks reading the same packing slip. One counts items by the number printed on the box. The other counts by opening the box until it finds an empty compartment. Hand them a box where those two numbers disagree, and one clerk will start reading the next customer’s order as part of yours.

Yes, the fix sounds simple: just reject requests with both headers. But real traffic is messy, and the way each variant abuses that mess is what separates a shrug from a breach. That brings us to the named attack types.

Types of HTTP Request Smuggling Attacks

HTTP Request Smuggling attacks are named after which length header the front-end and back-end each trust. The three classic forms are CL.TE, TE.CL, and TE.TE, and a fourth pattern rides on HTTP/2 downgrades.

CL.TE (front-end Content-Length, back-end Transfer-Encoding)

The front-end uses Content-Length while the back-end uses Transfer-Encoding. The attacker sets a small Content-Length so the front-end forwards only part of the body, then uses a chunked terminator so the back-end treats the remainder as a new request. This is the most common variant seen in the wild.

TE.CL (front-end Transfer-Encoding, back-end Content-Length)

The roles flip. The front-end reads the chunked body, the back-end trusts Content-Length, and the smuggled data hides in the gap between the two interpretations. TE.CL often needs more precise byte counting, which makes it fiddly to build but just as damaging once it lands.

TE.TE (both use Transfer-Encoding, one is obfuscated)

Both servers support Transfer-Encoding, so the attacker obfuscates the header just enough that one server ignores it and falls back to Content-Length. A malformed value or an odd whitespace pattern is often all it takes.

There is also the modern twist. When a site speaks HTTP/2 at the edge but downgrades to HTTP/1.1 before the origin, the rewrite step can reintroduce ambiguity that HTTP/2’s built-in length handling was supposed to remove. Running HTTP/2 & HTTP/3 all the way to the origin removes that downgrade seam entirely.

Knowing the variants is useful, but the question every stakeholder actually asks is simpler: what can someone do to my business with this? Quite a lot, as it turns out.

What Attackers Do With a Smuggled Request

A smuggled request lets an attacker inject content into other users’ connections, which opens the door to theft, hijacking, and full security bypass. The impact scales with how much traffic flows through the desynced connection.

The most direct payoff is capturing another user’s request. Because the smuggled fragment prefixes the next request on the connection, an attacker can force a victim’s request to be stored and echoed back, exposing session cookies and CSRF fields. That single move enables session hijacking, and it can neutralize a CSRF token by handing the attacker a valid one. Smuggling is also a reliable way to reach endpoints that should be off limits, which is a form of broken access control achieved at the transport layer rather than the application logic.

• Web cache poisoning that serves a malicious response to thousands of later visitors from a single injected request.
• Security control bypass, where the smuggled request never passes through the front-end filters that would have blocked it.
• Credential and session capture by forcing victim requests to be reflected to the attacker.
• Response queue poisoning that desyncs the connection so users receive responses meant for someone else.
• Access to internal or administrative routes that the front-end was supposed to gate.

A concrete example makes the stakes clear. Security researchers earned six-figure bug bounty payouts by smuggling requests on large platforms, in several cases turning a single crafted message into account takeover across many users. One well-documented case against a major retailer chained smuggling into a stored redirect that hijacked live sessions.

If the damage is this broad, the obvious follow-up is whether you can catch it before an attacker does. You can, though it takes the right signals.

How to Detect HTTP Request Smuggling

Detecting HTTP Request Smuggling relies on differential timing tests, malformed request logs, and controlled probes that measure how your front-end and back-end each parse an ambiguous message. The clearest tell is a response delay that only appears when a request carries conflicting length headers.

The most reliable manual technique is a timing probe. You send a request that would force the back-end to wait for more body data if, and only if, it parsed the headers a certain way. A consistent delay of around five seconds where a normal request returns in milliseconds is a strong signal that the two servers disagree. Automated scanners built into tools like Burp Suite run these probes safely against a target you own.

1. Baseline normal response times for a clean request to the target endpoint.
2. Send a CL.TE probe and a TE.CL probe that each introduces a deliberate parsing delay.
3. Compare timings. A large, repeatable gap points to a desync rather than random latency.
4. Confirm with a controlled smuggle that affects only your own follow-up request, never a live user’s.
5. Review front-end and back-end logs for truncated bodies, orphaned requests, and mismatched request counts.

Log analysis backs up the probes. A rule set like the OWASP Core Rule Set flags protocol violations such as duplicate length headers and malformed chunk sizes, giving you a passive tripwire alongside the active testing.

Detection tells you where you stand. Closing the gap is the part that protects your users, and that is where a layered defense earns its keep.

How to Prevent and Mitigate HTTP Request Smuggling

You prevent HTTP Request Smuggling by making both servers parse every request the same way, which means normalizing requests, rejecting ambiguous length headers, and removing the downgrade steps that reintroduce risk. Defense in depth turns a single missed rule into a non-event.

The core rule is strict parsing. Configure the front-end to reject any request that contains both Content-Length and Transfer-Encoding, or to strip one and forward a clean message. Keeping the protocol consistent end to end removes the rewrite step that so many attacks depend on. Beyond that, a customized WAF can enforce protocol hygiene at the edge, and pairing it with a firewall solution gives you both application-layer and network-layer control. Since smuggling is often a stepping stone to volumetric follow-ups, layering DDoS attack protection and Edge Guard Security keeps the same edge that blocks desync from buckling under a flood.

• Normalize or reject requests carrying both length headers, and drop malformed chunk encodings.
• Use the same HTTP version end to end so no downgrade step reintroduces ambiguity.
• Disable back-end connection reuse where practical, or scope reuse tightly so fragments cannot cross users.
• Inspect traffic with a WAF that understands protocol-level anomalies, not just payload signatures.
• Validate requests at the edge and fail closed on anything ambiguous rather than passing it through.

Prevention is not a one-time switch. Every new proxy, load balancer, or origin you add is another parser that has to agree with the rest, so the discipline is to test the whole chain each time it changes.

Final Thought on HTTP Request Smuggling

HTTP Request Smuggling is dangerous because it hides in the gap between systems that each work correctly on their own. No single server is misbehaving. They simply disagree about where a request ends, and that disagreement is enough to hand an attacker other people’s traffic.

The defense is consistency. When every hop in your chain parses requests the same strict way, rejects conflicting length headers, and avoids needless protocol downgrades, the ambiguity that powers the attack has nowhere to live. Pair that discipline with edge inspection and regular differential testing, and you close the seam for good while keeping your application fast for the users who matter.

Frequently Asked Questions About HTTP Request Smuggling