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. This attack technique leverages ambiguous request formatting to inject malicious secondary requests that appear after fabricated request terminations, effectively circumventing established security controls.
Following a responsible disclosure, we have implemented and deployed security patches across all affected systems, ensuring that organizations maintaining current software versions remain fully protected against this attack vector.
This disclosure underscores the ongoing importance of rigorous HTTP request validation and the need for consistent parsing logic across distributed web architectures.
Understanding HTTP Chunked Transfer and Extensions
HTTP/1.1 allows clients to send a message body in chunks when using the header `Transfer-Encoding: chunked`. Each chunk is preceded by a chunk header containing the size (in hex) and optional chunk extensions. According to RFC 9112 (Section 7.1.1), after the chunk size you may include zero or more extensions, each prefixed by a semicolon and optionally an `=` and value. If a semicolon appears after the chunk length, it must be followed by an extension name (and an optional value); a lone semicolon with nothing after it violates the expected syntax.
Valid example:
Invalid example:
A New Desync Attack via Chunk Extension Parsing
Researchers have uncovered a request smuggling technique exploiting differences in chunk-extension parsing between front-end and back-end systems. HTTP request smuggling occurs when upstream systems (like CDNs, load balancers, or WAFs) and downstream servers disagree on where one HTTP/1.1 request ends and the next begins.
In this variant, a malformed chunk extension (bare semicolon) is used to create parsing discrepancies, following the steps below:
1. Attacker sends a chunk size line ending with ‘;’ and no extension name.
2. The front-end parser ignores the malformed extension and treats it as part of one request.
3. The back-end parser interprets the newline after ‘;’ as the end of the chunk header.
4. The attacker embeds a second HTTP request after the zero-length chunk.
5. The back-end processes this as a new request, bypassing the front-end’s security checks.
The example below shows a smuggled request:
Here, the front-end sees the entire sequence as one request, while the back end treats the `GET /admin` as a separate, valid request.
Root Cause: Lax Parsing of Unused Protocol Features
HTTP/1.1 is especially vulnerable to request smuggling because its message boundaries can be expressed in multiple ways (Content-Length, Transfer-Encoding: chunked, or delimiters). 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. Over time this “leniency” has created small parsing differences: one server might ignore an error; another might treat it as the end of a message. Features like chunk extensions, which are rarely used, make this worse, developers frequently handle them loosely or not strictly according to the RFC.
These inconsistencies mean that when a frontend proxy and a backend server disagree on where a request ends, an attacker can slip in an extra request, the essence of HTTP request smuggling.
Conclusions
With the deployment of comprehensive security patches across all affected systems, our Cloud WAF and WAF On-Prem customers who maintain current software versions are now fully protected against this HTTP request smuggling vulnerability. We continue to monitor for any emerging variants and remain committed to proactive security measures.
This vulnerability serves as a compelling reminder of the inherent risks present in HTTP/1.1’s text-based protocol design. The parsing ambiguities that enable request smuggling attacks are fundamentally rooted in the protocol’s reliance on headers and delimiters that can be interpreted inconsistently across different server implementations.
The most effective long-term mitigation against this entire class of vulnerabilities is migration to HTTP/2. Unlike its predecessor, HTTP/2 employs a binary framing mechanism that eliminates the ambiguous parsing scenarios that make request smuggling possible. As demonstrated in recent research by PortSwigger’s “HTTP/1.1 must die: the desync endgame”, HTTP/1.1 remains fundamentally insecure with new attack variants continuously bypassing existing protections.
Imperva supports end-to-end communication using the HTTP/2 protocol leveraging our delivery rules, for more information please visit this link.
We continue to actively monitor emerging HTTP request smuggling techniques and protocol-level vulnerabilities, ensuring our customers remain protected against both current and future attack vectors. Organizations planning their infrastructure roadmaps should prioritize HTTP/2 migration not only for performance benefits, but as a critical security enhancement that addresses these fundamental protocol vulnerabilities.
As web architectures continue to evolve, this incident reinforces the importance of staying current with both security patches and protocol standards to maintain robust defense against sophisticated attack vectors.
The post Smuggling Requests with Chunked Extensions: A New HTTP Desync Trick appeared first on Blog.
