In HAProxy Data Plane API 2.2.0 through 3.4.3 (and corresponding Enterprise Edition releases), Server.ConfigureAPI() has process-global authentication logic that improperly drops security controls across multiple transport types. When a TLS Certificate Authority (tls_ca) is configured and a numeric TLS port (tls_port) is specified, the application globally disables Basic authentication on its shared internal request handler. Because this handler is shared concurrently among HTTP, HTTPS, and UNIX domain socket listeners, and mutual TLS (mTLS) client certificate verification (tls.RequireAndVerifyClientCert) is enforced exclusively on the HTTPS server path, all other simultaneously active non-mTLS listeners fail open. Consequently, an unauthenticated attacker capable of reaching an affected HTTP or UNIX management endpoint can completely bypass credentials to gain full API administrative access. This allows unauthorized remote or local actors to read sensitive, cleartext HAProxy configuration data or replace the managed configuration entirely via the raw configuration endpoint. This has been fixed in versions 3.4.4, 3.3.9, 3.2.17, 3.0.25, 2.9.29, and their respective EE backports by migrating to a per-request TLS connection-state validation model.
Fix
Nothing published yet: no patch, vendor advisory or mitigation reference on NVD, no vendor advisory in the News for this CVE, not in CISA's KEV, no fixed package version. BaselineWatch does not guess at one.
Change history 2
- StatusReceived → Awaiting AnalysisNVD modified 2026-10-16 19:55
- First seenCVSS 9.8NVD modified 2026-10-13 17:17
Affected (CPE criteria) 0
NVD has not attached CPE configurations yet.
References 4
- https://github.com/haproxytech/dataplaneapi/commit/c3ae4e3ccff5490d44650565e445c4b15e8aff8c
- https://github.com/haproxytech/dataplaneapi/releases/tag/v3.4.4
- https://www.haproxy.com/documentation/haproxy-data-plane-api/
- https://www.haproxy.com/documentation/haproxy-data-plane-api/community/changelog/#version-3.4