============================================================= ============================================================= 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.

In OpenStack Glance before 32.0.1, the location API does not validate destination hosts when adding an HTTP location to an image. Unlike the web-download import path, the location API only checks the URL scheme and does not apply the importfilteringopts host restrictions. An authenticated user can add a location pointing to internal endpoints such as the cloud metadata service (169.254.169.254), and retrieve the response by downloading the image data. This affects both the new POST /v2/images/{id}/locations API and the old PATCH API when showmultiplelocations is enabled. Deployments with the HTTP store backend enabled are affected.

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

:Date: September 03, 2026 :CVE: CVE-2026-71196, CVE-2026-71197, CVE-2026-71198

Affects ~~~~~~~ - Glance: >=16.0.0 <30.2.1, >=31.0.0 <31.1.1, >=32.0.0 <32.0.1

Description ~~~~~~~~~~~ Sergey Kanibor (Luntry), Sami Yessou (switch.ch), and Abhishek Kekane (Red Hat) reported three related SSRF vulnerabilities in OpenStack Glance.

The web-download import method ships with insecure default filtering that permits authenticated users to fetch arbitrary internal URLs, including cloud metadata endpoints. The URI validator does not perform DNS resolution before applying host filters, enabling bypass via attacker-controlled domains and DNS rebinding attacks. The HTTP image location API lacks host filtering entirely when the HTTP store is enabled, and fetched content is stored as image data accessible for download, converting blind SSRF into full-read exfiltration.

All Glance deployments using the web-download import method or HTTP image location APIs are affected.

Patches ~~~~~~~ - https://review.opendev.org/1003822 (2025.1/epoxy) - https://review.opendev.org/1003823 (2025.1/epoxy) - https://review.opendev.org/1003824 (2025.1/epoxy) - https://review.opendev.org/1003825 (2025.1/epoxy) - https://review.opendev.org/1003816 (2025.2/flamingo) - https://review.opendev.org/1003817 (2025.2/flamingo) - https://review.opendev.org/1003818 (2025.2/flamingo) - https://review.opendev.org/1003819 (2025.2/flamingo) - https://review.opendev.org/1003812 (2026.1/gazpacho) - https://review.opendev.org/1003813 (2026.1/gazpacho) - https://review.opendev.org/1003814 (2026.1/gazpacho) - https://review.opendev.org/1003815 (2026.1/gazpacho) - https://review.opendev.org/1003805 (2026.2/hibiscus (development)) - https://review.opendev.org/1003806 (2026.2/hibiscus (development)) - https://review.opendev.org/1003807 (2026.2/hibiscus (development)) - https://review.opendev.org/1003808 (2026.2/hibiscus (development))

Credits ~~~~~~~ - Sergey Kanibor from Luntry (CVE-2026-71196, CVE-2026-71197) - Sami Yessou from switch.ch (CVE-2026-71196) - Abhishek Kekane from Red Hat (CVE-2026-71198)

References ~~~~~~~~~~ - https://launchpad.net/bugs/2158998 - https://launchpad.net/bugs/2158999 - https://launchpad.net/bugs/2161330 - https://launchpad.net/bugs/2160020 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-71196 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-71197 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-71198

Notes ~~~~~ - All four commits in each patch set are interdependent and must be applied together, in the order listed above, as each builds on the previous. The DoS issue (LP#2160020) is addressed as part of this coordinated fix. - A related Tempest test compatibility fix was proposed at https://review.opendev.org/1003560

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

A flaw was found in openstack-network-exporter. The HTTP server within the component is configured without essential timeout settings, such as ReadHeaderTimeout. This vulnerability allows an unauthenticated, remote attacker to initiate multiple slow HTTP header connections. By trickling header bytes, the attacker can exhaust server resources, specifically file descriptors, leading to a Denial of Service (DoS) that prevents legitimate Prometheus metric scraping and alerting.

FIND-004 from Project Glasswing AI-SAST audit of openstack-k8s-operators/openstack-network-exporter (audit date 2026-06-12, harness version 0.32.0-57f1ef1). Confirmed exploitable (3/3 TP vote, dynamic validation 2026-07-15).

http.Server{Addr: ..., Handler: mux, ErrorLog: ...} in main.go (lines 73-84) is constructed without ReadHeaderTimeout, ReadTimeout, WriteTimeout, or IdleTimeout. The promhttp handler's 2-second Timeout only starts after the request line and headers are fully parsed, so a client that trickles header bytes can hold a goroutine and file descriptor open indefinitely. Because the listener defaults to all interfaces (see FIND-003), an unauthenticated adjacent attacker can exhaust server FDs and block legitimate Prometheus scrapes. Flagged by gosec rule G112.

Attack pattern: Unauthenticated client opens many slow-header TCP connections to :1981, causing exporter file-descriptor exhaustion, which makes metrics scraping and alerting go blind.

Affected code: main.go:73-84

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L (5.3, Medium)

Remediation: Set ReadHeaderTimeout: 10time.Second, ReadTimeout: 30time.Second, WriteTimeout: 30time.Second, IdleTimeout: 60time.Second on the http.Server struct, or migrate to exporter-toolkit/web.ListenAndServe which applies sane defaults.

FIND-003 from Project Glasswing AI-SAST audit of openstack-k8s-operators/openstack-network-exporter (audit date 2026-06-12, harness version 0.32.0-57f1ef1). Confirmed exploitable (3/3 TP vote, dynamic validation 2026-07-15).

The basic-auth wrapper in main.go (lines 75-84) is only installed inside the if config.TlsCert() != "" && config.TlsKey() != "" branch. If an operator sets auth-users: but omits or misconfigures tls-cert/tls-key, the server falls through to plain server.ListenAndServe() with no authentication and no warning. The compiled-in default HttpListen: ":1981" binds all interfaces, so in the default/shipped configuration the OVS/OVN dataplane metrics (bridge names, port counters, OVN controller state, host PMD/CPU layout) are exposed to any adjacent network peer that can reach the node on tcp/1981. This is a fail-open authentication design.

Attack pattern: Adjacent-network or same-cluster attacker scrapes http://<node>:1981/metrics to enumerate OVS bridges, OVN cluster state and host topology without credentials.

Affected code: main.go:75-84, config/config.go:79-89

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (6.5, Medium)

Remediation: Apply basicAuthHandler regardless of TLS, and emit a startup warning (or refuse to start) when auth-users is non-empty but TLS is disabled. Change the default http-listen to 127.0.0.1:1981 so that exposure beyond localhost is an explicit operator decision.