HTTP Request Smuggling Detection
HTTP request smuggling exploits disagreements between frontend proxies and backend servers over where one HTTP request ends and the next begins. A successful smuggle can poison the request queue, bypass security controls, hijack other users' requests, and trigger reflected XSS. Detection confirms whether the frontend and backend parse Transfer-Encoding and Content-Length headers differently.
CL.TE Detection
The frontend uses Content-Length, the backend uses Transfer-Encoding. Send a request where the CL says the body ends before TE terminates. If the backend keeps a fragment from your request and prepends it to the next request, smuggling is confirmed:
TE.CL Detection
The frontend uses Transfer-Encoding, the backend uses Content-Length. Send a chunked request with a large claimed Content-Length. The backend waits for more data, causing a timeout if TE.CL smuggling is possible:
smuggler.py for Automated Detection
smuggler automates CL.TE and TE.CL probes across all methods and obfuscation variants:
[+] CL.TE Possible! Timeout detected on chunked body
A timeout or unexpected response from smuggler confirms a desync condition. Manual verification with timing is more reliable than automated tools alone — follow up with a manual probe to confirm before reporting.
TE Obfuscation Variants
Some frontends strip a well-formed Transfer-Encoding header but pass obfuscated variants to the backend. Test these when standard headers are not triggering a desync:
References
-
PortSwigger — HTTP Request Smugglingportswigger.net/web-security/request-smuggling (opens in new tab)
CL.TE and TE.CL detection methodology and timing-based confirmation
-
Automated HTTP request smuggling detection tool
Was this helpful?
Your feedback helps improve this page.