HTTP Request Smuggling 2026 — TE.CL, CL.TE Techniques & High-Impact Exploitation | BB Day21

How HTTP Request Smuggling Works — The Desync Condition

Modern web applications typically use a front-end server — a CDN, reverse proxy, or load balancer — that forwards requests to back-end origin servers. HTTP/1.1 allows multiple requests over a single TCP connection (keep-alive). When the front-end forwards these requests to the back-end, it needs to correctly determine where one request ends and the next begins. HTTP/1.1 specifies two headers for this purpose: Content-Length (specifying the exact byte count of the body) and Transfer-Encoding: chunked (specifying body length through a series of chunks with hexadecimal length prefixes).

The specification says both headers should never appear in the same request. When they do, different servers make different decisions about which to honour. If the front-end and back-end make different decisions — one honours Content-Length, the other honours Transfer-Encoding — they disagree about where the request body ends. The bytes the front-end includes as part of the first request body may be interpreted by the back-end as the beginning of a second request. That second request was smuggled in without going through the front-end’s security checks.

CL.TE Attack — Front-End Uses Content-Length

In a CL.TE attack, the front-end uses the Content-Length header to determine the body size and forwards the entire CL-length body to the back-end. The back-end uses Transfer-Encoding and processes the chunked body — reading each chunk and its hex length prefix until it encounters the zero-length terminator chunk (0\r\n\r\n). Any bytes after the terminator that were included in the CL-sized body are left in the back-end’s read buffer and treated as the beginning of the next request.

The attack payload places a zero-length chunk terminator early in the body, followed by the smuggled request prefix. The front-end reads the full CL-sized body and forwards all of it. The back-end reads up to the zero-length chunk and stops, leaving the smuggled prefix in its buffer. When the next request arrives from any user, the back-end prepends the buffered smuggled prefix to that request — resulting in a malformed request that may reach different application logic or expose the next user’s request to the attacker.

TE.CL Attack — Front-End Uses Transfer-Encoding

In a TE.CL attack, the relationship is reversed: the front-end honours Transfer-Encoding and the back-end honours Content-Length. The attacker sends a request where the chunked body terminates early according to the chunks, but the Content-Length header specifies a larger body size. The front-end reads the chunks and forwards what it considers the complete chunked body. The back-end reads based on Content-Length and finds it has received fewer bytes than expected — it waits for more data, which arrives as the next user’s request.

TE.CL attacks are typically harder to trigger because they require the front-end to properly honour Transfer-Encoding while the back-end ignores it — a less common configuration. They are also more dangerous in testing because the malformed state left on the back-end connection can affect subsequent users unpredictably. PortSwigger recommends always testing in a private browser tab and pausing briefly between repeated smuggling attempts to avoid poisoning real user sessions during authorised testing.

Detection with Burp HTTP Request Smuggler

Manual detection of request smuggling requires careful timing analysis and careful handling of connection state — mistakes can affect other users on the same back-end connection. The HTTP Request Smuggler extension by James Kettle automates this detection safely. It sends a series of probe requests designed to elicit differential responses or timeouts that indicate a desync condition, without sending payloads that would actually poison the connection state for other users.

After installation via BApp Store, right-clicking any request in Burp History and selecting Extensions > HTTP Request Smuggler > Launch starts the automated scan. The extension tests for CL.TE, TE.CL, and HTTP/2 downgrade variants. Results appear in the extension’s output window with severity assessments. Confirmed vulnerabilities are flagged for manual verification — the extension confirms the condition but you must manually verify the actual impact through a controlled exploit attempt.

High-Impact Exploitation Scenarios

Access control bypass. If the front-end enforces path-based access controls — blocking requests to /admin or /internal based on the request URL — a smuggled request can target these paths without going through the front-end check. The outer request targets a public endpoint (passing the front-end check). The smuggled inner request targets the restricted endpoint and is forwarded directly by the back-end as if it came from the trusted front-end. Combined with back-end IP allowlisting that trusts the front-end’s IP, this bypass can provide full access to admin interfaces.

Credential capture. In environments where multiple users share back-end connection pools, a specifically crafted smuggled request can cause the next user’s incoming request to be appended to yours. If you control an endpoint that reflects input — even just a parameter that appears in an error message — you can receive the next user’s complete HTTP request including their POST body, cookies, and any credentials or CSRF tokens they submitted. This is one of the highest-severity exploitation paths: it turns a smuggling vulnerability into credential theft from other live users.

Cache poisoning at scale. If the application uses a caching layer and the smuggled request causes a cacheable response to be stored under the wrong cache key, subsequent users requesting the legitimate URL receive the attacker’s poisoned response. This scales the impact from one affected user to every user who requests the cached URL — turning a single smuggling request into a widespread XSS or open redirect affecting all visitors.

HTTP/2 Downgrade Smuggling — 2026 Variants

HTTP/2 was expected to eliminate request smuggling because it uses binary framing rather than header-based length determination. It did not. A class of vulnerabilities discovered in 2020–2021 (H2.CL and H2.TE) exploits the architecture where the front-end accepts HTTP/2 connections but downgrades to HTTP/1.1 when forwarding to the back-end. The front-end rewrites the HTTP/2 binary frames into HTTP/1.1 text headers for the back-end — and in doing so, may faithfully include Content-Length or Transfer-Encoding headers that were in the HTTP/2 pseudo-headers, creating a desync at the HTTP/1.1 back-end level.

H2.CL attacks inject a Content-Length header via HTTP/2 that conflicts with the actual HTTP/2 frame length. When downgraded, the resulting HTTP/1.1 request has an ambiguous body length that the back-end resolves differently from the front-end. H2.TE attacks inject a Transfer-Encoding: chunked header into an HTTP/2 request — something the HTTP/2 spec explicitly forbids but many front-ends will still faithfully include in the downgraded HTTP/1.1 forwarded request. Both variants remain prevalent in 2026 and are tested by the HTTP Request Smuggler extension.

Reporting and Remediation

HTTP request smuggling reports require more technical detail than most vulnerability classes because the mechanism is non-obvious to developers who haven’t encountered it. A strong report includes: the exact desync type (CL.TE or TE.CL), the specific request pair (outer request + smuggled inner request with exact header values), evidence of the desync (timing oracle result or error response), the demonstrated impact (access control bypass, credential capture, or cache poisoning), and the remediation recommendation. Always note whether HTTP/2 is available on the target — H2 end-to-end is the most complete fix.

Remediation options for developers: enforce HTTP/2 end-to-end eliminating the HTTP/1.1 desync entirely; reject or normalise requests containing both Content-Length and Transfer-Encoding headers at the front-end; disable HTTP/1.1 keep-alive between the front-end and back-end (forces new connections for each request, eliminating connection poisoning); configure the back-end to reject ambiguous requests with a 400 rather than attempting to parse them.