CVE-2026-94572: OpenStack Octavia HAProxy RCE Vulnerability

CVE-2026-94572 Overview

CVE-2026-94572 is a code injection vulnerability in OpenStack Octavia versions prior to 18.0.1. The flaw resides in the Amphora provider driver, which fails to validate the tls_ciphers field of listener and pool objects for control characters. Because the supplied value is written verbatim into the generated HAProxy configuration on the amphora, an authenticated project member who owns a TLS-enabled load balancer can inject a newline followed by arbitrary HAProxy directives. Only deployments using the Amphora provider are affected. The issue is tracked as CWE-94: Improper Control of Generation of Code and documented in OpenStack Security Advisory OSSA-2026-039.

Critical Impact

An authenticated tenant can inject arbitrary HAProxy configuration directives into the amphora, altering load balancer behavior and potentially compromising confidentiality and integrity of traffic handled by the load balancer.

Affected Products

• OpenStack Octavia versions prior to 18.0.1
• Deployments using the Amphora provider driver
• TLS-enabled load balancers managed by Octavia

Discovery Timeline

• 2026-09-21 - CVE-2026-94572 published to NVD
• 2026-09-21 - Openwall OSS-Security disclosure posted
• 2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-94572

Vulnerability Analysis

Octavia's Amphora provider generates HAProxy configuration files on the amphora virtual machine based on API-supplied load balancer objects. The tls_ciphers field on listener and pool resources accepts a string that Octavia forwards to HAProxy's ssl-default-*-ciphers directives. The driver does not reject or sanitize control characters in this string. Because HAProxy configuration is line-oriented, a newline character terminates the current directive and starts a new one that HAProxy will parse and honor. The vulnerability requires only project-member privileges within a tenant that owns a TLS-enabled load balancer, so any authenticated cloud user with load balancer creation rights in an affected deployment can trigger it.

Root Cause

The root cause is missing input validation on the tls_ciphers attribute. The Amphora driver treats the value as opaque text and interpolates it directly into a Jinja-rendered HAProxy configuration template. No character allowlist or newline stripping is applied prior to serialization. The upstream fix in commit cad62902e4 adds explicit rejection of control characters in the field.

Attack Vector

The attacker authenticates to the OpenStack API with standard project-member credentials. They create or update a listener or pool on a TLS-enabled load balancer and set tls_ciphers to a value containing a newline followed by attacker-chosen HAProxy configuration. When Octavia pushes the rendered configuration to the amphora and reloads HAProxy, the injected directives take effect. Injected directives can redirect traffic, disable TLS verification, add backends, expose statistics interfaces, or otherwise change how the load balancer processes tenant and neighbor traffic. Consult the Launchpad bug #2162101 and Launchpad bug #2167565 reports for further technical context.

Detection Methods for CVE-2026-94572

Indicators of Compromise

• Listener or pool objects with tls_ciphers values containing newline (\n, \r), null bytes, or other ASCII control characters.
• HAProxy configuration files on amphorae containing directives that were not emitted by Octavia's template (unexpected frontend, backend, stats, or http-request stanzas).
• Unexplained HAProxy reload events on amphorae correlated with recent listener or pool update API calls.
• Octavia API audit records showing PUT/POST on /v2/lbaas/listeners or /v2/lbaas/pools with unusually long tls_ciphers payloads.

Detection Strategies

• Query the Octavia database for any listener or pool row whose tls_ciphers column contains characters outside the expected cipher-string grammar (alphanumerics, :, -, _, +, !, @).
• Diff live HAProxy configuration on amphorae against the canonical Jinja template output for the same load balancer definition.
• Ingest Octavia API and amphora agent logs into a SIEM and alert on tls_ciphers payloads exceeding a reasonable length or containing hex-escaped control bytes.

Monitoring Recommendations

• Enable and centralize Keystone-authenticated Octavia API audit logging for all listener and pool mutations.
• Monitor amphora HAProxy process for unexpected listeners on non-standard ports after configuration reloads.
• Track load balancer configuration change frequency per project and alert on anomalous spikes that could indicate exploitation attempts.

How to Mitigate CVE-2026-94572

Immediate Actions Required

• Upgrade OpenStack Octavia to version 18.0.1 or later on all control-plane nodes running the Octavia API, worker, and housekeeping services.
• Audit all existing listener and pool tls_ciphers values and remove or reset any entry containing control characters.
• Rotate or rebuild amphorae that were configured with suspicious tls_ciphers values to ensure no injected directives persist.
• Restrict load balancer creation and modification rights via Keystone policy to trusted project roles where feasible.

Patch Information

The fix is delivered in Octavia 18.0.1 and merged upstream in commit cad62902e4984a46ad80cbfa943e90006d8d599d. The patch validates the tls_ciphers field and rejects any value containing control characters before it can be written to an HAProxy configuration. Distribution-specific packaging updates are tracked in Debian bug #1148175. Refer to OSSA-2026-039 for the full backport matrix.

Workarounds

• Apply an API policy or admission proxy in front of Octavia that rejects tls_ciphers values containing characters outside the OpenSSL cipher-string grammar.
• Temporarily disable creation of TLS-enabled load balancers for untrusted projects until the patched version is deployed.
• Switch affected tenants to a non-Amphora provider driver if operationally viable, since only the Amphora provider is affected.

# Example: verify installed Octavia version and search for suspicious tls_ciphers values
pip show octavia | grep -i version

mysql -e "SELECT id, tls_ciphers FROM octavia.listener \
  WHERE tls_ciphers REGEXP '[[:cntrl:]]';"
mysql -e "SELECT id, tls_ciphers FROM octavia.pool \
  WHERE tls_ciphers REGEXP '[[:cntrl:]]';"