DEV Community

StarkMan
StarkMan

Posted on

One TLS setting turned off Basic auth for every HAProxy Data Plane API listener

#authentication #loadbalancer #managementapi

One TLS setting turned off Basic auth for every HAProxy Data Plane API listener

Configuration management APIs are usually the most privileged HTTP endpoints an organisation runs. The HAProxy Data Plane API edits the load balancer's configuration, which means it can redirect traffic, disable access controls, and rewrite the front door of a production estate. CVE-2026-109575 describes a case where enabling one legitimate TLS option silently removed authentication from the rest of the process.

The affected surface

The CVE record covers HAProxy Data Plane API community versions 2.2.0 through 3.4.3 and the corresponding Enterprise Edition releases. The fix is in v3.4.4, published in the haproxytech/dataplaneapi repository.
The severity is 9.8 under CVSS 3.1, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, with no privileges required and no user interaction. An unauthenticated attacker who can reach an affected management endpoint obtains full API administrative access.

The mechanism

Server.ConfigureAPI() builds the HTTP serving stack for the API. Its authentication logic is process-global. When a TLS Certificate Authority is configured through tls_ca and a numeric TLS port is supplied through tls_port, the code disables Basic authentication on the shared internal request handler.
The shared handler is the crux. The same handler serves the HTTP listener, the HTTPS listener and the UNIX domain socket listener concurrently. Client certificate verification, tls.RequireAndVerifyClientCert, is enforced only on the HTTPS server path. The other listeners keep running, still pointed at the same handler, but now without Basic authentication in front of them.
The result is a fail-open condition across transport types. An attacker does not need the certificate, the password or any credential at all. Reaching the plain HTTP endpoint, or the UNIX socket where local access exists, is sufficient.

Why this class of bug recurs

A configuration option that improves security in one path can weaken a neighbouring path when the code that enforces it makes a global decision. The pattern appears whenever a service supports several transports and centralises request handling to avoid duplicating logic. Centralising is usually the right engineering call. The failure mode is when a branch that reads "TLS CA is configured" is written as "authentication is handled elsewhere", without narrowing the scope of that assumption to the listener that actually performs certificate verification.
For defenders, the takeaway is not that HAProxy is uniquely fragile. It is that the security posture of a management API can differ between its listeners, and the difference is invisible unless someone explicitly tests each one.

The operational reading

Three details decide how much this matters for a given deployment.
The first is whether the API is reachable at all. Data Plane API instances are frequently bound to localhost and driven by a controller, a CI pipeline or a wrapper script over the UNIX socket. In that shape, the vulnerable condition still exists, but the population able to reach it is limited to local users and to whatever can reach the socket.
The second is whether tls_ca and a numeric tls_port are both set. That combination is the trigger. Teams that terminated TLS in front of the API, with no CA configured for client certificates, are not in the described configuration.
The third is what an attacker gains. Full API administrative access means the ability to read the running configuration and to write a new one. A reload follows, and the effect is immediately visible in traffic. That distinguishes this from vulnerabilities whose impact appears days later in an analysis dashboard.

What to check first

  • Confirm the deployed version of the Data Plane API binary, including the copy inside containers and the controller's bundled build. The vulnerable range ends at 3.4.3; the fixed release is 3.4.4.
  • List every listener the API opens. Check the HTTP port, the HTTPS port and any UNIX socket. If a listener exists that you did not intend to expose, that is the finding regardless of version.
  • Inspect the configuration for the combination of tls_ca and a numeric tls_port. Where that pair is present, test each listener independently with the credentials removed. A request that succeeds without a password on a non-mTLS path is the confirmed condition.
  • Bind the API to a management interface or localhost. Network placement is not a substitute for the patch, but it reduces who can reach the fail-open path during the upgrade window.
  • Review the audit log for configuration changes and reloads made by the API. The endpoint's own record of who changed what is the best available evidence of prior access, because an unauthenticated request does not produce a login event to find.

Verification after upgrading

Version numbers alone are weak evidence for this bug, because the condition depends on configuration. After moving to 3.4.4, re-test the same three paths: plain HTTP, HTTPS with a client certificate, and the UNIX socket. Each should reject an unauthenticated request. If a legacy listener is still serving, remove it rather than relying on the new authentication check.
The patch also deserves a second question: what did the deployment do while the condition was live? An exposed management API that accepted unauthenticated writes can be a persistence mechanism. Comparing the current HAProxy configuration against the version controlled copy, and looking for frontends or rules nobody wrote, is a more useful exercise than searching for failed logins that never happened.

Narrow lesson, wide application

Authentication decisions that live at process scope, applied to a handler shared by several listeners, make the weakest transport the effective security level for all of them. That is true for load balancer control planes and equally true for the admin servers inside everything else on the network.

References

Top comments (0)