What Is HTTP Request Smuggling? A Plain-English Guide for UK Businesses

The Setup: Two Servers, One Disagreement

Modern web applications rarely consist of a single server. Traffic typically passes through a chain: a load balancer or reverse proxy at the front, one or more application servers at the back. The front-end accepts requests from the internet and forwards them to the back-end. The back-end processes them and sends responses back.

This architecture works because both ends agree on how to read HTTP requests — specifically, where each request ends and the next one begins. HTTP request smuggling is what happens when they do not agree.

When the front-end and back-end apply different rules for parsing request boundaries, an attacker can craft a single HTTP request that the front-end treats as one complete request, but the back-end treats as two. The leftover bytes — the "smuggled" prefix — are prepended to the next legitimate user's request without their knowledge. This allows the attacker to interfere with that user's request in ways that can lead to authentication bypass, session hijacking, web cache poisoning, and remote code execution.

HTTP and the Problem of Request Length

To understand how this works you need to understand how HTTP/1.1 signals the end of a request body. There are two mechanisms:

**Content-Length** — The request includes a header stating how many bytes the body contains. The server reads exactly that many bytes and then considers the request complete.

**Transfer-Encoding: chunked** — The body is sent in chunks. Each chunk is preceded by its size in hexadecimal, and the final chunk has a size of zero, signalling the end.

Both mechanisms are valid. The vulnerability arises when a request includes both headers and the front-end and back-end use different ones to determine where the request ends.

The Three Attack Variants

Security researchers James Kettle and others at PortSwigger categorised the attack into variants based on which header each tier prioritises:

**CL.TE** — The front-end uses Content-Length; the back-end uses Transfer-Encoding. The attacker crafts a request where Content-Length covers the entire payload (so the front-end forwards it as one request), but the chunked encoding terminates early, leaving a suffix that the back-end prepends to the next incoming request.

**TE.CL** — The front-end uses Transfer-Encoding; the back-end uses Content-Length. The attacker sends a chunked request that the front-end forwards in full, but whose Content-Length causes the back-end to read only part of it, leaving the remainder for the next request.

**TE.TE** — Both servers support Transfer-Encoding, but one can be obfuscated into ignoring it. The attacker sends a request with a malformed Transfer-Encoding header — using alternate capitalisation, extra whitespace, or invalid values — that causes one server to fall back to Content-Length while the other uses the chunked encoding.

What an Attacker Can Achieve

Bypass access controls

By smuggling a request prefix that sets a malicious path or adds headers, an attacker can cause another user's request to be interpreted as accessing a restricted resource. If the back-end makes authorisation decisions based on headers that the attacker controls via the smuggled prefix, access controls can be bypassed.

Capture other users' requests

A smuggled request can be crafted so that the next user's request is appended to a storage location (a comment field, a profile update endpoint) that the attacker can later read. The entire request — including authentication cookies, session tokens, and POST body data — is captured. This is one of the most severe impacts: the attacker essentially reads another user's authenticated session and can replay it.

Web cache poisoning

If the smuggled request poisons a cached response, the malicious response is served to subsequent users who request the same resource without any further action from the attacker.

Reflected XSS amplification

HTTP request smuggling can be used to deliver reflected XSS payloads to other users even when those users never visit a malicious URL, circumventing the usual requirement for user interaction.

Why It Is Difficult to Detect

Unlike SQL injection or XSS, HTTP request smuggling does not produce obvious error messages or visible anomalies in normal use. The attack exploits infrastructure-level behaviour that is not visible in application logs. Detection requires testing with crafted payloads specifically designed to probe how the front-end and back-end parse request boundaries.

Automated security scanners that include request smuggling probes in their test suites can detect the vulnerability. Manual testing using tools like Burp Suite's HTTP request smuggler extension provides more comprehensive coverage.

How to Fix HTTP Request Smuggling

Disable HTTP/1.1 request reuse at the front-end

Configuring the front-end server to use HTTP/2 for back-end connections eliminates the CL/TE ambiguity because HTTP/2 uses a different, unambiguous framing mechanism. Where HTTP/1.1 must be used for back-end connections, configuring the front-end to open a new back-end connection for each request (disabling connection reuse) prevents smuggled prefixes from affecting subsequent requests.

Normalise at the front-end

Configure the front-end to normalise ambiguous requests before forwarding — specifically, to reject or rewrite requests that contain both Content-Length and Transfer-Encoding headers, or that use obfuscated chunked encoding.

Ensure consistent parsing across the chain

Review the HTTP parsing configuration of both front-end and back-end servers to ensure they apply the same rules. RFC 7230 states that if both Content-Length and Transfer-Encoding are present, Transfer-Encoding takes precedence — ensuring both servers implement this rule consistently eliminates the CL.TE variant.

Use HTTP/2 end-to-end where possible

HTTP/2 uses binary framing that does not have the same ambiguity as HTTP/1.1 text-based request delimiting. End-to-end HTTP/2 (from client to front-end to back-end) removes the attack surface entirely for the variants that rely on HTTP/1.1 parsing differences.

Detection in Security Testing

Yrzo AI's automated scanner includes HTTP desync and request smuggling probes as part of its 75+ checks. The scanner tests for CL.TE and TE.CL variants on the target's public-facing endpoints and reports findings with a severity rating and remediation guidance.

Request smuggling vulnerabilities are rated high severity when found because the potential impact — capturing other users' sessions and bypassing access controls — is significant and the attacker does not need to interact with target users directly.

Run a scan at yrzoai.dev — full report in under 20 minutes, from £149.