Desync Attacks in Bug Bounty: Beyond Classic Smuggling
“Desync” is the broader label for parser disagreements across HTTP hops. Classic request smuggling is one branch. Newer work covers HTTP/2-to-HTTP/1.1 downgrade quirks, client-side desync, and response queue confusion where answers get paired with the wrong sockets.
If you already know CL.TE, this is the next layer programs still under-test.
Why desync kept evolving
Front-ends speak HTTP/2. Many origins still expect HTTP/1.1. The translation layer must split multiplexed streams into ordered H1 requests. Any bug in that translation — injected CRLFs, malformed pseudo-headers, length mismatches — can splice requests or responses.
Browsers joined the party too. Some desync primitives are launched from a victim’s browser toward a vulnerable front-end, which widens impact beyond attacker-controlled sockets.
Attack themes you will see in writeups
Request smuggling / request queue poison. Leftover bytes prepend the next request.
Response queue desync. Responses are matched incorrectly; you might receive another user’s HTML.
Cache deception via desync. Poisoned responses land in shared caches under safe-looking keys.
WAF / ACL bypass. The outer request looks harmless; the inner request hits a privileged route.
James Kettle’s PortSwigger research posts are required reading here — not as trivia, as a map of which gadgets still appear on CDNs.
A pragmatic hunt loop
- Identify the edge (CDN, reverse proxy, API gateway) and whether H2 is terminated there.
- Probe for H1 ambiguity first if H1 is still accepted on the edge.
- For H2, test downgrade-sensitive gadgets carefully: CRLF in headers the translator might copy, conflicting lengths, weird method/path combos allowed by the front-end.
- Use distinct canary paths and correlation IDs so a stray response is obviously yours.
- Stop when you have one clean, reproducible chain. Do not spray.
Lab time beats live guessing. Desync bugs punish sloppy automation.
Evidence triagers trust
Screenshots alone rarely cut it. Capture:
- Full request/response pairs showing the mismatch
- Two-connection experiments (attacker connection vs victim connection)
- Cache HIT headers when poisoning is involved
- Exact timestamps proving cross-user effects
State residual risk: could a real user have been affected during testing? Programs care.
Common dead ends
- Desync against a single-origin lab setup that does not mirror production hops
- “Weird 400s” with no second-request influence
- Tools that rewrite your raw bytes and destroy the primitive
Desync hunting is high effort, high signal when it works. Treat every confirmed splice as infrastructure impact, write the report like an incident timeline, and leave the target cleaner than you found it.