CVE-2026-94572 in Octavia
Summary
by MITRE • 09/21/2026
In OpenStack Octavia before 18.0.1, the Amphora provider driver did not validate the listener and pool tls_ciphers field for control characters. The value is written verbatim into the HAProxy configuration generated on the amphora, and thus an authenticated project member who owns a TLS-enabled load balancer can embed a newline and inject arbitrary HAProxy configuration directives. Only deployments using the Amphora provider are affected.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified in OpenStack Octavia prior to version 18.0.1 represents a critical input validation failure within the Amphora provider driver, specifically concerning the handling of TLS cipher suite configurations for load balancers. In this architecture, the Amphora acts as an instance-based proxy that generates HAProxy configuration files dynamically based on user-defined parameters provided through the OpenStack API. The specific flaw lies in the insufficient sanitization of the tls_ciphers field associated with listeners and pools. When a project member submits a request to configure or update these TLS settings, the system fails to validate the input string for control characters such as newlines before passing it downstream. This lack of rigorous validation allows an authenticated user who owns a TLS-enabled load balancer to inject arbitrary content into the configuration file that is subsequently written verbatim onto the Amphora instance.
From a technical perspective, this vulnerability enables Configuration Injection via Newline Character exploitation. By embedding newline characters within the tls_ciphers parameter, an attacker can break out of the intended single-line directive and introduce additional HAProxy configuration directives on subsequent lines. This capability effectively allows the injection of arbitrary commands or settings into the HAProxy process running on the Amphora instance. Since HAProxy is responsible for terminating TLS connections and routing traffic to backend servers, manipulating its configuration file grants the attacker significant control over how requests are processed. The impact extends beyond simple misconfiguration; it can lead to unauthorized access bypasses, interception of sensitive data through modified SSL/TLS parameters, or potentially remote code execution if specific HAProxy features that allow command injection via configuration directives are exploited in conjunction with this flaw.
The operational impact is severe for organizations relying on the Amphora provider driver within their OpenStack deployments. An authenticated project member can leverage this vulnerability to compromise the integrity and confidentiality of traffic passing through the load balancer. For instance, an attacker could force the use of weak or deprecated cipher suites, facilitating man-in-the-middle attacks against clients connecting to the service. Alternatively, they might inject directives that redirect traffic to malicious backend servers, leading to data exfiltration or phishing scenarios. Because the configuration is generated and applied dynamically during runtime updates, the attack does not require persistent access to the underlying infrastructure beyond having valid credentials for a project with load balancer management privileges. This highlights a significant risk in multi-tenant cloud environments where isolation between projects relies heavily on correct API-level input validation.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code, often referred to as code injection, specifically manifesting here through configuration file manipulation rather than direct executable code execution. It also maps to MITRE ATT&CK techniques related to Configuration Modification and potentially Command and Control if the injected directives are used to establish covert channels or exfiltrate data via HTTP headers manipulated by HAProxy settings. The root cause is a classic failure in input validation where special characters that hold syntactic meaning in the target configuration language, such as newlines for line breaks in HAProxy config files, are not escaped or rejected.
Mitigation strategies must prioritize immediate patching to version 18.0.1 or later of OpenStack Octavia, which addresses this issue by implementing strict validation rules that reject inputs containing control characters within the tls_ciphers field. In environments where upgrading is not immediately feasible, administrators should implement network-level access controls to restrict API access to trusted IP ranges and enforce least-privilege principles for project members who have permissions to modify load balancer configurations. Additionally, deploying Web Application Firewalls or custom OpenStack middleware that inspects outgoing configuration payloads can provide a layer of defense against injection attempts. Regular auditing of HAProxy configuration files generated by Octavia can also help detect any unauthorized modifications resulting from successful exploitation of this vulnerability.