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

In OpenStack Keystone before 29.0.3, any authenticated user holding role:reader on any project can list every project-scoped role assignment under any domain by passing a domain ID as scope.project.id with includesubtree to the GET /v3/roleassignments endpoint. The domain's project record has domainid=null, causing the policy domainid check to pass for any caller. With includenames, the response discloses the names and home-domain IDs of every user, group, project, and role involved. The literal "default" domain ID works against any deployment created with keystone-manage bootstrap. An attacker can harvest domain IDs from the response and repeat the query to map role assignments across the entire cloud. This is caused by misuse of "None" in

listroleassignmentsfortree.

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

:Date: August 25, 2026 :CVE: CVE-2026-80182, CVE-2026-80184

Affects ~~~~~~~ - Keystone: >=13.0.0 <27.0.3, >=28.0.0 <28.0.3, >=29.0.0 <29.0.3

Description ~~~~~~~~~~~ Grzegorz Grasza (Red Hat) reported that OpenStack Keystone did not consistently block delegated tokens from creating new long-lived credentials or authorizing new delegations. Tim Shephard (roiai.ca) separately reported that delegated tokens could be submitted to the token-method authentication path to escape their project scope.

A token scoped through an OAuth1 access token, an application credential, or a trust could create new long-lived credentials or authorize new delegations that persist independently of, and outlive, the credential used to obtain them. Separately, tokens obtained through any of these delegation mechanisms could be submitted to the token-method authentication path for reauthentication. When an application credential token was presented with no explicit scope, Keystone would issue a new token scoped to the credential owner's default project rather than the project for which the credential was issued, escaping the intended project boundary.

All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected.

Errata ~~~~~~ Patches ~~~~~~~ - https://review.opendev.org/1002307 (2025.1/epoxy) - https://review.opendev.org/1002308 (2025.1/epoxy) - https://review.opendev.org/1002305 (2025.2/flamingo) - https://review.opendev.org/1002306 (2025.2/flamingo) - https://review.opendev.org/1002303 (2026.1/gazpacho) - https://review.opendev.org/1002304 (2026.1/gazpacho) - https://review.opendev.org/1002301 (2026.2/hibiscus (development)) - https://review.opendev.org/1002302 (2026.2/hibiscus (development))

Credits ~~~~~~~ - Grzegorz Grasza from Red Hat (CVE-2026-80182) - Tim Shephard from roiai.ca (CVE-2026-80184)

References ~~~~~~~~~~ - https://launchpad.net/bugs/2153453 - https://launchpad.net/bugs/2158538 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-80182 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-80184

Notes ~~~~~ - The two patch sets are interdependent and must be applied together. The token reauthentication guard introduced by the second patch depends on the delegation classification logic and the new [auth] additionalprimaryauthmethods configuration option introduced by the first. Packaging or applying a subset is not supported. - After upgrading, Keystone treats any authentication method not built in to Keystone as a delegated credential and rejects it from guarded operations (managing trusts, application credentials, and OAuth1 access tokens, and token reauthentication). Deployments running a custom or third-party authentication plugin must add it to [auth] additionalprimaryauthmethods or those authentication flows will fail. - This advisory does not address a related weakness in EC2 credential (ec2credential) handling, which is being tracked and fixed in public and will be covered by a separate OpenStack Security Note (OSSN). - A related fix to the Keystone Tempest plugin test suite was proposed at https://review.opendev.org/1002296

OSSA History ~~~~~~~~~~~~ - 2026-08-25 - Errata 1 - 2026-08-25 - Original Version

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

On 8/25/26 10:06 AM, Goutham Pacha Ravi wrote: ============================================================================== ==============================================================================

:Date: August 25, 2026 :CVE: CVE-2026-pending,       CVE-2026-pending

Affects ~~~~~~~ - Keystone: >=13.0.0 <27.0.3, >=28.0.0 <28.0.3, >=29.0.0 <29.0.3

Description ~~~~~~~~~~~ Grzegorz Grasza (Red Hat) reported that OpenStack Keystone did not consistently block delegated tokens from creating new long-lived credentials or authorizing new delegations. Tim Shephard (roiai.ca) separately reported that delegated tokens could be submitted to the token-method authentication path to escape their project scope.

A token scoped through an OAuth1 access token, an application credential, or a trust could create new long-lived credentials or authorize new delegations that persist independently of, and outlive, the credential used to obtain them. Separately, tokens obtained through any of these delegation mechanisms could be submitted to the token-method authentication path for reauthentication. When an application credential token was presented with no explicit scope, Keystone would issue a new token scoped to the credential owner's default project rather than the project for which the credential was issued, escaping the intended project boundary.

All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected.

Patches ~~~~~~~ - https://review.opendev.org/1002307 (2025.1/epoxy) - https://review.opendev.org/1002308 (2025.1/epoxy) - https://review.opendev.org/1002305 (2025.2/flamingo) - https://review.opendev.org/1002306 (2025.2/flamingo) - https://review.opendev.org/1002303 (2026.1/gazpacho) - https://review.opendev.org/1002304 (2026.1/gazpacho) - https://review.opendev.org/1002301 (2026.2/hibiscus (development)) - https://review.opendev.org/1002302 (2026.2/hibiscus (development))

Credits ~~~~~~~ - Grzegorz Grasza from Red Hat - Tim Shephard from roiai.ca

References ~~~~~~~~~~ - https://launchpad.net/bugs/2153453 - https://launchpad.net/bugs/2158538 - 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 CVEs have been requested from MITRE for these vulnerabilities and   are pending assignment. - The two patch sets are interdependent and must be applied together.   The token reauthentication guard introduced by the second patch   depends on the delegation classification logic and the new [auth]   additionalprimaryauthmethods configuration option introduced by   the first. Packaging or applying a subset is not supported. - After upgrading, Keystone treats any authentication method not built   in to Keystone as a delegated credential and rejects it from guarded   operations (managing trusts, application credentials, and OAuth1   access tokens, and token reauthentication). Deployments running a   custom or third-party authentication plugin must add it to [auth]   additionalprimaryauthmethods or those authentication flows will   fail. - This advisory does not address a related weakness in EC2 credential   (ec2credential) handling, which is being tracked and fixed in   public and will be covered by a separate OpenStack Security Note   (OSSN). - A related fix to the Keystone Tempest plugin test suite was proposed   at https://review.opendev.org/1002296

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

In OpenStack Keystone before 29.0.3, tokens obtained via delegated authentication mechanisms (OAuth1 access tokens, application credentials, trusts) could be submitted to the token-method authentication path for reauthentication to escape their intended project scope. When an application credential token was presented with no explicit scope, Keystone would issue a new token scoped to the credential owner's default project rather than the project for which the credential was issued, bypassing the intended project boundary. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected.

In OpenStack Keystone before 29.0.3, tokens obtained via OAuth1 access token, application credential, or trust-scoped authentication could create new long-lived credentials or authorize new delegations that persist independently of, and outlive, the credential used to obtain them. The delegation restrictions that block these operations did not consistently apply to all delegated token types, allowing an OAuth1-scoped token, for example, to create application credentials or authorize OAuth1 request tokens despite those operations being restricted for other delegated token types. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected.

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

:Date: August 25, 2026 :CVE: CVE-2026-pending, CVE-2026-pending

Affects ~~~~~~~ - Keystone: >=13.0.0 <27.0.3, >=28.0.0 <28.0.3, >=29.0.0 <29.0.3

Description ~~~~~~~~~~~ Grzegorz Grasza (Red Hat) reported that OpenStack Keystone did not consistently block delegated tokens from creating new long-lived credentials or authorizing new delegations. Tim Shephard (roiai.ca) separately reported that delegated tokens could be submitted to the token-method authentication path to escape their project scope.

A token scoped through an OAuth1 access token, an application credential, or a trust could create new long-lived credentials or authorize new delegations that persist independently of, and outlive, the credential used to obtain them. Separately, tokens obtained through any of these delegation mechanisms could be submitted to the token-method authentication path for reauthentication. When an application credential token was presented with no explicit scope, Keystone would issue a new token scoped to the credential owner's default project rather than the project for which the credential was issued, escaping the intended project boundary.

All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected.

Patches ~~~~~~~ - https://review.opendev.org/1002307 (2025.1/epoxy) - https://review.opendev.org/1002308 (2025.1/epoxy) - https://review.opendev.org/1002305 (2025.2/flamingo) - https://review.opendev.org/1002306 (2025.2/flamingo) - https://review.opendev.org/1002303 (2026.1/gazpacho) - https://review.opendev.org/1002304 (2026.1/gazpacho) - https://review.opendev.org/1002301 (2026.2/hibiscus (development)) - https://review.opendev.org/1002302 (2026.2/hibiscus (development))

Credits ~~~~~~~ - Grzegorz Grasza from Red Hat - Tim Shephard from roiai.ca

References ~~~~~~~~~~ - https://launchpad.net/bugs/2153453 - https://launchpad.net/bugs/2158538 - 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 CVEs have been requested from MITRE for these vulnerabilities and are pending assignment. - The two patch sets are interdependent and must be applied together. The token reauthentication guard introduced by the second patch depends on the delegation classification logic and the new [auth] additionalprimaryauthmethods configuration option introduced by the first. Packaging or applying a subset is not supported. - After upgrading, Keystone treats any authentication method not built in to Keystone as a delegated credential and rejects it from guarded operations (managing trusts, application credentials, and OAuth1 access tokens, and token reauthentication). Deployments running a custom or third-party authentication plugin must add it to [auth] additionalprimaryauthmethods or those authentication flows will fail. - This advisory does not address a related weakness in EC2 credential (ec2credential) handling, which is being tracked and fixed in public and will be covered by a separate OpenStack Security Note (OSSN). - A related fix to the Keystone Tempest plugin test suite was proposed at https://review.opendev.org/1002296

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

In OpenStack Glance through 32.0.0, the /v2/tasks API accepts type=import tasks that bypass importfilteringopts, allowing an admin to fetch internal URLs from the Glance service network (aka SSRF), as long as https:// or http:// is used. This API has been available only to admins since Xena, and it has been deprecated for several releases.

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

:Date: August 19, 2026 :CVE: CVE-2026-76878

Affects ~~~~~~~ - Aodh: >=10.0.0 <20.0.1, ==21.0.0, ==22.0.0 - Watcher: >=4.0.0 <14.1.2, >=15.0.0 <15.1.2, >=16.0.0 <16.0.2

Description ~~~~~~~~~~~ Chen YuXiang of the Institute of Computing Technology, Chinese Academy of Sciences reported that OpenStack Aodh does not enforce project scope on the alarm listing API when the allprojects query parameter is supplied with a false value. A non-admin user holding only the reader role can list alarms belonging to other projects, optionally targeting a specific project, exposing alarm metadata such as webhook action URLs, signal endpoints, and project identifiers. All Aodh deployments are affected.

The same reporter found that OpenStack Watcher does not apply authorization to its webhook trigger endpoint. Any authenticated user who learns an audit's webhook URL, for example from the Aodh alarm metadata leaked above, can start an EVENT audit and its associated action plan regardless of their own project or role. All Watcher deployments are affected.

Errata ~~~~~~ MITRE assigned CVE-2026-76878 after initial publication.

Patches ~~~~~~~ - https://review.opendev.org/1001503 (2025.1/epoxy (aodh)) - https://review.opendev.org/1001509 (2025.1/epoxy (watcher)) - https://review.opendev.org/1001502 (2025.2/flamingo (aodh)) - https://review.opendev.org/1001508 (2025.2/flamingo (watcher)) - https://review.opendev.org/1001501 (2026.1/gazpacho (aodh)) - https://review.opendev.org/1001507 (2026.1/gazpacho (watcher)) - https://review.opendev.org/1001500 (2026.2/hibiscus (development) (aodh)) Credits ~~~~~~~ References ~~~~~~~~~~ - https://launchpad.net/bugs/2161276 - https://launchpad.net/bugs/2161771 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-76878

OSSA History ~~~~~~~~~~~~ - 2026-08-20 - Errata 1 - 2026-08-19 - Original Version

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

On 8/19/26 9:18 AM, Goutham Pacha Ravi wrote: ============================================================================================ ============================================================================================

:Date: August 19, 2026 :CVE: CVE-2026-pending

Affects ~~~~~~~ - Aodh: >=10.0.0 <20.0.1, ==21.0.0, ==22.0.0 - Watcher: >=4.0.0 <14.1.2, >=15.0.0 <15.1.2, >=16.0.0 <16.0.2

Description ~~~~~~~~~~~ Chen YuXiang of the Institute of Computing Technology, Chinese Academy of Sciences reported that OpenStack Aodh does not enforce project scope on the alarm listing API when the allprojects query parameter is supplied with a false value. A non-admin user holding only the reader role can list alarms belonging to other projects, optionally targeting a specific project, exposing alarm metadata such as webhook action URLs, signal endpoints, and project identifiers. All Aodh deployments are affected.

The same reporter found that OpenStack Watcher does not apply authorization to its webhook trigger endpoint. Any authenticated user who learns an audit's webhook URL, for example from the Aodh alarm metadata leaked above, can start an EVENT audit and its associated action plan regardless of their own project or role. All Watcher deployments are affected.

Patches ~~~~~~~ - https://review.opendev.org/1001503 (2025.1/epoxy (aodh)) - https://review.opendev.org/1001509 (2025.1/epoxy (watcher)) - https://review.opendev.org/1001502 (2025.2/flamingo (aodh)) - https://review.opendev.org/1001508 (2025.2/flamingo (watcher)) - https://review.opendev.org/1001501 (2026.1/gazpacho (aodh)) - https://review.opendev.org/1001507 (2026.1/gazpacho (watcher)) - https://review.opendev.org/1001500 (2026.2/hibiscus (development) (aodh)) Credits ~~~~~~~ References ~~~~~~~~~~ - https://launchpad.net/bugs/2161276 - https://launchpad.net/bugs/2161771 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending

Notes ~~~~~ - A CVE identifier was requested from MITRE for the aodh vulnerability   on 2026-08-03. 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 Aodh before 22.0.1, the alarm list API bypasses project scoping when the allprojects query parameter is set to false. The API checks for the presence of the allprojects key rather than its value; a true value enforces the administrator-only policy, but a false value removes the key and skips the branch that normally restricts results to the caller's project. A non-admin user with the reader role can list alarms from all projects, exposing alarm actions containing trust webhook URLs, Heat signal endpoints, project IDs, and user IDs. The parameter can also be combined with a foreign projectid to target a specific project's alarms. A related concern is that OpenStack Watcher does not apply authorization to its webhook trigger endpoint. Any authenticated user who learns an audit's webhook URL, for example from this leaked Aodh alarm metadata, can start an EVENT audit and its associated action plan regardless of their own project or role. The webhook endpoint has lacked policy enforcement since its introduction in the Ussuri release (Watcher 4.0.0).

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

:Date: August 19, 2026 :CVE: CVE-2026-pending

Affects ~~~~~~~ - Aodh: >=10.0.0 <20.0.1, ==21.0.0, ==22.0.0 - Watcher: >=4.0.0 <14.1.2, >=15.0.0 <15.1.2, >=16.0.0 <16.0.2

Description ~~~~~~~~~~~ Chen YuXiang of the Institute of Computing Technology, Chinese Academy of Sciences reported that OpenStack Aodh does not enforce project scope on the alarm listing API when the allprojects query parameter is supplied with a false value. A non-admin user holding only the reader role can list alarms belonging to other projects, optionally targeting a specific project, exposing alarm metadata such as webhook action URLs, signal endpoints, and project identifiers. All Aodh deployments are affected.

The same reporter found that OpenStack Watcher does not apply authorization to its webhook trigger endpoint. Any authenticated user who learns an audit's webhook URL, for example from the Aodh alarm metadata leaked above, can start an EVENT audit and its associated action plan regardless of their own project or role. All Watcher deployments are affected.

Patches ~~~~~~~ - https://review.opendev.org/1001503 (2025.1/epoxy (aodh)) - https://review.opendev.org/1001509 (2025.1/epoxy (watcher)) - https://review.opendev.org/1001502 (2025.2/flamingo (aodh)) - https://review.opendev.org/1001508 (2025.2/flamingo (watcher)) - https://review.opendev.org/1001501 (2026.1/gazpacho (aodh)) - https://review.opendev.org/1001507 (2026.1/gazpacho (watcher)) - https://review.opendev.org/1001500 (2026.2/hibiscus (development) (aodh)) Credits ~~~~~~~ References ~~~~~~~~~~ - https://launchpad.net/bugs/2161276 - https://launchpad.net/bugs/2161771 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending

Notes ~~~~~ - A CVE identifier was requested from MITRE for the aodh vulnerability on 2026-08-03. 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 Ironic before 38.0.1, the autodetect deploy interface may fail to run cleaning immediately after enrollment with, or changing to, the autodetect deploy interface.

Last updated 19 August 2026

In OpenStack Designate before 22.0.2, the mDNS handler performs pool-blind lookups when resolving record queries and NOTIFY requests. When two zones with the same name exist across different pools, the lookup fails with a deterministic error, causing the handler to return REFUSED for all DNS queries through that path. The handlenotify path is exploitable via a single unauthenticated UDP packet. This is independently reachable through the cross-tenant zone overlap described in a different recent CVE, and also affects legitimate same-tenant cross-pool configurations. BIND9 views do not mitigate this issue as mDNS is a shared service upstream of any view configuration.

In OpenStack Designate before 22.0.1, zone creation checks (issubzone, issuperzone, and the duplicate-zone DB constraint) are scoped to the target pool only. An authenticated user can bypass these checks by scheduling a zone to a different pool via the AttributeFilter scheduler, creating an overlapping zone that conflicts with another tenant's zone. This enables cross-tenant DNS hijack (redirecting traffic to attacker-controlled IPs) and DNS denial of service (NODATA responses). Exploitation requires a multi-pool deployment with AttributeFilter enabled in schedulerfilters, which is a non-default but documented and supported configuration for self-service tiering.

Errata 1 for OSSA-2026-031: CVE-2026-71190 has been assigned.

============================================================== OSSA-2026-031: Swift proxy denial of service via Accept header ==============================================================

:Date: July 28, 2026 :CVE: CVE-2026-71190

Affects ~~~~~~~ - Swift: >=1.9.1 <2.35.4, >=2.36.0 <2.36.3, >=2.37.0 <2.37.3, ==2.38.0

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

Patches ~~~~~~~ - https://review.opendev.org/998953 (2025.1/epoxy) - https://review.opendev.org/998952 (2025.2/flamingo) - https://review.opendev.org/998951 (2026.1/gazpacho) - https://review.opendev.org/998950 (2026.2/hibiscus (development))

Credits ~~~~~~~ - Christian Schwede from NVIDIA

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

OSSA History ~~~~~~~~~~~~ - 2026-08-05 - Errata 1 - 2026-07-28 - Original Version

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

On 7/28/26 8:28 AM, Goutham Pacha Ravi wrote: ============================================================== OSSA-2026-031: Swift proxy denial of service via Accept header ==============================================================

:Date: July 28, 2026 :CVE: CVE-2026-pending

Affects ~~~~~~~ - Swift: >=1.9.1 <2.35.4, >=2.36.0 <2.36.3, >=2.37.0 <2.37.3, ==2.38.0

Description ~~~~~~~~~~~ Patches ~~~~~~~ - https://review.opendev.org/998953 (2025.1/epoxy) - https://review.opendev.org/998952 (2025.2/flamingo) - https://review.opendev.org/998951 (2026.1/gazpacho) - https://review.opendev.org/998950 (2026.2/hibiscus (development))

Credits ~~~~~~~ - Christian Schwede from NVIDIA

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

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