Runbook: HTTP request smuggling and desync¶

HTTP request smuggling exploits disagreement between the way a front-end proxy and a back-end server parse the boundaries of HTTP requests. When two servers interpret the same request differently, one of them treats the trailing bytes as the beginning of the next request. This allows an attacker to prepend data to another user’s request, or to inject a complete request that the server processes under the attacker’s control but attributes to someone else.

Modern variants extend this to HTTP/2 downgrade scenarios and client-side desync, where the victim’s browser can be caused to make a request that the back-end interprets as containing an injected prefix.

Prerequisites¶

• Burp Suite Pro with Turbo Intruder and HTTP Request Smuggler extension.

• Understanding of the target’s reverse proxy stack (nginx, HAProxy, AWS ALB, Cloudflare).

• An OOB detection channel (Burp Collaborator).

Phase 1: Detect the vulnerability class¶

Most targets are either CL.TE (front-end uses Content-Length, back-end uses Transfer-Encoding) or TE.CL (front-end uses Transfer-Encoding, back-end uses Content-Length).

Run HTTP Request Smuggler (Burp extension) against the target host to automate initial detection. Review any flagged responses for timing differences or unexpected response data.

Manual CL.TE timing probe¶

A CL.TE vulnerability causes the back-end to wait for additional data after the front-end has already closed the request. This produces a time delay:

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

0

X

The front-end reads 6 bytes (the chunk terminator 0\r\n\r\n and X) and forwards. The back-end treats the chunked encoding as definitive: after receiving the 0 chunk, it waits for the next request. The X byte is left in the buffer. If the response is significantly delayed, CL.TE is likely present.

Manual TE.CL timing probe¶

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

1
Z
Q

The front-end uses Transfer-Encoding and processes the 1\r\nZ\r\n chunk, then sees Q and waits for the next chunk. The back-end uses Content-Length (3 bytes: 1\r\n). The remaining data is left in its buffer. If the response is delayed, TE.CL is present.

Phase 2: Confirm with socket reuse¶

Timing probes can be caused by legitimate network conditions. Confirm with a technique that produces a detectable second-order effect.

For CL.TE, smuggle a request prefix that produces an anomalous response for the next request on that connection:

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

0

GET /admin HTTP/1.1
X-Ignore: X

Send the request twice on the same connection. If the second response returns /admin content rather than the root page, the prefix was injected into the subsequent request.

Phase 3: HTTP/2 desync¶

HTTP/2 uses binary framing and never has CL/TE ambiguity at the HTTP/2 layer. The vulnerability appears when the HTTP/2 front-end downgrades to HTTP/1.1 when communicating with the back-end, introducing the ambiguity during translation.

In Burp, set the request to HTTP/2 using the Inspector panel. Test whether injecting a Transfer-Encoding: chunked header into the HTTP/2 request causes the back-end to behave as it would in a classic TE.CL scenario.

Also test HTTP/2 header injection: some front-ends allow HTTP/2 headers containing newlines that, when translated to HTTP/1.1, introduce additional headers or split the request.

Name the variant by which length field each end honours after the downgrade: H2.CL (back-end trusts an injected Content-Length) and H2.TE (back-end trusts an injected Transfer-Encoding). CRLF injection into an HTTP/2 header value can split the request outright (request splitting) rather than merely prepending a prefix.

A related case is CL.0, where the back-end ignores the Content-Length on certain endpoints (static files, redirects) and treats the body as the next request. Test it by sending a body behind a request to such an endpoint and watching whether the body is interpreted as a standalone request on connection reuse.

Phase 4: Client-side desync¶

Client-side desync does not require control of the network path between the client and server. It works when the server itself responds to an initial request in a way that causes the client’s connection to become desynchronised.

Test endpoints that respond to a request with a short response and leave a connection alive. If the server can be caused to respond without consuming the full request body, the remaining bytes may be prepended to the victim’s next request on the same connection:

POST /endpoint HTTP/1.1
Host: target.com
Content-Length: 34

GET /admin HTTP/1.1
X-Ignore: X

This requires testing in Burp’s browser with repeat-connection mode disabled, so that the browser reuses connections as a real browser would.

Phase 5: Attack development¶

Once a desync is confirmed, common exploitation paths are:

Capturing other users’ requests: smuggle a request prefix that forwards the victim’s subsequent request to an attacker-controlled endpoint.

Bypassing access controls: prepend a prefix that sets a trusted header (X-Forwarded-For: 127.0.0.1, X-Internal: true) that the back-end uses to bypass access restrictions.

Delivering reflected XSS via a smuggled response: smuggle a request that causes the server to respond with a reflected XSS payload to the victim’s browser.

Response queue poisoning: smuggle a complete request so the connection’s responses shift by one, and every subsequent user on that connection receives a response meant for someone else.

Web cache poisoning and deception: smuggle a request whose response is cached against a victim-facing URL (poisoning), or that causes a victim’s authenticated response to be stored in a cache an attacker can read (deception). This hands off to the web cache poisoning runbook.

All attack development is best performed carefully against non-production or with prior coordination to avoid affecting other users during testing.

Output¶

• Confirmed desync type (CL.TE, TE.CL, H2.CL, H2.TE, client-side).

• Infrastructure details: reverse proxy and back-end technology identified.

• Demonstrated impact: access control bypass, request capture method, or XSS delivery.

Techniques¶

• HTTP request smuggling

Counter moves¶

Runbook: HTTP request smuggling and desync is what this page works through. The durable answers are server-side validation, authorisation, and dependency hygiene. The defensive counterpart is in the blue notes on the application layer as a target.