OpenStack Ironic through 39.0.1 allows a denial of service via a configdrive that results in a very large amount of uncompressed data, aka a gzip bomb.

OpenStack Ironic before 39.0.1 sometimes allows a user to change the maintenance setting on a node via PATCH to /v1/nodes/{ident} - in other words, not using the specific maintenance endpoint.

OpenStack Ironic before 39.0.1 allows DELETE and GET via vendorpassthru, e.g., to delete accounts from the BMC's Redfish service.

======================================================================== OSSA-2026-048: Ironic allows generic node update for maintenance setting ========================================================================

:Date: October 22, 2026 :CVE: CVE-2026-89419

Affects ~~~~~~~ Description ~~~~~~~~~~~ The Metal3.io Security team reported a vulnerability in Ironic's API. When calling the Node maintenance API at /v1/nodes/{ident}/maintenance, Ironic properly applies the baremetal:node:setmaintenance and baremetal:node:clearmaintenance policies.

However, if a user instead calls the more generic Node update API by sending an HTTP PATCH to /v1/nodes/{ident}, and includes maintenance or maintenancereason in the dictionary, they can instead trigger the baremetal:node:update policy. This may lead to users unexpectedly having access to change the maintenance setting on a node.

For clouds using default Ironic policy, this means someone with the member role on the project indicated in node.lessee can change maintenance on the node. This is typically restricted only to accounts with manager or admin roles on lessee accounts. There is no change in effective default permissions in the case of node.owner project members or system-scoped users.

Patches ~~~~~~~ - https://review.opendev.org/1011871 (2024.1/caracal (unmaintained)) - https://review.opendev.org/1011869 (2025.1/epoxy) - https://review.opendev.org/1011867 (2025.2/flamingo) - https://review.opendev.org/1011865 (2026.1/gazpacho) - https://review.opendev.org/1011863 (2026.2/hibiscus) - https://review.opendev.org/1011861 (2027.1/indri (development)) - https://review.opendev.org/1011875 (Bugfix/37.0) - https://review.opendev.org/1011873 (Bugfix/38.0)

Credits ~~~~~~~ - Dmitry Tantsur, Metal3.io Security Team from Red Hat (CVE-2026-89419)

References ~~~~~~~~~~ - https://launchpad.net/bugs/2166510 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-89419

Notes ~~~~~ - Patches for unmaintained/2024.1, bugfix/38.0, and bugfix/37.0 will be   merged to git but no new release will be provided.

========================================================================== OSSA-2026-047: Redfish vendorpassthru method allows path injection via ID ==========================================================================

:Date: October 22, 2026 :CVE: CVE-2026-90458

Affects ~~~~~~~ Description ~~~~~~~~~~~ The Metal3.io Security team reported a vulnerability in Ironic's API. When calling the vendorpassthru API endpoint provided by the redfish management interface to create or delete a subscription, a malicious System-scoped Administrator could instead perform an HTTP DELETE or HTTP GET on an arbitrary path on a node's BMC. In a worst case scenario, this could lead to user accounts being deleted from the Redfish service on the BMC.

Only clouds with nodes enrolled in a redfish hardware type are susceptible to this vulnerability.

Patches ~~~~~~~ - https://review.opendev.org/1011870 (2024.1/caracal (unmaintained)) - https://review.opendev.org/1011868 (2025.1/epoxy) - https://review.opendev.org/1011866 (2025.2/flamingo) - https://review.opendev.org/1011864 (2026.1/gazpacho) - https://review.opendev.org/1011862 (2026.2/hibiscus) - https://review.opendev.org/1011860 (2027.1/indri (development)) - https://review.opendev.org/1011874 (Bugfix/37.0) - https://review.opendev.org/1011872 (Bugfix/38.0)

Credits ~~~~~~~ - Dmitry Tantsur, Metal3.io Security Team from Red Hat (CVE-2026-90458)

References ~~~~~~~~~~ - https://launchpad.net/bugs/2166507 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-90458

Notes ~~~~~ - Patches for unmaintained/2024.1, bugfix/38.0 and bugfix/37.0 will be   merged to git but no new release will be provided.

In OpenStack Cinder through 29.0.0, cross-project information disclosure can occur in the Messages API. A non-admin user with the project-scoped 'member' or 'reader' role making the Block Storage API v3.3 "List messages" call finds the non-expired user messages for other projects included in the response, resulting in the leakage of UUIDs of resources owned by other projects, in addition to the user message about the other projects' resources (which, by design, are sanitized generic messages). All Cinder deployments are affected.

In OpenStack Manila before 23.0.1, multiple Manila API operations on public shares do not verify that the caller owns the share. The API controllers authorize operations against the caller's own project context, then load a foreign public share without re-authorizing against the share's actual owner. This affects the following operations: allowaccess: grant data-plane read/write access to another tenant's share; denyaccess: revoke the owner's existing access rules; updateaccess: escalate access level (e.g., ro to rw); createsharebackup: exfiltrate share data via a backup created under the attacker's project; softdelete: move a foreign share to the recycle bin; restore: interfere with the owner's deletion workflow; export location metadata: create, update, and delete metadata on foreign export locations; access rule listing: disclose IPs, usernames, and CephFS keys. Any authenticated project member can exploit these operations on any public share. The share UUID is visible since the share is public.

============================================================= ============================================================= Summary ~~~~~~~ Dmitry Tantsur (Red Hat) and Tuomo Tanskanen (Ericsson Software Technology) from the Metal3.io security team reported a vulnerability in Ironic. When a deployment can set instanceinfo/imagesource or Affected Services / Software ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Discussion ~~~~~~~~~~ The fix adds a [deploy]/imageserverauthhosts option allowing operators to restrict the hosts to which credentials are sent, along with a [deploy]/imageserverauthpermitunknownhosts option.

Deployments of OpenStack-integrated Ironic typically use Glance for image management and are not impacted by this vulnerability.

Recommended Actions ~~~~~~~~~~~~~~~~~~~ Operators utilizing the basic auth feature for image retrieval should:

Apply the relevant patch for their release set [deploy]/imageserverauthhosts to a list of acceptable   hosts to pass authentication credentials to set [deploy]/imageserverauthpermitunknownhosts to False

Ironic intends to change the default of [deploy]/imageserverauthpermitunknownhosts to False in the 2027.1 release. See https://review.opendev.org/999907 for more information.

Patches 2026.2/hibiscus: https://review.opendev.org/999744 2026.1/gazpacho: https://review.opendev.org/1003587 2025.2/flamingo: https://review.opendev.org/1003597 2025.1/epoxy: https://review.opendev.org/1003598 bugfix/38.0: https://review.opendev.org/1003577 bugfix/37.0: https://review.opendev.org/1003579

Credits:

Tuomo Tanskanen, Metal3.io Security Team (Ericsson Software Technology) Dmitry Tantsur, Metal3.io Security Team (Red Hat)

Contacts / References ~~~~~~~~~~~~~~~~~~~~~ Author: Jay Faulkner (G-Research OSS)

Original bug : https://launchpad.net/bugs/2162816 This OSSN : https://docs.openstack.org/security-notes/OSSN-0110.html Mailing List : openstack-discuss () lists openstack org OpenStack Security : https://security.openstack.org/ CVE-2026-90461 : https://nvd.nist.gov/vuln/detail/CVE-2026-90461

In OpenStack Mistral through 23.0.0, several of the v2 API write paths resolve the target object with a query that can return another project's resource, then write to it. An authenticated project member can use this to rewrite and un-publish another project's public action definitions and environments. A project administrator can create a workbook whose embedded ad-hoc action or workflow name collides with a resource of another project, which moves that resource into the caller's project and causes the original owner's subsequent updates of it to fail with server errors. Only deployments exposing the Mistral API are affected.

In OpenStack Mistral through 23.0.0, the workflow membership API lets a project that has accepted a share of another project's private workflow create a further membership naming a third project. The new membership row is created with its projectid defaulted to the accepting project rather than the original workflow owner, and thus the owner can neither see nor delete it. The third project can accept this membership (that it had not actually been granted by the owner), and then read and execute the owner's private workflow; only the accepting (not the owning) project can later revoke that access.

In OpenStack Mistral through 23.0.0, the /v2/maintenance API controller clears the request context and calls the maintenance service directly without any policy enforcement. Any holder of a valid Mistral token, regardless of assigned role, can read and change the service's cluster-wide maintenance state. Setting the state to PAUSED stops processing of new workflow and execution objects across all tenant projects until an operator restores it.

In OpenStack Mistral through 23.0.0, the std.sshproxied action passes a caller-supplied proxycommand value directly to paramiko.ProxyCommand() before any SSH connection to a gateway or target host is attempted. An authenticated project member can use the standard action-execution API to submit an arbitrary local command as proxycommand; paramiko starts that command as a subprocess on the executor host under the executor's own service account, independent of whether the SSH connection itself ever succeeds. Only Mistral deployments that permit the std.sshproxied action, the default configuration, are affected.

========================================================================== OSSA-2026-044: Four authorization and privilege vulnerabilities in Mistral ==========================================================================

:Date: October 08, 2026 :CVE: CVE-2026-93858, CVE-2026-93860, CVE-2026-93861, CVE-2026-97147

Affects ~~~~~~~ - Mistral: <20.1.1, ==21.0.0, ==22.0.0, ==23.0.0

Description ~~~~~~~~~~~

Patches ~~~~~~~ - https://review.opendev.org/1009502 (2025.1/epoxy) - https://review.opendev.org/1009503 (2025.1/epoxy) - https://review.opendev.org/1009504 (2025.1/epoxy) - https://review.opendev.org/1009505 (2025.1/epoxy) - https://review.opendev.org/1009506 (2025.1/epoxy) - https://review.opendev.org/1009507 (2025.1/epoxy) - https://review.opendev.org/1009508 (2025.1/epoxy) - https://review.opendev.org/1009509 (2025.1/epoxy) - https://review.opendev.org/1009493 (2025.2/flamingo) - https://review.opendev.org/1009494 (2025.2/flamingo) - https://review.opendev.org/1009495 (2025.2/flamingo) - https://review.opendev.org/1009496 (2025.2/flamingo) - https://review.opendev.org/1009497 (2025.2/flamingo) - https://review.opendev.org/1009498 (2025.2/flamingo) - https://review.opendev.org/1009499 (2025.2/flamingo) - https://review.opendev.org/1009500 (2025.2/flamingo) - https://review.opendev.org/1009484 (2026.1/gazpacho) - https://review.opendev.org/1009485 (2026.1/gazpacho) - https://review.opendev.org/1009486 (2026.1/gazpacho) - https://review.opendev.org/1009487 (2026.1/gazpacho) - https://review.opendev.org/1009488 (2026.1/gazpacho) - https://review.opendev.org/1009489 (2026.1/gazpacho) - https://review.opendev.org/1009490 (2026.1/gazpacho) - https://review.opendev.org/1009491 (2026.1/gazpacho) - https://review.opendev.org/1009476 (2026.2/hibiscus) - https://review.opendev.org/1009477 (2026.2/hibiscus) - https://review.opendev.org/1009478 (2026.2/hibiscus) - https://review.opendev.org/1009479 (2026.2/hibiscus) - https://review.opendev.org/1009480 (2026.2/hibiscus) - https://review.opendev.org/1009481 (2026.2/hibiscus) - https://review.opendev.org/1009482 (2026.2/hibiscus) - https://review.opendev.org/1009483 (2026.2/hibiscus) - https://review.opendev.org/1009468 (2027.1/indri (development)) - https://review.opendev.org/1009469 (2027.1/indri (development)) - https://review.opendev.org/1009470 (2027.1/indri (development)) - https://review.opendev.org/1009471 (2027.1/indri (development)) - https://review.opendev.org/1009472 (2027.1/indri (development)) - https://review.opendev.org/1009473 (2027.1/indri (development)) - https://review.opendev.org/1009474 (2027.1/indri (development)) - https://review.opendev.org/1009475 (2027.1/indri (development))

Credits ~~~~~~~ - Arnaud Morin from OVHcloud (CVE-2026-97147) References ~~~~~~~~~~ - https://launchpad.net/bugs/2160267 (CVE-2026-97147) - https://launchpad.net/bugs/2161277 (CVE-2026-93861) - https://launchpad.net/bugs/2162100 (CVE-2026-93858) - https://launchpad.net/bugs/2162789 (CVE-2026-93860) - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-93858 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-93860 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-93861 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-97147

-- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

========================================================================== OSSN-0109: Cross-project metric association bypass in Gnocchi (2026-10-07) ==========================================================================

Summary ~~~~~~~ The Gnocchi metric creation endpoint allows authenticated users to associate metrics with resources owned by others by passing resourceid in the request body bypassing proper authorization checks.

This improper access control enables attackers to inject arbitrary measures Aodh alarms and Heat scaling policies across project boundaries.

Affected Services / Software ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Gnocchi (<4.6.6, ==4.7.0)

Discussion ~~~~~~~~~~ The Gnocchi API did not apply any policy when passing resourceid in the request body when creating metrics using POST /v1/metric. the resource UUID was known or could be enumerated. and thus Heat scaling policies that could trigger stack changes that causes changes in OpenStack resources on the project. This vulnerability was originally disclosed by gnocchi's upstream at https://github.com/gnocchixyz/gnocchi.

Recommended Actions ~~~~~~~~~~~~~~~~~~~ the Gnocchi API service.

Patches: Credits: swdb

Contacts / References ~~~~~~~~~~~~~~~~~~~~~ Author: Tobias Urdin (Binero)

This OSSN : https://docs.openstack.org/security-notes/OSSN-0109.html

===================================================================================== =====================================================================================

:Date: October 07, 2026 :CVE: CVE-2026-107363

Affects ~~~~~~~ - Zaqar: >=1.0.0 <20.1.3, >=21.0.0 <21.0.3, >=22.0.0 <22.0.3, ==23.0.0

Description ~~~~~~~~~~~ Chen YuXiang from the Institute of Computing Technology, Chinese Academy of Sciences reported a vulnerability in Zaqar's WebSocket transport. An authenticated remote attacker who knows a target project's UUID may substitute it in subsequent WebSocket frames to enumerate, inspect, create, or delete queues belonging to that project. This may result in unauthorized disclosure, modification, or loss of queue data. Only deployments using the WebSocket transport with Keystone authentication are affected.

Errata ~~~~~~ CVE-2026-107363 has been assigned for this vulnerability.

Patches ~~~~~~~ - https://review.opendev.org/1009254 (2025.1/epoxy) - https://review.opendev.org/1009253 (2025.2/flamingo) - https://review.opendev.org/1009252 (2026.1/gazpacho) - https://review.opendev.org/1009251 (2026.2/hibiscus) - https://review.opendev.org/1009250 (2027.1/indri (development))

Credits ~~~~~~~ References ~~~~~~~~~~ - https://launchpad.net/bugs/2161402 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-107363

OSSA History ~~~~~~~~~~~~ - 2026-10-07 - Errata 1 - 2026-10-07 - Original Version

-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

On 10/7/26 10:59 AM, Goutham Pacha Ravi wrote: ===================================================================================== =====================================================================================

:Date: October 07, 2026 :CVE: CVE-2026-pending

Affects ~~~~~~~ - Zaqar: >=1.0.0 <20.1.3, >=21.0.0 <21.0.3, >=22.0.0 <22.0.3, ==23.0.0

Description ~~~~~~~~~~~ Chen YuXiang from the Institute of Computing Technology, Chinese Academy of Sciences reported a vulnerability in Zaqar's WebSocket transport. An authenticated remote attacker who knows a target project's UUID may substitute it in subsequent WebSocket frames to enumerate, inspect, create, or delete queues belonging to that project. This may result in unauthorized disclosure, modification, or loss of queue data. Only deployments using the WebSocket transport with Keystone authentication are affected.

Patches ~~~~~~~ - https://review.opendev.org/1009254 (2025.1/epoxy) - https://review.opendev.org/1009253 (2025.2/flamingo) - https://review.opendev.org/1009252 (2026.1/gazpacho) - https://review.opendev.org/1009251 (2026.2/hibiscus) - https://review.opendev.org/1009250 (2027.1/indri (development))

Credits ~~~~~~~ References ~~~~~~~~~~ - https://launchpad.net/bugs/2161402 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending

Notes ~~~~~ - A CVE identifier was requested from MITRE for this vulnerability on   2026-10-06. The CVE will be added to this advisory by errata once   assigned.

-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

In OpenStack Zaqar before 23.0.1, the WebSocket transport fails to bind the project identifier in subsequent requests to the project authenticated by the Keystone token. An authenticated user with a valid token for one project may substitute another project's UUID to enumerate, inspect, create, or delete queues belonging to that project, resulting in unauthorized disclosure, modification, or loss of queue data. Only deployments using the WebSocket transport with Keystone authentication are affected.

===================================================================================== =====================================================================================

:Date: October 07, 2026 :CVE: CVE-2026-pending

Affects ~~~~~~~ - Zaqar: >=1.0.0 <20.1.3, >=21.0.0 <21.0.3, >=22.0.0 <22.0.3, ==23.0.0

Description ~~~~~~~~~~~ Chen YuXiang from the Institute of Computing Technology, Chinese Academy of Sciences reported a vulnerability in Zaqar's WebSocket transport. An authenticated remote attacker who knows a target project's UUID may substitute it in subsequent WebSocket frames to enumerate, inspect, create, or delete queues belonging to that project. This may result in unauthorized disclosure, modification, or loss of queue data. Only deployments using the WebSocket transport with Keystone authentication are affected.

Patches ~~~~~~~ - https://review.opendev.org/1009254 (2025.1/epoxy) - https://review.opendev.org/1009253 (2025.2/flamingo) - https://review.opendev.org/1009252 (2026.1/gazpacho) - https://review.opendev.org/1009251 (2026.2/hibiscus) - https://review.opendev.org/1009250 (2027.1/indri (development))

Credits ~~~~~~~ References ~~~~~~~~~~ - https://launchpad.net/bugs/2161402 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending

Notes ~~~~~ - A CVE identifier was requested from MITRE for this vulnerability on 2026-10-06. The CVE will be added to this advisory by errata once assigned.

-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

A Server-Side Request Forgery (SSRF) vulnerability exists in the Image API (v2) of OpenStack Glance. When the showmultiplelocations configuration option is enabled in glance-api.conf, an authenticated attacker can manipulate the locations attribute of an image in the queued state by sending a crafted HTTP PATCH request

======================================================================= OSSA-2026-042: Zaqar empty URL-Signature header bypasses authentication =======================================================================

:Date: September 24, 2026 :CVE: CVE-2026-97404

Affects ~~~~~~~ - Zaqar: >=1.0.0 <20.1.2, >=21.0.0 <21.0.2, >=22.0.0 <22.0.2

Description ~~~~~~~~~~~ pple, an independent security researcher, reported that Zaqar's WSGI transport mishandles an empty URL-Signature header: a request carrying the header with an empty value bypasses both Keystone authentication and pre-signed URL verification. An unauthenticated remote attacker who knows a target project's UUID can then read, enumerate, create, and delete that project's queues, messages, claims, and subscriptions. By additionally claiming an administrative role, the attacker may also perform administrative operations, such as managing pools and flavors in adminmode deployments. Only deployments using the WSGI transport with an authentication strategy configured are affected; the websocket transport is not affected.

Patches ~~~~~~~ - https://review.opendev.org/1007162 (2025.1/epoxy) - https://review.opendev.org/1007161 (2025.2/flamingo) - https://review.opendev.org/1007160 (2026.1/gazpacho) - https://review.opendev.org/1007159 (2026.2/hibiscus) - https://review.opendev.org/1007158 (2027.1/indri (development))

Credits ~~~~~~~ - pple from Independent (CVE-2026-97404)

References ~~~~~~~~~~ - https://launchpad.net/bugs/2164987 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-97404

Notes ~~~~~ - This issue is distinct from the EXTRA-SPEC header bypass in OSSA-2026-029; the fix for that issue removed the EXTRA-SPEC branch but left the empty-value handling of the URL-Signature header untouched.

-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

======================================================================= OSSA-2026-041: Cross-container information disclosure via Swift tempurl =======================================================================

:Date: September 24, 2026 :CVE: CVE-2026-97149

Affects ~~~~~~~ Description ~~~~~~~~~~~ Oren Yomtov from ACT Security and "swdb", a security researcher, independently reported a vulnerability in the Swift tempurl middleware. A party holding a single-object PUT TempURL signed with an account-level key (X-Account-Meta-Temp-URL-Key) could resend the signed request with an X-Copy-From header naming any object in the same account, causing Swift to copy the named object into the granted destination object, and read the copied bytes back with a second GET TempURL, disclosing objects the holder of the TempURL was not authorized to access. Only deployments with the tempurl middleware enabled are affected. The copy is limited to the account that owns the key, and the attacker must know the target container and object name.

As a mitigation, operators can add x-copy-from to the incomingremoveheaders option of the [filter:tempurl] section of their proxy server configuration. With that configuration the header is silently removed and the PUT stores no data; the patches below instead reject the request with a 400 response.

Patches ~~~~~~~ - https://review.opendev.org/1007050 (2025.1/epoxy) - https://review.opendev.org/1007049 (2025.2/flamingo) - https://review.opendev.org/1007048 (2026.1/gazpacho) - https://review.opendev.org/1007047 (2026.2/hibiscus) - https://review.opendev.org/1007046 (2027.1/indri (development))

Credits ~~~~~~~ - Oren Yomtov from ACT Security - swdb from Independent

References ~~~~~~~~~~ - https://launchpad.net/bugs/2166876 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-97149

Notes ~~~~~ - This issue is distinct from the S3API vulnerabilities in OSSA-2026-030; it affects the native Swift API with the default proxy pipeline and does not require the S3API middleware or the s3acl configuration.

-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

In OpenStack Zaqar before 22.0.2, WSGI transport mishandles the URL-Signature header. By sending a request with an empty URL-Signature header, an unauthenticated remote attacker who knows a target project's UUID may bypass both Keystone authentication and pre-signed URL verification, resulting in the ability to read, enumerate, create, and delete that project's queues, messages, claims, and subscriptions. By additionally claiming an administrative role, the attacker may also perform administrative operations, such as managing pools and flavors in adminmode deployments. Only deployments using the WSGI transport with an authentication strategy configured are affected; the websocket transport is not affected.

In OpenStack Swift before 2.38.2, the tempurl middleware does not reject the X-Copy-From header on PUT requests. A TempURL signature only covers the method, expiry, and path, and thus the list of disallowed headers is the only defense against a signed PUT request changing what the request does. An attacker holding a PUT TempURL for a single object can add an X-Copy-From header naming any object in the same account; the copy middleware copies that object to the destination, and the attacker then reads the victim's data back with a GET TempURL for the destination object. Copies across account boundaries are rejected. Only deployments using the shipped default proxy pipeline (tempurl and copy middleware) with account-level TempURL keys are affected.

========================================================================================== ==========================================================================================

:Date: September 21, 2026 :CVE: CVE-2026-94572, CVE-2026-94571

Affects ~~~~~~~ - Octavia: >=0.8.0 <16.1.0, ==17.0.0, ==18.0.0

Description ~~~~~~~~~~~ Chen YuXiang from the Institute of Computing Technology, Chinese Academy of Sciences reported input validation flaws in the Octavia load balancer API. The listener and pool tlsciphers fields and the L7 policy redirecturl and redirectprefix fields were written into the HAProxy configuration generated on the amphora without rejecting control characters, allowing an authenticated user who owns a load balancer managed by OpenStack Octavia's Amphora provider to inject arbitrary HAProxy configuration directives.

Subsequently, an independent reporter, "Rolix", demonstrated that these flaws can be exploited to execute arbitrary commands as root on the provider-managed amphora, to disclose other tenants' TLS private keys and certificates and the deployment heartbeat key stored on the amphora, and to reach the control-plane network to which the amphora is attached.

Only the Amphora provider driver is affected. Deployments that use a different provider driver do not render tenant input into an HAProxy configuration and are not affected.

Errata ~~~~~~ Patches ~~~~~~~ - https://review.opendev.org/1001096 (2025.1/epoxy) - https://review.opendev.org/1001097 (2025.1/epoxy) - https://review.opendev.org/1001094 (2025.2/flamingo) - https://review.opendev.org/1001095 (2025.2/flamingo) - https://review.opendev.org/1001091 (2026.1/gazpacho) - https://review.opendev.org/1001092 (2026.1/gazpacho) - https://review.opendev.org/999553 (2026.2/hibiscus) - https://review.opendev.org/999555 (2026.2/hibiscus)

Credits ~~~~~~~ - "Rolix" from Independent (CVE-2026-94572)

References ~~~~~~~~~~ - https://launchpad.net/bugs/2167565 - https://launchpad.net/bugs/2162101 - https://launchpad.net/bugs/2162103 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-94572 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-94571

Notes ~~~~~ - Two changes are required on each branch: one fixes the tlsciphers fields and one fixes the L7 policy redirect fields. - The listener and pool tlsciphers fields were introduced in Octavia 6.0.0. Releases within the affected range that predate 6.0.0 are vulnerable only through the L7 policy redirecturl and redirectprefix fields. - These issues were originally triaged as a low-severity hardening opportunity and the fixes were developed and merged in public. They were reclassified after a proof of concept demonstrated remote code execution as root on the amphora and reachability of the control-plane network. - The remote code execution issue was reported to the OpenStack VMT by Thomas Goirand (zigo) of Infomaniak, on behalf of the reporter, "Rolix".

OSSA History ~~~~~~~~~~~~ - 2026-09-21 - Errata 1 - 2026-09-21 - Original Version

-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

On 9/21/26 10:08 AM, Goutham Pacha Ravi wrote: ========================================================================================== ==========================================================================================

:Date: September 21, 2026 :CVE: CVE-2026-pending,       CVE-2026-pending

Affects ~~~~~~~ - Octavia: >=0.8.0 <16.1.0, ==17.0.0, ==18.0.0

Description ~~~~~~~~~~~ Chen YuXiang from the Institute of Computing Technology, Chinese Academy of Sciences reported input validation flaws in the Octavia load balancer API. The listener and pool tlsciphers fields and the L7 policy redirecturl and redirectprefix fields were written into the HAProxy configuration generated on the amphora without rejecting control characters, allowing an authenticated user who owns a load balancer managed by OpenStack Octavia's Amphora provider to inject arbitrary HAProxy configuration directives.

Subsequently, an independent reporter, "Rolix", demonstrated that these flaws can be exploited to execute arbitrary commands as root on the provider-managed amphora, to disclose other tenants' TLS private keys and certificates and the deployment heartbeat key stored on the amphora, and to reach the control-plane network to which the amphora is attached.

Only the Amphora provider driver is affected. Deployments that use a different provider driver do not render tenant input into an HAProxy configuration and are not affected.

Patches ~~~~~~~ - https://review.opendev.org/1001096 (2025.1/epoxy) - https://review.opendev.org/1001097 (2025.1/epoxy) - https://review.opendev.org/1001094 (2025.2/flamingo) - https://review.opendev.org/1001095 (2025.2/flamingo) - https://review.opendev.org/1001091 (2026.1/gazpacho) - https://review.opendev.org/1001092 (2026.1/gazpacho) - https://review.opendev.org/999553 (2026.2/hibiscus) - https://review.opendev.org/999555 (2026.2/hibiscus)

Credits ~~~~~~~ - "Rolix" from Independent

References ~~~~~~~~~~ - https://launchpad.net/bugs/2167565 - https://launchpad.net/bugs/2162101 - https://launchpad.net/bugs/2162103 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending

Notes ~~~~~ - Two changes are required on each branch: one fixes the tlsciphers   fields and one fixes the L7 policy redirect fields. - The listener and pool tlsciphers fields were introduced in   Octavia 6.0.0. Releases within the affected range that predate 6.0.0   are vulnerable only through the L7 policy redirecturl and   redirectprefix fields. - These issues were originally triaged as a low-severity hardening   opportunity and the fixes were developed and merged in public. They   were reclassified after a proof of concept demonstrated remote code   execution as root on the amphora and reachability of the control-plane   network. - The remote code execution issue was reported to the OpenStack VMT by   Thomas Goirand (zigo) of Infomaniak, on behalf of the reporter,   "Rolix". - CVE identifiers were requested from MITRE for these two   vulnerabilities on 2026-09-17. The CVEs will be added to this advisory   by errata once assigned.

-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

In OpenStack Octavia before 18.0.1, the Amphora provider driver did not validate the listener and pool tlsciphers 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.

In OpenStack Octavia before 18.0.1, the Amphora provider driver did not reject control characters in the L7 policy redirecturl and redirectprefix fields. The RFC 3986 URL validator percent-encodes control characters before validating, and thus newlines passed structural checks, but Octavia stored and wrote the raw unencoded value directly into the HAProxy configuration generated on the amphora. An authenticated project member who owns a load balancer can therefore inject arbitrary HAProxy directives through a REDIRECTTOURL L7 policy. Only deployments using the Amphora provider are affected.

========================================================================================== ==========================================================================================

:Date: September 21, 2026 :CVE: CVE-2026-pending, CVE-2026-pending

Affects ~~~~~~~ - Octavia: >=0.8.0 <16.1.0, ==17.0.0, ==18.0.0

Description ~~~~~~~~~~~ Chen YuXiang from the Institute of Computing Technology, Chinese Academy of Sciences reported input validation flaws in the Octavia load balancer API. The listener and pool tlsciphers fields and the L7 policy redirecturl and redirectprefix fields were written into the HAProxy configuration generated on the amphora without rejecting control characters, allowing an authenticated user who owns a load balancer managed by OpenStack Octavia's Amphora provider to inject arbitrary HAProxy configuration directives.

Subsequently, an independent reporter, "Rolix", demonstrated that these flaws can be exploited to execute arbitrary commands as root on the provider-managed amphora, to disclose other tenants' TLS private keys and certificates and the deployment heartbeat key stored on the amphora, and to reach the control-plane network to which the amphora is attached.

Only the Amphora provider driver is affected. Deployments that use a different provider driver do not render tenant input into an HAProxy configuration and are not affected.

Patches ~~~~~~~ - https://review.opendev.org/1001096 (2025.1/epoxy) - https://review.opendev.org/1001097 (2025.1/epoxy) - https://review.opendev.org/1001094 (2025.2/flamingo) - https://review.opendev.org/1001095 (2025.2/flamingo) - https://review.opendev.org/1001091 (2026.1/gazpacho) - https://review.opendev.org/1001092 (2026.1/gazpacho) - https://review.opendev.org/999553 (2026.2/hibiscus) - https://review.opendev.org/999555 (2026.2/hibiscus)

Credits ~~~~~~~ - "Rolix" from Independent

References ~~~~~~~~~~ - https://launchpad.net/bugs/2167565 - https://launchpad.net/bugs/2162101 - https://launchpad.net/bugs/2162103 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending

Notes ~~~~~ - Two changes are required on each branch: one fixes the tlsciphers fields and one fixes the L7 policy redirect fields. - The listener and pool tlsciphers fields were introduced in Octavia 6.0.0. Releases within the affected range that predate 6.0.0 are vulnerable only through the L7 policy redirecturl and redirectprefix fields. - These issues were originally triaged as a low-severity hardening opportunity and the fixes were developed and merged in public. They were reclassified after a proof of concept demonstrated remote code execution as root on the amphora and reachability of the control-plane network. - The remote code execution issue was reported to the OpenStack VMT by Thomas Goirand (zigo) of Infomaniak, on behalf of the reporter, "Rolix". - CVE identifiers were requested from MITRE for these two vulnerabilities on 2026-09-17. The CVEs will be added to this advisory by errata once assigned.

-- Goutham Pacha Ravi OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

In OpenStack Blazar before 17.0.1, the V2 lease API does not enforce object-level authorization on its update and delete operations (PUT /v2/leases/{leaseid} and DELETE /v2/leases/{leaseid}). The policy authorize() wrapper attempts to load the target lease to build the authorization target from its owner, but it looks up the lease under the keyword "leaseid" whereas the controller methods name the parameter "id" (and the wsmepecan.wsexpose wrapper delivers it positionally). The lookup returns None, and thus authorization falls back to the requesting user's own projectid/userid instead of the target lease owner. Any authenticated user who knows a lease ID can therefore modify or delete leases belonging to other users and projects, bypassing the intended ownership check.

In OpenStack Blazar before 17.0.1, the V2 lease listing operation (GET /v2/leases) returns leases for every project without enforcing project scoping or an administrator-only policy. Any authenticated user with access to the Blazar REST API can enumerate leases belonging to other tenants, exposing lease IDs, reservation IDs, resource IDs, and reservation metadata. The exposed lease IDs also enable the object-level authorization bypass tracked in the companion request, allowing an attacker to then modify or delete the enumerated leases.

OpenStack Ironic through 38.0.0 may send a username and password to an unexpected remote host when Image Service is configured for HTTP(S) Basic Authentication.

An issue was discovered in OpenStack Keystone before 29.0.3. Tokens obtained via delegated authentication methods (EC2 credentials, application credentials, OAuth1 access tokens, and trusts) are not blocked from creating, modifying, or deleting credentials via the /v3/credentials API. EC2-derived tokens can additionally read credential blobs, exposing TOTP MFA seeds and other secrets. Also, PATCH /v3/credentials does not validate the requested post-update projectid, allowing any delegated token to move a credential to an unauthorized project. All Keystone deployments using delegated authentication are affected.