X-BUR
Burp HTTP Request Smuggler
PortSwigger's free BApp Store extension for detecting and exploiting HTTP request smuggling and desync vulnerabilities.
OVERVIEW
HTTP Request Smuggler is James Kettle/PortSwigger's official Burp extension (installable straight from the BApp Store, or manually from github.com/PortSwigger/http-request-smuggler) that automates the tedious part of finding request-smuggling vulnerabilities: it actively probes every request that passes through Burp for signs that the front-end (proxy, load balancer, CDN) and back-end server disagree about where one HTTP request ends and the next begins.
Beyond detection, it ships pre-built attack templates for turning a confirmed desync into something concrete — smuggling a request past a front-end access control, poisoning another user's response, or feeding an ambiguous request into a web cache — that plug directly into Repeater once a candidate is found. It works alongside the base Burp Suite proxy workflow (see the separate Burp Suite entry on this site) and runs in both Community and Professional.
USE CASES
Practical use cases
- 01
Scanning traffic passing through Burp for CL.TE/TE.CL/TE.TE desync signatures between front-end and back-end.
- 02
Turning a confirmed desync into a request-smuggling attack that bypasses a front-end access control or WAF rule.
- 03
Poisoning the response another user receives by smuggling a request that lands in front of their connection.
- 04
Feeding a smuggled request into a downstream cache to achieve web cache poisoning.
QUICK START
When a target sits behind a reverse proxy, load balancer, or CDN, to probe for request-smuggling desync bugs between the front-end and back-end.
- Confirm active desync probing is authorized — malformed requests can affect other real users sharing the same front-end/back-end pair.
- Install the extension from the BApp Store (Extender > BApp Store) or load the JAR manually.
- Browse the target through Burp's proxy so the extension can passively scan in-scope traffic for desync signatures.
- Send a flagged request to Repeater and use the extension's attack templates to confirm and characterize the smuggling primitive.
BEFORE YOU RUN IT
What to check before running it
Desync attacks are inherently disruptive to a shared front-end — a mistimed probe can corrupt another real user's request or response, so coordinate timing on production targets.
Findings are highly infrastructure-specific: the same payload can be harmless on one CDN/proxy combination and cause an outage on another, so start conservatively.
Results depend on the exact proxy chain in front of the target, which pentesting from outside a client's network may not fully replicate — note the observed topology in the report.