[OSSA-2026-039] OpenStack Octavia: HAProxy configuration injection leading to remote code execution in Octavia (CVE-2026-94572, CVE-2026-94571)

OpenStack Octavia before 18.0.1 fails to reject control characters (such as newlines) in the redirect_url and redirect_prefix fields of L7 policies. Because the RFC 3986 URL validator percent-encodes control characters before validating, values containing newlines pass structural checks, but Octavia writes the raw unencoded value directly into the HAProxy configuration generated on the amphora load balancer instance. An authenticated project member who owns a load balancer can exploit this via a REDIRECT_TO_URL L7 policy to inject arbitrary HAProxy directives on the amphora, potentially redirecting or intercepting tenant traffic, poisoning backend connections, or disrupting availability for any tenant whose traffic crosses that amphora. Only deployments using the Amphora provider driver are affected; other provider drivers are not. The flaw is rated critical (CVSS 4.0: 9.4) due to high impact on the amphora and subsequent systems it fronts, but there is no known public proof of concept and it is not listed in the CISA KEV catalog.

Do: Upgrade Octavia to 18.0.1 or later, which rejects control characters in L7 policy redirect_url and redirect_prefix fields. If immediate upgrade is not possible, audit existing L7 policies for embedded newlines or other control characters in those fields, consider stripping or denying such values at the Octavia API front end, and restrict load-balancer-creation rights to trusted tenants. After remediation, rebuild or reconfigure affected amphorae (failover or LB rebuild) so no injected HAProxy directives persist, and review amphora HAProxy configs and tenant traffic logs for signs of prior injection.

OpenStack Octavia before 18.0.1 fails to validate the tls_ciphers field on listeners and pools when using the Amphora provider driver, allowing a newline and other control characters to be written verbatim into the HAProxy configuration generated inside the amphora VM. An authenticated project member who owns a TLS-enabled load balancer can exploit this to inject arbitrary HAProxy configuration directives. Because HAProxy terminates and routes tenant traffic, successful injection can let the attacker intercept, redirect, or tamper with load-balanced traffic and potentially pivot within the provider network, which is reflected in the critical CVSS 4.0 score of 9.4. Only deployments using the Amphora provider are affected, with the practical risk concentrated in multi-tenant clouds that expose load-balancer APIs to untrusted tenant accounts. No public proof of concept is known and the flaw is not on the CISA KEV list, so there is no indication of in-the-wild exploitation at this time.

Do: Upgrade Octavia to 18.0.1 or later, and check your Linux distributor or vendor for backported fixes if you run a supported stable branch. Until patched, tighten Octavia RBAC/policy so only trusted roles can create or update listeners and pools, and audit existing tls_ciphers values plus the generated haproxy.cfg on amphorae for embedded newlines or unexpected directives. Review load-balancer audit logs for tenants setting odd cipher strings on TLS-enabled listeners or pools.