HTTP/1.1 Must Die! The Desync Endgame

HTTP/1.1 Must Die! The Desync Endgame

Speaker: James Kettle (Director of Research, PortSwigger)

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: Watch the full talk

Reading time: ~10 minutes

Type: Briefing

TL;DR

James Kettle presents his fourth year of HTTP desync research and arrives at a stark conclusion: the industry has patched detection methods and scanning tools while leaving the actual vulnerability — HTTP/1.1's fundamental failure to isolate requests — largely intact. He introduces HTTP Request Smuggler v3, two entirely new attack classes (Zero CL desync and Expect-header desync), and case studies that include compromising 24 million Cloudflare-hosted websites, hijacking responses from 1 million Netlify sites, and achieving full control of auth.lastpass.com, collectively earning over $350,000 in bug bounties. His conclusion: HTTP/1.1 must be retired from upstream connections, and he launches httponemustdie.com to rally the security community around that goal.

Introduction

In 2019, James Kettle published research demonstrating that HTTP/1.1 has a fatal architectural flaw: there is no single reliable way to determine where one request ends and the next begins. When a front-end server and a back-end server disagree about request boundaries — a "desync" — an attacker can poison the back-end connection and effectively hijack other users' requests, often enabling complete website takeover. The attack class proved devastatingly effective against targets including PayPal's login page (compromised twice) and major CDN infrastructure.

Six years later, the protocol hasn't been replaced. Front-end to back-end connections still predominantly use HTTP/1.1 despite the existence of HTTP/2, which has zero length ambiguity. Instead, the industry applied a patchwork of regular expression-based detection rules and scanning-tool mitigations — closing the gates while leaving the underlying vulnerability untouched.

At Black Hat USA 2025, Kettle describes the resulting situation as "the desync endgame": everything looks secure at first glance, but a tiny change to methodology uncovers attacks hiding in plain sight. His solution is to both provide the tools to keep finding those attacks and to build the collective evidence base needed to finally retire HTTP/1.1.

The Desync Endgame: The Problem with Patching Detections

▶ Watch: The desync endgame defined (04:00)

The standard HTTP desync detection technique — sending a probe request with a Transfer-Encoding header and observing whether a second request is prefixed with unexpected data — has been systematically blocked by WAF and proxy regular expressions. The alternative timeout-based approach is even more heavily filtered.

The result: vulnerability scanners report nothing, security teams feel confident, and the actual underlying issue — that HTTP/1.1 lacks request isolation guarantees — remains unchanged. Kettle illustrates this with the Cloudflare incident: during a certain period, testing any Cloudflare-hosted website correctly (with a proper cache buster) showed no vulnerability. But testing without the cache buster caused a desync inside Cloudflare's own infrastructure, enabling persistent compromise of effectively all 24 million websites behind Cloudflare's CDN.

"This is the desync endgame. Things look like they're secure, but you make one mistake, and you end up hacking twenty-four million websites."

HTTP Request Smuggler v3: New Tools for the Endgame

▶ Watch: HTTP Request Smuggler v3 introduction (10:01)

Kettle's response to the detection-evasion arms race is HTTP Request Smuggler v3, released at Black Hat. This open-source Burp Suite extension (compatible with Pro, DAST, and the free Community Edition) goes beyond Transfer-Encoding probes to use a broad range of headers, permutations, and strategies to analyze how both the front end and back end parse a request, then identify discrepancies between them.

The tool introduces the concept of "visible hidden" and "hidden visible" discrepancies: cases where a header is seen by the front end but hidden from the back end (or vice versa), without using Transfer-Encoding at all. These discrepancies can then be converted into exploitable desyncs.

Key capabilities demonstrated:

• Detecting a hidden visible discrepancy on a web VPN used by a bank via a duplicate Host header with a malformed value
• Predicting vulnerability in servers that don't accept \n as a line terminator — a behavior the RFC permits but some servers reject, creating guaranteed discrepancies with certain proxies
• Flagging Microsoft IIS servers behind Amazon Application Load Balancer exhibiting "hidden visible" discrepancies, bypassing (and eventually triggering fixes to) AWS's HTTP Desync Guardian

An unpatched library used across many systems was also identified by the tool — Kettle cannot name it because the patch has not yet shipped.

Zero CL Desync: A Technique Previously Considered Impossible

The first new attack class addresses a problem that has long been considered a dead end.

▶ Watch: Zero CL desync concept (16:02)

A "Zero CL" (Content-Length zero) desync occurs in a "hidden visible" configuration: the front end doesn't see the Content-Length header, so it only forwards the headers to the back end, which then waits indefinitely for a body — causing a server-side connection deadlock. Because you lock up the connection every time you attempt the attack, it was widely regarded as unexploitable.

Kettle discovered the solution accidentally while researching timing attacks against nginx. Nginx would sometimes respond to a request before the client finished sending it. This "early response" behavior suggested that if a server could be made to respond early on a specific path, the deadlock could be escaped.

The implementation uses Windows reserved device names (e.g., /con, /aux) — paths that cause Windows to interpret a request as targeting a serial console or device driver rather than a file, triggering early response. When used against a back end running on Windows:

1. The attacker sends a Content-Length header that the front end can't see (hidden visible configuration).
2. The server hits the Windows device-name path and responds early without reading the body.
3. The next request that hits the server has its headers chopped off — a "mystery 400" response that Kettle's tool had been flagging as unexplained for years.

From there, a double desync chains a Zero CL desync (stage one) with a CL zero desync (stage two), using the first to weaponize the second and ultimately inject attacker-controlled content into a victim's request. An xNSS (cross-server scripting) technique — serving malicious JavaScript to live users and hijacking their accounts — was demonstrated against a real target. PortSwigger has published a Web Security Academy lab so practitioners can reproduce the entire chain in a safe environment.

Expect-Header Desync: A New Class from an Ancient Header

▶ Watch: Expect header attack class (24:03)

The Expect: 100-continue header — designed to allow clients to check whether a server will accept a request body before sending it — is decades old and widely supported. Kettle and a collaborating team of bug bounty hunters discovered it introduces a new class of desync vulnerability by injecting statefulness into HTTP proxy code that was not designed to handle it.

Representative bugs found via the Expect header:

• Servers forget they are handling a HEAD request when Expect is present, causing them to read too many bytes from the back end and creating a server-side deadlock
• Multiple different servers leak memory — including secret keys — when an Expect header is sent
• Proxies strip security-relevant response headers from only one of the two response header blocks triggered by Expect, allowing bypasses of intended security controls

Most significantly, simply sending a normal Expect header caused Zero CL desyncs on many targets — apparently due to front-end servers forgetting they hadn't yet received the body from the client when processing the back-end response. This led to:

• A $12,000 bounty from T-Mobile for a pre-production server affected by an Expect-triggered Zero CL desync
• Response queue poisoning on GitLab: by smuggling two complete requests and causing an unexpected extra response, the system lost track of which responses belonged to which users. After 27,000 requests, the team obtained access to someone else's private vulnerability report — earning a $7,000 bounty
• Response queue poisoning on Netlify, hijacking a stream of responses from over 1 million websites on the Netlify CDN (Netlify declined to pay, citing that customer websites were "out of scope")

The Akamai Exploit and LastPass

▶ Watch: Akamai and LastPass case study (30:03)

The culminating case study involves a technique that worked across a large number of websites on the Akamai CDN, including achieving full control of auth.lastpass.com — allowing the team to serve arbitrary content from LastPass's authentication domain.

Rather than report each affected site separately, the team submitted reports to individual bug bounty programs. One collaborating researcher chose not to include Kettle in several reports in exchange for not sharing the bounty; those reports ultimately generated over $200,000. Kettle's direct work with Akamai earned a $9,000 bounty and accelerated their hotfix, though it still took 65 days from that initial contact to full remediation. The total bounties across all techniques in the session exceeded $350,000.

The Path Forward: Killing HTTP/1.1

▶ Watch: How to kill HTTP/1.1 (34:04)

Kettle's argument is that all the bugs described in the session, despite being implementation bugs, share a single root cause: HTTP/1.1's poor isolation between requests, compounded by the protocol's tolerance for ambiguity and the inevitable complexity of proxy implementations.

HTTP/2 solves this. It uses binary framing with explicit length encoding — zero length ambiguity. The fix is straightforward: ensure your origin server supports HTTP/2, then enable upstream HTTP/2 on the front-end server. The client-to-front-end connection can remain HTTP/1.1 without significant risk, because those connections are not shared between users.

The obstacle: major infrastructure providers including NGINX, Akamai, CloudFront, and Fastly do not support upstream HTTP/2 as of this presentation, leaving users stuck.

For those who must continue using HTTP/1.1 upstream, Kettle recommends: regular scanning with HTTP Request Smuggler v3 (with customized adaptations to stay ahead of regex filters), and following all guidance linked from httponemustdie.com.

Notable Quotes

"Over the last six years, the industry has patched the detection methodology, patched the scanning tools, but the actual vulnerability has largely not been fixed."

— James Kettle [[▶ 04:00]](https://www.youtube.com/watch?v=FJbuAyxTTWc&t=240s)

"You make one mistake, and you end up hacking twenty-four million websites. This is the desync endgame."

— James Kettle, on the Cloudflare desync [[▶ 06:00]](https://www.youtube.com/watch?v=FJbuAyxTTWc&t=360s)

"More desync attacks are always coming. So if we want a secure web, HTTP/one needs to die — and together, we can kill it."

— James Kettle [[▶ 36:05]](https://www.youtube.com/watch?v=FJbuAyxTTWc&t=2165s)

"This is HTTP/1. It's the foundation of the web. It's made of landmines that expose millions of websites, and we've spent six years demonstrating that we're not able to fix it."

— James Kettle [[▶ 08:01]](https://www.youtube.com/watch?v=FJbuAyxTTWc&t=481s)

Key Takeaways

• HTTP/1.1 desync attacks are not a solved problem. Six years of research have produced an arms race where detection methods are patched while the underlying vulnerability — request isolation failure — remains. New techniques keep emerging because the root cause has never been addressed.
• "Zero CL desync" is now exploitable. Previously considered impossible due to server-side connection deadlock, this attack class becomes viable when the target has an "early response gadget" such as Windows reserved device name paths. The double desync technique enables full account hijacking.
• The Expect header is a new attack surface. This ancient HTTP header injects statefulness into proxy code, producing a wide range of unexpected behaviors including memory leaks, response queue poisoning, and Zero CL desyncs across multiple major infrastructure providers.
• WAFs and security middleware can introduce desync vulnerabilities. Several targets were vulnerable specifically because a web application firewall or other proxy introduced the desync — security tooling intended to protect a site can make it more exploitable.
• The fix is enabling upstream HTTP/2. HTTP/2's binary framing eliminates length ambiguity. Enabling HTTP/2 between the front-end proxy and the origin server eliminates the entire desync attack class. Organizations using NGINX, Akamai, CloudFront, or Fastly currently cannot do this and should prioritize monitoring and scanning as interim mitigations.

Slides PDF not available for this talk.