Hunt Http Smuggling

Hunt HTTP Smuggling is an authorized methodology for finding and validating HTTP request smuggling, gated by a mandatory confirmation step requiring the user to state the target, confirm written authorization and scope, and approve the exact command before anything active runs.

It starts from a 2026 reality check: classic CL.TE and TE.CL payloads are not universally exploitable anymore, because modern proxies are RFC 9112-strict by default. A target-suitability matrix maps front-end software to which desync variants still work - Nginx 1.21+, Caddy 2.x, and Envoy 1.20+ reject the classic CL+TE conflict with an HTTP 400, while HAProxy 2.4 and below (CVE-2021-40346), older F5 BIG-IP, older Citrix ADC/NetScaler, Squid 3.x, and older Apache Traffic Server remain vulnerable to classic variants, and AWS ALB and Cloudflare-fronted chains to specific upstreams remain exploitable via H2.CL/H2.TE downgrade.

curl -sI https://target/ | grep -i "Server:"

That fingerprint informs which vector to pursue: an Nginx/Caddy/Envoy front-end means the classic CL/TE vector is dead and the tester should pivot to H2.CL/H2.TE if the front-end speaks HTTP/2, while a HAProxy or AWS/CDN Server header means the full payload matrix is worth running. H2-downgrade smuggling is framed as the modern dominant vector, arising when a front-end speaks HTTP/2 to the client but HTTP/1.1 to origin and the frame-length headers don't survive the conversion cleanly - the majority of 2024-2026 CDN-plus-origin topologies. Detection combines Burp's HTTP Request Smuggler extension with manual timing probes, where a CL.TE probe followed by a roughly 10-second delay indicates the backend is waiting for the rest of a body.

The highest-impact outcome described is a "collector gadget": rather than blindly poisoning the queue, smuggle a request at a back-end handler that echoes the full request (a search endpoint reflecting headers, or a redirect mirroring the request line), so the next victim's Cookie, Authorization, or access-token headers get attributed to the smuggled request and returned in a response the attacker reads - repeatable on a busy keep-alive socket to harvest live credentials at scale, including through a CDN when the CDN-to-origin hop desyncs.

Use it when you have explicit written authorization to assess a target for request smuggling within a bug-bounty or penetration-test engagement, after fingerprinting the front-end to confirm a viable vector exists.

Do not use it without confirmed authorization and scope - the confirmation gate blocks active probing until given. It is a docs-only methodology import and does not bundle upstream executable helpers, commands, or an engine.

Input is the authorized target's front-end server fingerprint and its CDN/origin topology. Output is a chosen smuggling vector (CL.TE, TE.CL, H2.CL, or H2.TE), a detection method (extension-based or timing-based), and - per the Pre-Severity Gate - proof that the smuggled effect lands on a different client or session's request, not the tester's own follow-up request.

Chains into hunt-cache-poison (a smuggled response cached for later victims), hunt-auth-bypass (smuggling past a front-end ACL to reach internal routes), hunt-idor (attaching another user's session cookies to a smuggled request), hunt-xss (injecting a reflected payload into the next victim's response), and hunt-ato for the credential-harvesting chain. Uses the security-arsenal payload bank and validates via triage-validation before reporting through report-writing.

Authorized penetration testers and bug-bounty researchers assessing HTTP request smuggling - people who need to know which desync vector is still viable against a given front-end stack rather than throwing dead classic payloads at a hardened target.