External risk intelligence

OpenStack Octavia Amphora Driver Configuration Injection Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.4)

CVE-2026-94572

This vulnerability requires authenticated access to an OpenStack project to manipulate load balancer configuration settings. While the infrastructure is network-accessible, the requirement for existing project-level authentication makes direct public internet exploitation of this configuration injection uncommon.

Code Injection

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory concerns a critical vulnerability in OpenStack Octavia's Amphora provider driver, which fails to properly validate specific configuration fields for TLS-enabled load balancers. An authenticated user with project access could potentially inject arbitrary commands into the HAProxy configuration, impacting the security and operation of affected deployments. The main concern at this time is confirming if this specific technology is in use and exposed.

Configuration flaw in load balancer driver.
Matters if using OpenStack Octavia Amphora.
Confirm relevance and exposure to Octavia.

Attack Path

How an attacker could exploit the issue

An attacker with authenticated access to an OpenStack project could manipulate the TLS cipher settings of a load balancer. This involves crafting a malicious input for the `tls_ciphers` field, which is then written directly into the HAProxy configuration. The vulnerability allows for the injection of arbitrary HAProxy directives, potentially leading to significant compromise. This specific vulnerability affects deployments utilizing the Amphora provider.

Authenticated project member is required.
Malicious input in listener/pool TLS ciphers.
Arbitrary HAProxy configuration injection.

Live Threat

Current exploitation, exposure, and threat context

In deployments using the OpenStack Octavia Amphora provider, an authenticated project member could inject arbitrary HAProxy configuration directives by embedding control characters into listener or pool TLS cipher fields. This could occur when the system generates HAProxy configurations for TLS-enabled load balancers.

Arbitrary HAProxy configuration.
Control characters in TLS cipher fields.
Unrestricted service configuration changes.

Operational Fix

Recommended remediation, mitigation, and detection steps

Deployments using the OpenStack Octavia Amphora provider driver are affected by this vulnerability. Owners of TLS-enabled load balancers within a project are responsible for assessing their exposure. The initial step involves identifying all instances of the Amphora provider, determining their network reachability and business criticality, and then confirming the accountable project member to plan remediation.

Identify Amphora provider instances.
Verify TLS-enabled load balancer reachability.
Plan remediation with accountable owners.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is OpenStack Octavia and the Amphora driver?

OpenStack Octavia is an open-source Load Balancing as a Service component designed for cloud environments. It distributes incoming network traffic across multiple server instances to ensure reliability and performance. The Amphora provider is a specific driver within Octavia that manages these load balancers by deploying and configuring virtual machine instances—called amphorae—to run the HAProxy software responsible for handling and routing that traffic.

What does CVE-2026-94572 mean by configuration injection?

This vulnerability, classified as Improper Control of Generation of Code (CWE-94), occurs because the software fails to sanitize input. When a user defines TLS cipher suites for their load balancer, the driver does not check for hidden control characters like newlines. An attacker can insert these characters to trick the system into writing unauthorized commands directly into the underlying HAProxy configuration file, effectively altering how the load balancer operates.

How does an attacker trigger this vulnerability?

The trigger requires the attacker to be an authenticated project member who has permission to create or update TLS-enabled load balancers. By crafting a specific input for the TLS cipher field containing a newline character, they can bypass intended constraints. Simply accessing the OpenStack dashboard or API without project-level credentials will not trigger this bug, as it requires the ability to submit configuration changes to an existing load balancer pool or listener.

Is my environment at high risk from this CVE?

According to Halo Surface Signal, direct public exploitation is considered unlikely because the flaw requires authenticated access to an OpenStack project. While the underlying load balancer infrastructure is often network-accessible, an attacker must already be an authorized member of your project to initiate the configuration injection. Organizations should prioritize internal review of access controls and project permissions to limit who can modify load balancer settings.

What steps should I take if I use OpenStack Octavia?

Your first step is to confirm if your deployment uses the Amphora provider driver, as other drivers are not affected. Audit your current load balancer configurations to identify any that use TLS settings and verify which project members have the rights to modify these objects. Coordinate with those project owners to assess current configurations while awaiting official patches from your OpenStack distribution provider to remediate the underlying input validation flaw.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.