CVE-2026-90678

HAProxy 3.3.0 through 3.4.4 and 3.5-dev1 through 3.5-dev5 mishandle HTTP/3 DATA frame accounting: when an HTTP/3 request carries no Content-Length, the length declared in the DATA frame header is credited to the stream before the payload arrives and is emitted verbatim as the HTTP/1.1 chunk size sent to the backend. A remote unauthenticated attacker can declare more payload than they deliver and end the stream, causing HAProxy to announce an oversized chunk and return a desynchronized connection to the backend idle pool. This enables HTTP request smuggling on reused backend connections — the attacker can slip a request past frontend rules such as a path-based http-request deny so it is never inspected by HAProxy's HTTP analysis, and can cause concurrent clients' request lines and Authorization headers to be consumed as the attacker's request body and lost. Only deployments built with QUIC support and configured with an HTTP/3 (QUIC) bind listener that proxy to HTTP/1.1 backends using chunked transfer coding on reused connections are affected; the mechanism was introduced in 3.3-dev10, so 3.2.x and earlier are unaffected. Exploitation is probabilistic (a race with backend connection pooling that succeeds in most but not all trials and can be retried freely); no public PoC and no in-the-wild exploitation are known.

What to do: Upgrade to a HAProxy release newer than the affected ranges (later than 3.4.4 or 3.5-dev5) as soon as a fixed build is available. Until then, remove or disable QUIC bind listeners on frontends (or rebuild without QUIC support), or disable backend HTTP connection reuse (e.g., http-reuse never) with HTTP/1.1 chunked backends to break the desynchronization-on-reuse chain. Also review frontend deny/ACL rules and backend logs for requests that bypassed path-based controls or clients reporting lost Authorization headers.