Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-13T04:17:25.227Z",
  "pubdate": "2026-09-13T04:17:25.227Z",
  "executiveSummary": "This vulnerability is an HTTP request smuggling flaw within the HAProxy QUIC multiplexer, affecting versions 3.3.0 through 3.4.4 and 3.5-dev1 through 3.5-dev5.\nThe issue arises from a synchronization failure during protocol translation between HTTP/3 frontends and HTTP/1.1 backends using chunked transfer coding.\nA remote unauthenticated attacker can exploit this condition to bypass HAProxy frontend security rules, such as path-based denials, by smuggling arbitrary requests through connection pools.\nSuccessful exploitation results in request desynchronization, potentially causing sensitive data—including request lines and Authorization headers from concurrent client sessions—to be ingested as the body of the attacker-controlled request.\nThe vulnerability requires the HAProxy instance to be configured with a QUIC bind listener and for backend connections to utilize HTTP/1.1 with chunked transfer coding.\nExploitation is non-deterministic, relying on a race condition related to backend connection reuse, but it is repeatable, allowing for sustained attempts until success.\nThe risk is critical for environments where HTTP/3 is exposed and backend connection pooling is enabled, as it undermines the integrity of the proxy's HTTP analysis engine.",
  "technicalDetails": "The root cause is a race condition in the HAProxy HTTP/3 multiplexer where the stream endpoint's input-payload estimate is improperly updated. When processing an HTTP/3 request lacking a Content-Length header, the multiplexer decodes the DATA frame header and prematurely credits the declared length to the known-input-payload estimate before the actual payload bytes are received.\nDuring the translation process to the backend, this declared length is emitted verbatim as the HTTP/1.1 chunk size. If a remote attacker delivers fewer bytes than the declared length and terminates the stream, HAProxy fails to account for the discrepancy.\nThis creates an inconsistency where the frontend considers the request complete while the backend expects more data, leading to the connection being returned to the idle pool in a desynchronized state.\nThe attack flow follows these steps: 1) The attacker initiates an HTTP/3 request with a specific DATA frame length declaration exceeding the actual body sent. 2) HAProxy forwards this request to an HTTP/1.1 backend using chunked encoding, establishing an expectation of a larger body. 3) The attacker terminates the stream prematurely. 4) The proxy, having miscalculated the stream state, incorrectly marks the connection as free for the next request. 5) Subsequent traffic from legitimate clients is then injected into the incomplete chunked sequence of the attacker's request, causing the legitimate data to be treated as part of the malicious request body.\nThis behavior facilitates HTTP request smuggling, as the smuggled request bypasses the HAProxy layer-7 parsing and validation logic entirely. Because the backend processes the attacker's smuggled request as part of the same underlying connection as the subsequent legitimate client requests, the attacker can hijack sensitive headers, such as session tokens or Authorization strings, effectively performing session theft or bypassing security policies.\nThe vulnerability was introduced in 3.3-dev10, affecting all 3.3.x and 3.4.x releases up to 3.4.4, as well as 3.5-dev1 through 3.5-dev5. Releases 3.2.x and earlier remain unaffected as they lack the specific implementation of the faulty QUIC multiplexer logic. Exploitation is constrained by the necessity of a reused backend connection, making it non-deterministic; however, the ability to retry the attack makes it a viable threat vector in production environments leveraging keep-alive connections."
}