Burp HTTP Request Smuggler: A Practical Extension Guide
James Kettle's HTTP Request Smuggler extension saves hours of hand-building ambiguous requests. It does not save you from understanding them. A red scanner item means two HTTP parsers may disagree; it does not automatically mean you have a clean, reportable exploit.
Install the extension from Burp's BApp Store, then start with one host you are allowed to test. Request smuggling can poison other users' connections, so this is not the place for a broad “scan everything” rule.
Set up a controlled run
Send a normal authenticated request to Repeater first. Confirm the target actually uses persistent HTTP/1.1 connections and note any CDN or reverse-proxy headers. In the extension settings, use the default probe set for the first pass and keep request concurrency low. Scope the scan to a single hostname and avoid endpoints that trigger purchases, email, deletion, or expensive jobs.
Right-click the base request and launch “Smuggle probe.” The extension tests framing patterns such as CL.TE, TE.CL, obfuscated Transfer-Encoding, and HTTP/2 downgrade variants. A front end might honor Content-Length while the back end honors Transfer-Encoding, or the reverse. That disagreement leaves bytes queued for the next request.
Read the evidence, not the color
The strongest early signal is a repeatable timing difference. One payload makes the back end wait for bytes that the front end believes have already arrived. Another clue is a follow-up request receiving a strange status, body prefix, or route that belongs to your smuggled prefix.
Open the generated requests. Learn which header mutation triggered the result:
- Duplicate or disguised
Transfer-Encoding - Conflicting
Content-Length - HTTP/2 request downgraded to HTTP/1 with unsafe framing
- A pause-based probe that avoids attacking another connection
- Backend-specific quirks around chunk extensions or line endings
Do not report the extension's issue text alone. Re-run the exact probe several times, separated by clean control requests. CDN jitter and overloaded origins create fake timing findings.
Move from probe to proof
The safest proof uses your own two requests on one connection. First, demonstrate a consistent backend timeout using the smallest malformed body. Next, smuggle a harmless prefix such as GET /404-smuggle-canary HTTP/1.1 and show that your own follow-up receives the canary response. Use a unique path so logs are easy for the program to trace.
Avoid victim capture. You do not need another user's cookie to establish parser disagreement. If the program asks for impact, explain reachable chains—front-end ACL bypass, cache poisoning, response queue poisoning—then prove only the least disruptive one they approve.
Common dead ends
Some findings disappear when Burp opens a fresh connection for every request. That often means the route is not exploitable across the real connection pool. A 400 from the CDN is also not proof that the origin parsed anything. Check whether the response came from the edge.
HTTP/2 deserves its own pass. The wire protocol has explicit frame lengths, yet downgrading proxies may manufacture an unsafe HTTP/1 request. The extension includes HTTP/2-oriented techniques; preserve the protocol selection Burp used when reproducing.
Your report should include the raw probe, control timing, affected protocol, likely front end, repeat count, and a non-destructive consequence. Recommend consistent request parsing across every hop, rejecting ambiguous framing, and using end-to-end HTTP/2 where practical.
The official HTTP Request Smuggler BApp page links the extension and research. PortSwigger's request smuggling academy explains the parser models behind its output.