X-SMU
smuggler.py
Standalone Python CLI that fingerprints HTTP request smuggling and desync issues through differential server responses.
OVERVIEW
smuggler.py (github.com/defparam/smuggler), MIT licensed and written in Python 3, is a standalone command-line alternative to the Burp-based workflow covered elsewhere on this site (see the HTTP Request Smuggler entry): it sends a configurable battery of mutated Content-Length/Transfer-Encoding request pairs at a target and looks for differential responses — timeouts, unexpected status codes, or response splitting — that indicate the front-end and back-end disagree about where one request ends, covering both classic CL.TE/TE.CL desyncs and several HTTP/2 downgrade variants.
Because it needs no proxy in the loop and runs entirely from the terminal, it drops into automated scanning scripts or CI pipelines the way HTTP Request Smuggler's Burp extension can't, at the cost of the point-and-click attack templates and live Repeater integration that the Burp extension provides for turning a confirmed desync into an exploit.
USE CASES
Practical use cases
- 01
Fingerprinting CL.TE and TE.CL desync bugs from the command line against a target behind a reverse proxy or CDN.
- 02
Running smuggling checks as an automated, scriptable step in a CI/CD pipeline against a staging environment.
- 03
Testing HTTP/2 downgrade-related smuggling variants alongside classic HTTP/1.1 header mutations.
- 04
Feeding a list of URLs via stdin to batch-check multiple hosts behind a shared front-end.
QUICK START
When a target sits behind a reverse proxy or load balancer and a scriptable command-line check is preferred over a Burp-driven workflow, to fingerprint request-smuggling desync behavior.
- Confirm the target sits behind a front-end (proxy, load balancer, CDN) and that smuggling probes at volume are within scope.
- Clone the repo and run it with Python 3 — no extra dependencies beyond the standard library are required.
- Run a scan against the target URL, or pipe a list of in-scope URLs into it for a batch run.
- Review any flagged CL.TE/TE.CL mutation and the saved payload file it writes for suspected desyncs.
- Manually replay a positive in Repeater or a raw socket tool to confirm before reporting it.
python3 smuggler.py -u https://target.example.comBEFORE YOU RUN IT
What to check before running it
A flagged mutation is a lead, not a confirmed desync — always manually replay it (Repeater, a raw socket) before reporting, since timing noise on the wire can produce false positives.
Confirmed request smuggling affects other users sharing the same front-end connection pool, not just the tester — coordinate carefully with the client before demonstrating impact on a shared production path.
A full run against every mutation and HTTP/2 variant sends a non-trivial volume of malformed requests; confirm the target's infrastructure and monitoring team expect this before running it unannounced.