CVE-2026-90678: High severity HAProxy HAProxy vulnerability

Published Sep 13, 2026
·
Updated

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.

Affected Software

1 affected component
HAProxy HAProxy>=3.3.0<=3.4.4, >=3.5-dev1<=3.5-dev5

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade haproxy to a version that resolves this vulnerability.

    Fixed in 3.5-dev6Patch BUG/MAJOR: h3: reject H3 truncated frames
  2. Compensating control

    If upgrading is not immediately possible, restrict or avoid HTTP/3 frontends that use QUIC (build HAProxy with QUIC support and configure a QUIC bind listener) to reduce exposure to the described HTTP/3-specific desynchronization/request smuggling scenario.

Event History

Sep 13, 2026
CVE Published
via MITRE·03:37 AM
Data Sourced
via MITRE·03:37 AM
RemedyDescriptionSeverityWeakness
Data Sourced
via NVD·04:17 AM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are exposed to this issue?

Only deployments with an HTTP/3 frontend are affected: HAProxy must be built with QUIC support, configured with a QUIC bind listener, and forwarding the relevant traffic to a backend over HTTP/1.1 with chunked transfer coding on a reused connection.

2

Does exploitation require authentication or user interaction?

No. A remote unauthenticated client can trigger the issue by sending an HTTP/3 request without Content-Length, declaring more DATA-frame payload than it delivers, and then ending the stream.

3

What is the practical impact of a successful exploit?

The backend connection can be returned to the idle pool in a desynchronized state, enabling potential request smuggling on reused backend connections. A smuggled request may bypass frontend HTTP analysis and rules such as path-based http-request deny rules, and may affect concurrent clients sharing the backend connection.

4

Are HTTP/3-capable HAProxy deployments always affected?

No. The vulnerable condition also requires the affected request to be sent onward to an HTTP/1.1 backend using chunked transfer coding on a reused connection. The issue does not apply when the required HTTP/3, QUIC, HTTP/1.1 backend, and connection-reuse conditions are not all present.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203