Researcher @t0xodile Published:Wednesday, 5 August 2026 at 23:30 UTC Updated:Wednesday, 5 August 2026 at 23:30 UTC In this paper we’ll show that HTTP Header Injection is severely underestimated. Forget open redirects orCross-Site Scriptingand instead, embrace the catastrophic potential of the CRLF-Powered Desync Worm. We’ll begin by teaching you how to take a simple header injection primitive and transform it into a full-blown desync worm. Next, we’ll introduce novel methods to detect and exploit IP and connection-locked desyncs which prevent cross-network exploitation by shifting the desync’s execution into the victim's browser to generate an XSS out of thin air and steal HTTPOnly cookies. Along the way, we’ll help you avoid accidental desync disasters like logging every active user of your target into your own account causing your shopping cart to be overwritten with random users’ items on every refresh. This paper was co-authored withTobia RighifromTurtleSec. Over the last year, we've collaborated on this research in order to ensure that every single technique was pushed to its absolute limit. This went rather well, and we ended up co-presenting the results at BHUSA and DEFCON. You can read his own version of the paper onTurtleSec’s blog. Around 1 year ago, we came acrossthis post on Blueskywhich mentioned an attack technique we’d heard of, but never come across in the wild. This post bothered us, as it claimed the attack was “not that uncommon” in spite of our failure to ever find it. On top of this, we knew of at least two other research papers on the same topic (both of which were in their respective year’sTop 10 Web Hacking Techniques). The first,Making HTTP header injection critical via response queue poisoningby James Kettle explains how you can achieveHTTP request smugglingusing request splitting, citing a single case study as evidence. The second,HTTP Request Splitting Vulnerabilities Exploitationby Sergey Bobrov explores how common request splitting actually is, due to a common Nginx misconfiguration, but only briefly mentions the potential for desyncs. This got us thinking. What would happen if we took James’ desync techniques, and applied them to everything that seemed vulnerable to HTTP header injection. After our first encounter, we quickly realised the technique’s potential and started to spot gaps in its current understanding. This entire paper will talk extensively about request smuggling, and therefore we highly recommend going through our freeWeb Security Academyresources if you’re not already familiar. In Nginx configurations (an extremely popular web server) if the$urivariable is included in theproxy_passdirective, Nginx willnormalisethe request path before use, url-decoding any encoded characters including CRLF sequences (%0d%0a). This allows us to inject new lines into the request that is forwarded upstream of Nginx, giving us full control over thestructureof that request. For example, here we inject an invalidContent-Lengthheader whilst maintaining the syntax of the request and produce an expected400response. To better represent the structure of these injections, we’ll use the followingHackvertorsyntax, which is extremely helpful when it comes to working with these kinds of vulnerabilities inside Burp Suite. Detection for request header injection is thankfully quite simple. Inject a header or piece of invalid HTTP syntax in order to produce a predictable status code. Historically request splitting has referred to an ultra powerful form ofCross-Site Request Forgery. However, James explained that by splitting the request intoexactlytwo requests and using a little automation, you could achieveResponse Queue Poisoning(RQP). This technique does not breach the RFC using mutated headers in any way. Two CRLF sequences in a row, are simply another boundary between requests and as a result, this technique works exceptionally well out-of-the-box. It’s worth noting that theConnectionheader is sometimes required, but not always. We recommend adding it just to experiment but for the sake of clarity, we’ve removed it from our examples. RQP is a truly glorious attack, where you smuggle two complete requests, this causes the server to lose track of which response is meant to go to who, and instead send everyone random responses intended for other users.