CVE-2026-90678 in HAProxy
Summary
by MITRE • 09/13/2026
An issue was discovered in HAProxy 3.3.0 through 3.4.4 and in 3.5-dev1 through 3.5-dev5. Exploitation requires an HTTP/3 frontend: HAProxy must be built with QUIC support and configured with a QUIC bind listener, and the affected traffic must reach a backend over HTTP/1.1 using chunked transfer coding on a reused connection. Under those conditions, when an HTTP/3 request carries no Content-Length header, the HTTP/3 multiplexer credits the length declared in a DATA frame header to the stream endpoint's known-input-payload estimate at the moment the frame header is decoded, before the payload has been received, and that declared length is emitted verbatim as the HTTP/1.1 chunk size. A remote unauthenticated client that declares more payload than it delivers and then ends the stream causes HAProxy to announce a chunk larger than the bytes it writes and to return the connection to the idle pool in a desynchronized state. The result is potential HTTP request smuggling on reused backend connections: an attacker can place a request past a frontend rule such as a path-based http-request deny, so that the smuggled request is never seen by HAProxy's HTTP analysis, and can cause concurrent clients' requests, including their request lines and Authorization headers, to be consumed as the attacker's request body and lost. Exploitation is not deterministic; it depends on a race with backend connection pooling, succeeding in a majority of but not all trials during testing, and can be retried freely. The mechanism was introduced in 3.3-dev10; releases 3.2.x and earlier are unaffected.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/13/2026
The vulnerability identified in HAProxy versions ranging from 3.3.0 through 3.4.4, as well as development builds 3.5-dev1 through 3.5-dev5, represents a critical protocol desynchronization flaw rooted in the handling of HTTP/3 to HTTP/1.1 proxying interactions. This issue specifically manifests when HAProxy is configured with QUIC support and utilizes an HTTP/3 frontend that proxies traffic to backend servers over HTTP/1.1 using chunked transfer coding on reused connections. The core technical failure lies in how HAProxy calculates the payload length for outgoing HTTP/1.1 chunks based on incoming HTTP/3 DATA frames. When an HTTP/3 request arrives without a Content-Length header, the multiplexer incorrectly credits the length declared within the DATA frame header to the stream endpoint's known-input-payload estimate immediately upon decoding that header, rather than waiting for the actual payload bytes to be received and verified. This premature estimation leads HAProxy to emit this unverified declared length verbatim as the chunk size in the subsequent HTTP/1.1 request sent to the backend server.
This discrepancy between the declared data length and the actual transmitted payload creates a state desynchronization that persists on reused backend connections, which are fundamental to maintaining performance via connection pooling. When an attacker sends an HTTP/3 request declaring more payload than is actually delivered and then abruptly terminates the stream, HAProxy proceeds to write a chunk size larger than the number of bytes it successfully transmits. Consequently, the backend server enters a desynchronized state where its expectation of incoming data no longer aligns with what has been received. This misalignment allows for HTTP request smuggling attacks on subsequent requests processed over the same pooled connection. Because the internal parser is left in an inconsistent state regarding message boundaries, HAProxy may fail to correctly parse or enforce security rules for the next client request arriving on that specific backend connection.
The operational impact of this vulnerability is severe, primarily enabling unauthorized access and data leakage through HTTP request smuggling. An attacker can exploit this desynchronization to bypass frontend-level security controls, such as path-based deny rules, by ensuring their malicious requests are not properly analyzed or blocked by HAProxy's inspection engine. Furthermore, the attack vector allows for significant confidentiality breaches; concurrent clients' requests, including sensitive information like Authorization headers and request lines, may be consumed as part of the attacker’s smuggled request body. This results in the loss of legitimate client data and potential exposure of authentication credentials to unauthorized parties who can manipulate the backend server's interpretation of subsequent traffic streams. The exploitation is not deterministic due to its reliance on race conditions involving backend connection pooling dynamics, yet testing indicates it succeeds in a majority of trials and can be retried freely until successful execution occurs.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the system fails to properly validate that the declared payload length matches the actual data received before proceeding with protocol translation. It also relates closely to CWE-367 Time-of-check Time-of-use (TOCTOU) race condition, where the state of the connection is checked and used in a manner susceptible to manipulation during the interval between checking and acting on that state. In terms of offensive security frameworks, this technique maps to ATT&CK T1502 Subverted Trust Control, specifically involving HTTP request smuggling via protocol desynchronization, which allows attackers to bypass access controls by manipulating how intermediate proxies interpret message boundaries.
Mitigation strategies must prioritize immediate version upgrades or configuration changes if upgrading is not immediately feasible. The most effective remediation is to upgrade HAProxy to a patched release that corrects the payload estimation logic for HTTP/3 to HTTP/1.1 translation, ensuring that chunk sizes are derived only from verified received data rather than unconfirmed frame headers. In environments where immediate patching is impossible, administrators should consider disabling QUIC support or avoiding configurations that mix HTTP/3 frontends with HTTP/1.1 backends using chunked transfer coding on reused connections. Additionally, implementing strict input validation and monitoring for anomalous connection states in backend servers can help detect attempts to exploit this desynchronization, although such measures are secondary to resolving the root cause within the proxy software itself.