At Black Hat USA and DEFCON 2025, PortSwigger's Director of Research, James Kettle, issued a stark warning: request smuggling isn't dying out, it's evolving and thriving.
Despite years of defensive efforts, new research unveiled by Kettle proves that HTTP request smuggling (or "desync" attacks) remain not only rampant but dangerously underestimated, compromising tens of millions of supposedly well-secured websites worldwide.
In his groundbreaking new research, HTTP/1.1 Must Die: The Desync Endgame, Kettle challenges the security community to completely rethink its approach to request smuggling. He argues that, in practical terms, it's nigh on impossible to consistently and reliably determine the boundaries between HTTP/1.1 requests, especially when implemented across the chains of interconnected systems that comprise modern web architectures. Mistakes such as parsing discrepancies are inevitable, and when using upstream HTTP/1.1, even the tiniest of bugs often have critical security impact, including complete site takeover.
This research demonstrates unequivocally that patching individual implementations will never be enough to eliminate the threat of request smuggling. Using upstream HTTP/2 offers a robust solution.
If we are serious about securing the modern web, it's time to retire HTTP/1.1 for good.
Request smuggling lives in the cracks between systems, whether that be proxies, CDNs, or distributed backends. HTTP/1.1 is full of ways for those systems to disagree about request boundaries.
PortSwigger's latest research has confirmed an uncomfortable truth: not only are request smuggling vulnerabilities still extremely prevalent, attempts to mitigate them have in fact just made them harder to spot. In many cases, these mitigations have in fact just compounded the problem by adding yet more complexity to how systems are supposed to determine where each request starts and ends.
Several major CDNs were found to be vulnerable to new desync vectors and subtle variations on well-known exploits, exposing over 24 million of their customers' websites.
This isn't an academic risk; after bypassing supposedly battle-hardened mitigations entirely, the researchers were awarded over $200,000 in bug bounties from these techniques, highlighting both the prevalence and severity of the problem.
If your stack uses HTTP/1.1, anywhere, you're relying on brittle defenses and dangerous assumptions that simply don't stand up to scrutiny.
If you're the in-house pentester responsible for securing a sprawling web estate, you already know the job is never done. But some threats are so foundational, they demand a shift in strategy, not just another test case for your checklist.
If you're focused on the usual application logic, input validation, or authentication flaws, you're probably missing critical threats lurking in your stack. Desync bugs stem from infrastructure-level flaws. That's why they evade scanners and manual tests conducted using subpar tooling.
Break shallow assumptions: HTTP downgrading is especially risky. Systems claiming HTTP/2 support often rely on HTTP/1.1 internally, reintroducing all the ambiguities that desync attacks rely on and, in fact, making the problem far worse.
Evade brittle defenses: Current defences rely on regex-based filters and header normalization, which can be easily bypassed. In fact, many vendors just fingerprint known payloads, giving you the illusion of security without protecting them against the underlying issue.
Go where other testers can't: Supposedly mature setups can exhibit parsing mismatches that quietly open the door to desync exploitation, even in cases where the established testing methodology doesn't flag any obvious issues. You can no longer rely on default test cases or shallow scans; desync attacks demand protocol-level thinking, so your tooling and methodology need to reflect that.
As a pentester, you're tasked with continuously assessing and challenging your organization's defenses. Here's how you can take the lead:
Don't fall behind the curve
James Kettle's latest whitepaper gives you a clear picture of how desync attacks are evolving in 2025, so you can better assess your organization's exposure and stay ahead of real-world threats. More desync vectors are inevitable, so it's vital to understand the underlying threat from which these vulnerabilities arise.
Need a refresher? The Web Security Academy has over 20 free, hands-on request smuggling labs designed to sharpen your skills through guided practice in a safe, realistic environment. There's even a brand new lab that explores a previously hypothetical desync vector uncovered during this research.
Audit your estate for parser discrepancies
Established techniques for request smuggling detection often misses vulnerabilities due to superficial defences that simply block known request smuggling patterns. PortSwigger's latest research introduces a far more effective approach. By focussing on desync primitives, the parsing discrepancies at the heart of the problem, you can evade these wafer-thin defences and check whether you're really secure.
With the new and improved HTTP Request Smuggler v3.0 extension for Burp Suite, you can automate this approach to quickly surface parsing anomalies across your web stack, giving you a clearer picture of potential desync risks that might otherwise go undetected.
Get complete visibility into how your stack handles HTTP traffic
One of the key challenges of request smuggling detection is understanding what's happening to your requests when you can't see how they're being transformed in transit. Complex chains of proxies, CDNs, and application servers can obscure critical behaviors.
The new HTTP Hacker extension for Burp Suite puts you in control. It reveals hidden protocol details, like persistent connections and pipelining, so you can map the true flow of requests through your stack. It's like an X-ray for your proxy chain, giving you the clarity you need to uncover and exploit high-impact vulnerabilities that would otherwise remain hidden.
Scale Desync Detection Across Your Entire Estate
Manually testing for request smuggling across potentially thousands of web assets is challenging, especially if you're already struggling to keep up with the ever-growing demands placed on AppSec teams.
Burp Suite DAST helps you scale your efforts by automatically scanning thousands of assets using the latest detection techniques developed by Kettle, irrefutably the leading authority on this critical vulnerability class.
Built on the same research-backed approach, it's the only DAST solution with enterprise-grade support for true desync detection, giving you broader coverage without sacrificing depth.
Start planning your HTTP/1.1 exit strategy
Although we've armed you with the knowledge and tooling you need to identify dormant desync vectors lurking in your stack. However, the only real fix is to eliminate HTTP/1.1 altogether. Start roadmapping a phased deprecation, particularly for internal connections and APIs.
"You've got the illusion of security thanks to toy mitigations and selective hardening that only serves to break the established detection methodology. In truth, HTTP/1.1 is so densely packed with critical vulnerabilities, you can literally find them by mistake." Kettle writes.
Protecting your systems now means acknowledging that the protocol itself is broken.
This demands a shift in mindset:
PortSwigger isn't just raising the alarm; we're arming you with the tools to act:
Burp Suite offers unmatched desync detection and exploration capabilities, thanks to rich HTTP/1 and HTTP/2 support, HTTP Request Smuggler and the new HTTP Hacker extensions. This ensures you aren't shackled by subpar tooling with superficial support for testing anything beyond simple, application-level issues.
DAST at scale: Burp Suite DAST identifies request smuggling vectors across your estate using reliable, primitive-level detection techniques that bypass flawed defences and reveal the true extent of your exposure to desync attacks.
Education-first: Our free labs and industry-defining research translate cutting-edge insights into actionable training.
Test your systems. Prove the risk. Drive internal change.
And above all, join us in declaring: HTTP/1.1 must die.
