HTTP Request Smuggling Basics for Bug Bounty Hunters

HTTP Request Smuggling Basics for Bug Bounty Hunters

HTTP request smuggling happens when a proxy and an origin parse the same bytes differently. One side thinks the request ended. The other still has leftover data that prefixes the next user’s request.

That leftover is the “smuggled” prefix. It can poison queues, bypass front-end ACLs, or capture another user’s cookies if timing lines up.

You do not need to invent novel desync primitives on day one. You need to understand Content-Length vs Transfer-Encoding: chunked disagreements and how to detect them without melting production.

The two classic flavors

CL.TE: front-end uses Content-Length; back-end prefers Transfer-Encoding.

TE.CL: front-end uses Transfer-Encoding; back-end uses Content-Length.

Ambiguous messages — both headers present, weird chunk sizes, obfuscated Transfer-Encoding values — are the usual triggers. HTTP/2 downgrading to HTTP/1.1 on the backend opened a whole second generation of issues; start with H1 labs first so the mental model sticks.

Detection without chaos

PortSwigger’s timing technique is still the practical entry:

1. Send a request that should hang the backend if it is waiting for more body bytes.
2. Measure whether the connection stalls in a way consistent with CL.TE or TE.CL.
3. Follow with a confirmation payload that smuggles a harmless prefix (for example a request to a unique path you control on the same host) and see if a subsequent normal request gets an unexpected response.

Never smuggle destructive methods against production. Prefer unique paths and canary headers. Respect rate limits — smuggling probes are noisy when automated blindly.

What “interesting” looks like

• Front-end allows a path the back-end would reject if requested directly (ACL bypass)
• Smuggled prefix shows up in another user’s response (poisoning)
• Internal headers like X-Forwarded-For or admin cookies get rewritten by the prefix
• Cache or WAF rules apply only to the outer request, not the inner one

Reporting

Triagers want:

• Exact raw bytes (Burp “Show non-printable” on)
• Which desync class you believe you hit
• Proof that a second request was affected (capture, timing chart, unexpected body)
• Impact story tied to the app (auth bypass, cache poison, credential theft)

Include that you tested carefully and did not leave lasting poison if you can show cleanup.

Mindset check

Smuggling is infrastructure hunting. Same app, different CDN config, different outcome. Re-validate after deploys. If timing is flaky, say so — intermittent desync still matters when you can reproduce it in a controlled window.

Master CL.TE and TE.CL confirmation on labs, then graduate to H2 downgrade and header obfuscation. The hunters who earn on smuggling read bytes like a protocol, not like a form field.