HTTP/2 Desync: Request Smuggling’s Stealthy Evolution

Discover how HTTP/2’s binary framing introduces new smuggling vectors that bypass traditional defenses. From H2C smuggling to header name abuse, these attacks work when HTTP/1.1 protections don’t apply.

Introduction: The False Promise of HTTP/2 Security

HTTP request smuggling has plagued web applications since 2005, exploiting inconsistencies in how servers interpret request boundaries. When HTTP/2 emerged with its binary framing protocol, many believed it would eliminate these vulnerabilities entirely. After all, HTTP/2 uses explicit length fields for each data frame, removing the ambiguity that plagued HTTP/1.1’s Content-Length and Transfer-Encoding headers.

Unfortunately, this optimism proved premature. HTTP/2 downgrading—where a front-end server speaks HTTP/2 with clients but rewrites requests into HTTP/1.1 before forwarding them to back-end servers—enables a range of attacks, including HTTP request smuggling. This protocol translation creates a dangerous gap where the security guarantees of HTTP/2 evaporate, and sophisticated attackers can exploit the seams between protocols.

This article explores the evolution of request smuggling into the HTTP/2 era, examining how attackers leverage H2C smuggling, CRLF injection, and header manipulation to bypass modern security controls.

Understanding HTTP/2 Request Smuggling Fundamentals

Why HTTP/2 Was Supposed to Be Immune

HTTP/2 requests are not sent as plain text messages but instead converted to binary format. The request is represented as “frames,” where each frame has an explicit length field that tells the server how many bytes to read. This architecture eliminates the Content-Length versus Transfer-Encoding ambiguity that made HTTP/1.1 vulnerable.

HTTP request smuggling isn’t really a vulnerability in the HTTP/1.1 protocol itself, but the existence of two different ways of specifying how the request ends (Content-Length and Transfer-Encoding) leaves room for bad HTTP proxy server chain implementations. HTTP/2’s single, unambiguous length mechanism should theoretically prevent these attacks.

The Downgrade Problem

The reality is that pure HTTP/2 environments remain relatively rare. While HTTP/2 is widely used, there are still legacy back-end servers that exclusively use HTTP/1.1 since the newer protocol is still relatively new in enterprise deployments. This creates mixed environments where HTTP/2 front-ends communicate with HTTP/1.1 back-ends.

The HTTP/2 specification recommends that any request containing the Transfer-Encoding header should either have it stripped or blocked by the front-end server. But if the front-end server ignores the specification and lets the request pass with the header intact, it subsequently downgrades the request to HTTP/1.1 and forwards it to a back-end server that supports chunked encoding. This is where request smuggling vulnerabilities re-emerge.

Attack Vectors: H2.CL and H2.TE Desync

HTTP/2 to Content-Length (H2.CL) Attacks

In H2.CL attacks, the front-end HTTP/2 server passes along a Content-Length header that shouldn’t exist in the HTTP/2 context. When the request is downgraded to HTTP/1.1, the back-end server uses this header to determine request boundaries, creating opportunities for smuggling.

By redirecting JavaScript includes, attackers could execute malicious JavaScript to compromise user accounts and steal passwords and credit card numbers. By running this attack in a loop, they could gradually compromise all active users of the site, with no user interaction. Netflix experienced exactly this vulnerability, traced through their Zuul proxy to Netty, resulting in CVE-2021-21295 and a maximum bounty of $20,000.

HTTP/2 to Transfer-Encoding (H2.TE) Attacks

The RFC states that any message containing connection-specific header fields must be treated as malformed. One connection-specific header field is Transfer-Encoding. Amazon Web Services’ Application Load Balancer failed to obey this line and accepted requests containing Transfer-Encoding, enabling exploitation of almost every website using it via an H2.TE desync.

These attacks demonstrate how even major cloud providers can implement HTTP/2 incorrectly, leaving millions of websites vulnerable.

H2C Smuggling: The Cleartext Connection Upgrade Attack

What Is H2C Smuggling?

H2C smuggling represents one of the most innovative HTTP/2 attack techniques discovered in recent years. Unveiled by Bishop Fox researchers in September 2020, HTTP/2 cleartext (H2C) smuggling abuses H2C-unaware front-ends to create a tunnel to back-end systems, enabling attackers to bypass front-end rewrite rules and exploit internal HTTP headers.

Upgrading HTTP/1.1 connections to lesser-known HTTP/2 over cleartext (h2c) connections can allow a bypass of edge-proxy access controls. This technique was recognized as the top web hacking technique of 2020 by PortSwigger’s annual security community vote.

How the Attack Works

The attack exploits how HTTP connections can be upgraded from HTTP/1.1 to HTTP/2. This h2c smuggling method allows attackers to bypass proxy controls by transmitting HTTP/1.1 upgrade requests via TLS, which goes directly to back-end servers. H2C upgrades made over TLS actually violate the protocol’s specification, but many servers accept them anyway.

h2cSmuggler smuggles HTTP traffic past insecure edge-server proxy_pass configurations by establishing HTTP/2 cleartext communications with h2c-compatible back-end servers, allowing a bypass of proxy rules and access controls.

Real-World Impact

After investigating the impact of H2C smuggling across various bug bounty targets, researchers discovered various authentication, routing, and WAF bypasses across multiple cloud providers. Even cloud providers that initial research suggested would be immune proved vulnerable when the technique was applied more thoroughly.

With this type of request smuggling, you can send as many requests as you like via HTTP/2 multiplexing. HTTP request smuggling enables a wide variety of attacks, including forging internal headers, accessing restricted administrative endpoints, and sometimes Host header SSRF allowing further movement through the network.

CRLF Injection in HTTP/2 Headers

The Binary Protocol Loophole

HTTP/2’s binary nature should prevent CRLF (Carriage Return Line Feed) injection attacks that plague HTTP/1.1. However, because of HTTP/2’s binary nature, there are multiple ways to attempt to bypass protections. CRLF injection that allows header smuggling past the HTTP/2 front-end is a primary vector.

The HTTP/2 specification for header values states that a field value must not contain the zero value (ASCII NUL, 0x00), line feed (ASCII LF, 0x0a), or carriage return (ASCII CR, 0x0d) at any position. If these characters are included within a value attached to one of the headers in a request, that request should be treated as malformed and handled or dropped. Many servers fail to enforce this requirement.

Exploitation Technique

The Transfer-Encoding needs to be injected into the value of an arbitrary header with a CRLF sequence, for instance Foo: bar\r\nTransfer-Encoding: chunked. A duplicate of the arbitrary header needs to be present in the request.

When the front-end downgrades this HTTP/2 request to HTTP/1.1, it processes the CRLF characters literally, creating new header lines that didn’t exist in the original HTTP/2 request. The back-end server then sees a Transfer-Encoding header that bypassed all front-end security controls.

When attempting to exploit request smuggling in HTTP/2 to HTTP/1.1, CRLF injection is often necessary. Unlike HTTP/1.1, which is text-based, HTTP/2 is a binary protocol and no longer uses the same delimiters to structure requests. When a front-end server converts an HTTP/2 request into HTTP/1.1, it may interpret certain binary characters as line breaks, allowing an attacker to inject additional headers and manipulate the rewritten request.

Response Queue Poisoning and Session Hijacking

Understanding Response Desynchronization

One of the most severe desync attack consequences is response queue poisoning. When a desync occurs, this can lead to exposure of sensitive user data, cross-user session contamination, and persistent compromise until the connection closes.

A response queue poisoning works by smuggling an extra request after the first one. The first request triggers the response queue desynchronization, causing users to receive responses belonging to other users.

Session Theft in Practice

Using response queue desynchronization along with traditional HTTP/1.1 request smuggling techniques, attackers can capture requests from legitimate users, enabling account takeover and access to sensitive information.

The attack proceeds as follows: an attacker sends a carefully crafted request that causes desynchronization, then subsequent legitimate user requests become appended to attacker-controlled prefixes. The attacker can capture session cookies, authentication tokens, and other sensitive data from victims who happen to send requests immediately after the attack.

Client-Side Desynchronization: A New Frontier

Beyond Server-to-Server Attacks

One of the most significant recent developments in desync attack research is the discovery of client-side desynchronization (CSD) attacks. A client-side desync is an attack in which the victim’s web browser is tricked into desynchronizing its connection to the vulnerable website, different from regular request smuggling attacks which cause the connection between a front-end server and back-end server to desynchronize.

This evolution means that even architectures designed to isolate user connections can be vulnerable, as the attack targets the client’s own connection rather than shared server infrastructure.

Advanced Techniques: Header Name Abuse and Encoding Tricks

Exploiting Weak Header Validation

Cloudflare applied weaker validation after the 100th header before forwarding the request to an upstream server. If a client’s HTTP server accepts and parses HTTP headers that end with a tab or space character, this can lead to request/response desynchronization in HTTP/1.1 caused by the initial HTTP/2 attacker’s request.

While colons, newlines, and A-Z characters are still prohibited in smuggled headers, spaces and tabs are enough to perform the attack in some cases. To trigger HTTP desynchronization in keep-alive HTTP connections, an attacker can use something like “transfer-encoding : chunked” (note the space before the colon).

Emerging Attack Variants

Research continues to uncover new desync techniques: 0.CL attacks exploiting zero-length Content-Length headers, Expect header manipulation leveraging the 100-Continue mechanism, and protocol chaining combining HTTP/2, HTTP/1.1, and WebSocket upgrades. This topic remains under-researched, with security professionals continuing to discover new exploitation techniques.

Recent Vulnerabilities and Real-World Examples

Notable CVEs

Several critical vulnerabilities demonstrate the ongoing threat:

CVE-2023-25690 affected Apache HTTP Server where mod_proxy rewrite rules could be chained for request splitting and smuggling, fixed in version 2.4.56. CVE-2023-25950 impacted HAProxy 2.⁷⁄₂.6 where the HTX parser mishandled pipelined requests. CVE-2022-41721 affected Go’s MaxBytesHandler, causing leftover body bytes to be parsed as HTTP/2 frames, enabling cross-protocol smuggling.

Apache HTTP Server versions through 2.4.63 contained vulnerabilities that could allow man-in-the-middle attackers to perform HTTP desynchronization attacks and hijack HTTP sessions during TLS upgrades. The CVE-2025-49812 vulnerability specifically allowed attackers to exploit TLS upgrade functionality to perform desync attacks, demonstrating how even encrypted connections can be vulnerable.

Bug Bounty Impact

In 2024, resilience to TE.0 and funky chunks vulnerabilities became critical, with 2025 seeing confirmation of immunity to Expect-based and 0.CL attacks worth over $350,000 in bounties. These substantial payouts reflect the severity of HTTP/2 desync vulnerabilities.

Detection and Testing Tools

Professional Testing Approaches

TRACE requests can be really helpful when analyzing a smuggling vulnerability. The response shows exactly what is being received by the back-end, giving information about headers that are modified or added by the proxy and even protocol modifications, such as downgrading from HTTP/2 to HTTP/1.1, which is the source of many desync vulnerabilities.

Several tools assist security professionals in identifying these vulnerabilities:

Burp Request Smuggler since v1.26 automatically tests H2.TE/H2.CL and hidden ALPN support—enable “HTTP/2 probing” in the extension options. h2cSmuggler is a Python proof-of-concept by Bishop Fox to automate the cleartext upgrade attack.

The open-source tool http2smugl allows engineers, DevOps, and security teams to check their load balancers for HTTP/2 request smuggling vulnerabilities for free, and is also useful for bug bounty research and further vulnerability discovery.

Prevention and Mitigation Strategies

Primary Defense: End-to-End HTTP/2

To prevent HTTP request smuggling vulnerabilities, use HTTP/2 end to end and disable HTTP downgrading if possible. HTTP/2 uses a robust mechanism for determining the length of requests and, when used end to end, is inherently protected against request smuggling.

Make sure to use HTTP/2 end-to-end connections and do not downgrade them. This will prevent all downgrade-based attacks. If you are setting up or managing an HTTP/2 server, especially one that supports downgrading, make sure to reject requests containing overly ambitious headers specifying the request body’s size.

When Downgrading Is Unavoidable

If you can’t avoid HTTP downgrading, make sure you validate the rewritten request against the HTTP/1.1 specification. Additional measures include:

Reject ambiguous requests containing both Content-Length and Transfer-Encoding, on both the front-end and the back-end. Avoid reusing connections between the front-end server and back-end in order to prevent the persistence of out-of-sync requests. Deploy a WAF configured to detect and block attempts to exploit request smuggling. Harmonize the technology stack by using the same server for the front-end and back-end to avoid differences in parsing and interpretation of HTTP requests.

H2C-Specific Mitigations

Mitigation for H2C smuggling is simple—strip or hard-code the Upgrade header at the edge except for WebSockets.

Maintaining defense-in-depth strategies, reducing the significance of smuggled headers in your architecture, and being prepared to identify and reject suspicious requests on the back end will help reduce the impact of future attack techniques.

CRLF Injection Prevention

Another mitigation strategy is to block any headers containing specific sequences, such as the CRLF sequence. Servers should strictly enforce the HTTP/2 specification’s prohibition on carriage return and line feed characters in header values.

Future Outlook and Emerging Trends

The Persistence of HTTP/1.1

HTTP/1.1 is especially vulnerable to request smuggling because its message boundaries can be expressed in multiple ways. The RFCs define strict rules, but in practice many servers were built at different times against different interpretations of those rules. To stay compatible with real-world clients, implementations often accept slightly malformed requests instead of rejecting them.

HTTP request smuggling remains prevalent because so many modern applications still rely on legacy HTTP/1.1 stacks rather than the current best-practice successor, HTTP/2. Moreover, patching is often challenging due to inconsistent support for the HTTP protocol across different server environments.

Ongoing Research

Smuggling attacks, including desync, are major threats for the modern web and remain relevant for both HTTP/1.1 and HTTP/2. As researchers continue to examine the interaction between protocols, new attack vectors will likely emerge.

Conclusion

HTTP/2 desync attacks represent a sophisticated evolution of request smuggling that exploits the gap between protocol versions. While HTTP/2’s binary framing was designed to eliminate the ambiguity that enabled traditional smuggling attacks, the widespread practice of downgrading requests to HTTP/1.1 for back-end communication reintroduces these vulnerabilities.

Organizations must recognize that simply adopting HTTP/2 at the edge doesn’t provide complete protection. True security requires end-to-end HTTP/2 implementation, strict header validation, careful handling of protocol upgrades, and ongoing vigilance against new attack variants.

As web infrastructure continues to evolve, the interaction between different protocol versions will remain a rich target for attackers. Security teams should prioritize eliminating HTTP downgrading where possible, implementing robust header validation, and staying current with emerging research in this rapidly developing field.

Key Takeaways:

HTTP/2 downgrading reintroduces request smuggling vulnerabilities that pure HTTP/2 would prevent
H2C smuggling bypasses edge proxy controls by exploiting cleartext upgrade mechanisms
CRLF injection in HTTP/2 headers can smuggle additional headers past front-end validation
End-to-end HTTP/2 is the most effective defense against these attacks
Ongoing research continues to uncover new exploitation techniques in protocol interactions