Desync Attacks: Request Smuggling’s Evil Twin 🔗

Understanding the Dark Side of HTTP Parsing Vulnerabilities

HTTP desynchronization attacks represent one of the most sophisticated and dangerous classes of web application vulnerabilities discovered in recent years. While traditional request smuggling has been known since the early 2000s, modern desync attacks have evolved into a far more complex and dangerous threat, exploiting subtle ambiguities in HTTP protocol implementations to bypass security controls, hijack user sessions, and poison web caches.

What Are HTTP Desync Attacks?

HTTP desynchronization, commonly known as HTTP request smuggling, occurs when front-end and back-end servers disagree on where one HTTP request ends and another begins. This fundamental parser discrepancy creates a critical security vulnerability that attackers can exploit to inject malicious requests into connection streams, effectively “smuggling” unauthorized commands past security mechanisms.

The root cause of HTTP desynchronization is parser discrepancy, a mismatch in how different systems interpret HTTP requests due to variations in their parsing logic. When an attacker sends a carefully crafted request containing ambiguous boundary markers, different servers in a proxy chain may process it differently, leading to request smuggling opportunities.

Unlike traditional request smuggling that requires specially crafted malicious requests, modern desync attacks have evolved to include browser-powered techniques that use completely legitimate HTTP/1.1 requests. This creates new opportunities for server-side request smuggling attacks and makes client-side desync attacks a whole new class of threat.

The Anatomy of HTTP/1.1’s Fatal Flaw

The HTTP/1.1 protocol specification contains a fundamental weakness that makes desync attacks possible: it provides two different methods for specifying message boundaries.

Content-Length vs Transfer-Encoding

The vulnerability stems from two competing header mechanisms:

Content-Length Header: Specifies the exact size of the message body in bytes. When this header is present, the server reads exactly that many bytes and considers the request complete.

Transfer-Encoding: chunked: Allows the message body to be sent in multiple chunks, each prefixed with its size in hexadecimal. The message terminates with a zero-length chunk.

HTTP request smuggling vulnerabilities arise in situations where the front-end server and back-end server use different mechanisms for determining the boundaries between requests. When both headers are present in a single request, different server implementations may prioritize one over the other, creating exploitable inconsistencies.

Three Main Attack Vectors

1. CL.TE (Content-Length / Transfer-Encoding)

In this attack variant, the front-end server processes the Content-Length header while the back-end server uses the Transfer-Encoding header. The attacker crafts a request where:

The front-end reads a specific number of bytes based on Content-Length
The back-end interprets the same data as chunked encoding
Remaining bytes are treated as the beginning of a new request

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

The Transfer-encoding header is processed by the backend server, which considers the message body as chunked encoding and processes the first chunk, which is claimed to be of zero length. The “SMUGGLED” bytes remain unprocessed and are treated as a new request.

2. TE.CL (Transfer-Encoding / Content-Length)

This variant reverses the processing order:

The front-end uses Transfer-Encoding and processes chunks
The back-end uses Content-Length and reads a fixed number of bytes
The attacker can smuggle additional requests in the “leftover” chunk data

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

The front-end processes both chunks completely, but the back-end server examines the Content-length header and finds that the request body is 3 bytes long, with following bytes left unprocessed and interpreted as the start of the next request.

3. TE.TE (Transfer-Encoding Obfuscation)

In this type of HTTP request smuggling, the front end and backend both process the request using Transfer-Encoding header, but the header can be obfuscated in a way that makes one of the servers but not the other one ignore it.

Attackers exploit subtle variations in header parsing:

Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked

Each variation represents a slight departure from strict HTTP specification compliance, and different server implementations handle these variations inconsistently.

Chunked Encoding Exploitation Techniques

Chunk Extension Abuse

A new HTTP request smuggling technique was recently discovered, where attackers take advantage of inconsistent parsing behaviors between front-end proxy servers and back-end application servers by leveraging ambiguous request formatting.

HTTP/1.1 allows optional chunk extensions after the chunk size. These extensions are rarely used in practice, leading many implementations to handle them loosely or incorrectly. Attackers exploit this by:

Sending a chunk size line ending with a semicolon but no extension name
The front-end parser ignores the malformed extension
The back-end parser interprets the newline after the semicolon as the end of the chunk header
The attacker embeds a second HTTP request after the zero-length chunk

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked

0;
GET /admin HTTP/1.1
Host: localhost

The front-end sees the entire sequence as one request, while the back end treats the GET /admin as a separate, valid request.

Funky Chunks and TE.0 Vulnerabilities

Recent research has uncovered advanced techniques involving malformed chunk encodings. 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 attacks exploit edge cases in chunk processing where servers may: - Accept chunks with incorrect formatting - Process chunk extensions incorrectly - Handle chunk terminators inconsistently

Client-Side Desync: Browser-Powered 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 a back-end server to desynchronize.

How Client-Side Desync Works

Client-side desync occurs when web servers are configured or misconfigured to issue an immediate response to a POST or PUT request without first checking the content of the body. The vulnerability chain involves:

An attacker hosts malicious JavaScript on their domain
The victim visits the attacker’s page
The JavaScript causes the victim’s browser to send a specially crafted request
The server responds immediately without reading the full body
The browser reuses the same connection for subsequent requests
The leftover data from the first request pollutes the second request

This attack is particularly dangerous because: - It works against single-server architectures (no front-end/back-end split required) - It uses completely browser-compatible HTTP/1.1 requests - It can bypass same-origin policy restrictions - It enables cross-site request forgery with full response capture

Pause-Based Desync Attacks

When certain servers process a partial request that is interrupted before it’s fully received, they will time out if no more data arrives for 15 seconds, but instead of closing the connection, they leave it open for reuse.

Attackers exploit this by: 1. Sending request headers indicating a body will follow 2. Pausing for the timeout duration 3. Sending the body after timeout 4. The server treats the body as a new, separate request

This technique is particularly effective against caching servers like Varnish that maintain connection pools.

Keep-Alive Connection Exploitation

HTTP keep-alive connections, designed to improve performance by reusing TCP connections, create additional attack surface for desync vulnerabilities. Using keep-alive between HTTP servers and proxies is less common, but when used, there lies a problem of HTTP Request Smuggling.

Connection Hijacking Through Keep-Alive

When keep-alive is enabled: - Multiple requests share the same TCP connection - Connection state persists between requests - Parser desynchronization affects all subsequent requests on that connection

Attackers can exploit this by:

Request Injection: Smuggling a malicious request that will be executed in the context of the next user’s request on the same connection
Response Queue Poisoning: Causing the server’s response queue to become misaligned, delivering responses intended for one user to another
Credential Harvesting: Capturing authentication tokens from subsequent legitimate requests on the hijacked connection

The trick involves injecting a partial query in the stream and waiting for a regular user query coming in the same backend connection and added to the partial request.

Session Hijacking via Connection Reuse

Credentials used in a second query are stolen or hijacked for an attacker’s smuggled query, with damages of such issues being very high as attackers can make a user perform unwanted POST actions using their own credentials and rights.

The attack flow: 1. Attacker sends incomplete request with smuggled prefix 2. Victim’s legitimate request arrives on same connection 3. Victim’s headers (including cookies and authentication tokens) are appended to attacker’s smuggled request 4. Attacker gains access to victim’s authenticated session

HTTP/2 Downgrade Attacks

Modern web infrastructures often use HTTP/2 for client-to-server communication but downgrade to HTTP/1.1 for back-end communication. Chunked transfer encoding is incompatible with HTTP/2 and the spec recommends that any transfer-encoding: chunked header injected should be stripped or the request blocked entirely.

H2.CL and H2.TE Attacks

If the front-end server fails to properly strip or validate headers during HTTP/2 to HTTP/1.1 translation, attackers can:

Inject forbidden headers that survive protocol downgrade
Exploit CRLF injection through HTTP/2’s binary format
Smuggle requests through pseudo-header manipulation

HTTP/2 messages are binary rather than text-based, so boundaries of each header are based on explicit, predetermined offsets rather than delimiter characters, meaning CRLF can be included inside the value itself without causing the header to be split.

When downgraded to HTTP/1.1, these embedded CRLF sequences are once again interpreted as header delimiters, enabling header injection and request smuggling.

Real-World Impact and Case Studies

Major Vulnerabilities Disclosed

Recent security research has exposed critical vulnerabilities in major CDN and web infrastructure providers:

Novel attack classes disclosed at Black Hat have exposed tens of millions of websites through critical vulnerabilities in major CDN infrastructures, leveraging HTTP/1.1’s fatal flaw of weak request boundaries and multiple length specification methods.

These attacks enable: - Site Takeover: Complete compromise of web applications - Credential Hijacking: Theft of authentication tokens and session cookies - Cache Poisoning: Persistent injection of malicious content into CDN caches

The PayPal Incident

A researcher discovered vulnerabilities affecting PayPal by using line-wrapped headers that made the Transfer-Encoding header invisible to Akamai’s CDN, granting control of PayPal’s login page and resulting in a $20,000 bounty award.

The attack used:

Transfer-Encoding:
 chunked

The line wrapping caused Akamai to treat the header as invalid and ignore it, while the back-end server accepted it, creating a CL.TE desynchronization.

Apache HTTP Server Vulnerabilities

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.

Advanced Exploitation Techniques

Response Queue Poisoning

One of the most severe desync attack consequences is response queue poisoning. When a desync occurs:

The smuggled request generates a response
This response is queued but delivered to the wrong client
Subsequent responses become misaligned
All future users on that connection receive responses intended for others

This can lead to: - Exposure of sensitive user data - Cross-user session contamination - Persistent compromise until the connection closes

Web Cache Poisoning via Desync

Using Response Concatenation, it is possible to choose a response that contains a Content-Length and Cache-Control headers that forces the response to be stored in the cache.

Attackers can: 1. Smuggle a HEAD request that produces response headers only 2. The Content-Length header indicates the size of a full GET response 3. The proxy concatenates the next response (to a different user’s request) 4. The concatenated response is cached with the attacker’s injected content 5. All subsequent users receive the poisoned cached response

TRACE Method Exploitation

The TRACE method requires the server to respond to TRACE requests, and while it might seem unlikely in production environments as it should only be used for debugging, smuggling can be used to bypass firewall rules and deliver a TRACE message directly to the backend even if the method is forbidden.

The attack enables reflected XSS through desync:

POST / HTTP/1.1
Host: vulnerable.com
Content-Length: 6
Transfer-Encoding: chunked

0

TRACE / HTTP/1.1
Host: vulnerable.com
SomeHeader: <script>alert(1)</script>

The TRACE response reflects the injected script, which is then delivered to the next user on that connection.

Detection and Identification

Manual Detection Techniques

The simplest way to probe for client-side desync behavior is by sending a request in which the specified Content-Length is longer than the actual body. If the request hangs or times out, the server is waiting for the remaining bytes. If you get an immediate response, you’ve potentially found a CSD vector.

Detection workflow: 1. Identify reusable connections: Look for servers that support HTTP keep-alive 2. Test boundary parsing: Send requests with conflicting headers 3. Observe timing differences: Delayed responses indicate desync potential 4. Check for request concatenation: Monitor if parts of one request appear in another

Automated Tools and Scanning

Several tools can help identify desync vulnerabilities:

Burp Suite HTTP Request Smuggler Extension: Automated detection of CL.TE, TE.CL, and TE.TE vulnerabilities
smuggler.py: Command-line tool for mass scanning of desync vulnerabilities
Burp Scanner: Includes built-in desync detection capabilities

Both Burp Scanner and the HTTP Request Smuggler extension can help automate much of the detection process, but it’s useful to know how to do this manually to cement understanding of how it works.

Browser-Based Testing

For client-side desync testing:

Use a browser that is not proxying traffic through Burp Suite, with Chrome recommended as its developer tools provide useful troubleshooting features, enabling the Preserve log option and Connection ID column to track which connections are used for each request.

Testing with the Fetch API:

fetch('https://vulnerable-site.com', {
    method: 'POST',
    body: 'POST /internal HTTP/1.1\r\nHost: vulnerable-site.com\r\n\r\n',
    headers: {
        'Content-Length': '200'
    }
});

Defense Strategies and Mitigations

Architectural Solutions

1. HTTP/2 End-to-End

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

HTTP/2 eliminates desync vulnerabilities by: - Using binary framing instead of text-based parsing - Removing ambiguity about message boundaries - Eliminating Content-Length and Transfer-Encoding headers - Enforcing strict multiplexing rules

2. Unified Parsing Architecture

Fastly eliminates HTTP desynchronization through architectural uniformity by having a single parsing implementation across the stack, creating no room for mismatched behavior and edge cases that create vulnerabilities.

Key principles: - Use one HTTP parser implementation throughout your stack - Avoid mixing different server software versions - Implement strict request validation at every layer - Reject ambiguous requests immediately

Configuration Best Practices

Disable Connection Reuse

For back-end connections: - Do not reuse connections between front-end and back-end servers - Establish fresh connections for each request - Close connections immediately after response completion

Strict Header Validation

Reject requests containing both Content-Length and Transfer-Encoding
Enforce RFC compliance strictly
Block obfuscated header variations
Normalize requests before forwarding

Server Hardening

Apache configuration:

# Reject ambiguous requests
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

# Limit keep-alive
MaxKeepAliveRequests 100
KeepAliveTimeout 5

# Strict protocol enforcement
HttpProtocolOptions Strict

Nginx configuration:

# Disable request smuggling vectors
ignore_invalid_headers on;
client_body_buffer_size 1k;
client_header_buffer_size 1k;
client_max_body_size 1k;

Web Application Firewall Rules

Implement WAF rules that: - Detect and block duplicate headers - Identify chunked encoding anomalies - Monitor for suspicious header patterns - Alert on unusual request sizes

Following responsible disclosure, comprehensive security patches have been deployed across all affected systems, ensuring that organizations maintaining current software versions remain fully protected against HTTP request smuggling vulnerabilities.

Monitoring and Detection

Deploy monitoring for: - Unusual connection patterns - Requests with conflicting length specifications - Abnormal chunk encoding sequences - Response queue misalignments - Cache behavior anomalies

The Future of Desync Attacks

Emerging Attack Vectors

Research continues to uncover new desync techniques:

0.CL Attacks: Exploiting zero-length Content-Length headers
Expect Header Manipulation: Leveraging the 100-Continue mechanism
Protocol Chaining: Combining HTTP/2, HTTP/1.1, and WebSocket upgrades

This topic is still under-researched, and as such researchers hope this publication will help inspire new desynchronization techniques and exploits over the next few years.

Industry Response

Major infrastructure providers are taking action:

Implementing stricter parsing logic
Deploying unified parser architectures
Enhancing automated vulnerability scanning
Increasing bug bounty rewards for desync discoveries

While some providers’ load balancers remain unpatched due to compatibility concerns, and nginx lacks viable 0.CL protection, industry leaders’ strict standards enforcement eliminates entire attack classes.

Conclusion

HTTP desync attacks represent a sophisticated evolution of request smuggling that exploits fundamental ambiguities in the HTTP/1.1 protocol specification. Through chunked encoding manipulation, keep-alive connection exploitation, and browser-powered client-side techniques, attackers can bypass security controls, hijack sessions, and compromise web applications at scale.

The attacks are particularly dangerous because they: - Target infrastructure rather than application logic - Bypass traditional security mechanisms - Enable persistent compromise through cache poisoning - Work against even well-secured applications

Organizations must adopt a defense-in-depth approach combining architectural changes (HTTP/2 adoption), strict parsing enforcement, connection isolation, and continuous monitoring to protect against this evolving threat landscape.

As web infrastructure continues to evolve, staying informed about the latest desync research and maintaining updated, properly configured systems remains critical for maintaining application security. The research community continues to uncover new attack variants, making ongoing vigilance and proactive defense essential components of any security strategy.