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

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

OpenStack Octavia through 18.0.0 mishandles quality of service (QoS) policy authorization. By associating another project's QoS policy with an amphora, an authenticated user may prevent deletion of that policy. All Octavia deployments are affected.

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

====================================================== OSSA-2026-030: Swift S3API header authorization bypass ======================================================

:Date: July 28, 2026 :CVE: CVE-2026-71191, CVE-2026-71192

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

Description ~~~~~~~~~~~ Errata ~~~~~~ Patches ~~~~~~~ - https://review.opendev.org/998948 (2025.1/epoxy) - https://review.opendev.org/998949 (2025.1/epoxy) - https://review.opendev.org/998946 (2025.2/flamingo) - https://review.opendev.org/998947 (2025.2/flamingo) - https://review.opendev.org/998944 (2026.1/gazpacho) - https://review.opendev.org/998945 (2026.1/gazpacho) - https://review.opendev.org/998942 (2026.2/hibiscus (development)) - https://review.opendev.org/998943 (2026.2/hibiscus (development))

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

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

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:27 AM, Goutham Pacha Ravi wrote: ====================================================== OSSA-2026-030: Swift S3API header authorization bypass ======================================================

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

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

Description ~~~~~~~~~~~ Patches ~~~~~~~ - https://review.opendev.org/998948 (2025.1/epoxy) - https://review.opendev.org/998949 (2025.1/epoxy) - https://review.opendev.org/998946 (2025.2/flamingo) - https://review.opendev.org/998947 (2025.2/flamingo) - https://review.opendev.org/998944 (2026.1/gazpacho) - https://review.opendev.org/998945 (2026.1/gazpacho) - https://review.opendev.org/998942 (2026.2/hibiscus (development)) - https://review.opendev.org/998943 (2026.2/hibiscus (development))

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

References ~~~~~~~~~~ - https://launchpad.net/bugs/2158733 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending - 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

Errata 1 for OSSA-2026-007: CVE-2026-40683 has been assigned.

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

:Date: April 14, 2026 :CVE: CVE-2026-40683

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

Patches ~~~~~~~ - https://review.opendev.org/982409 (2024.2/dalmatian) - https://review.opendev.org/982408 (2025.1/epoxy) - https://review.opendev.org/982407 (2025.2/flamingo) - https://review.opendev.org/958205 (2026.1/gazpacho)

Credits ~~~~~~~ - Benedikt Trefzer from Cirrax GmbH (CVE-2026-40683) - Andrew Bogott from Wikimedia Foundation (CVE-2026-40683) - Grzegorz Grasza from Red Hat (CVE-2026-40683)

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

Notes ~~~~~ - To work around this vulnerability, set userenabledinvert=True and use an LDAP attribute with inverted semantics such as nsAccountLock, or use userenabledemulation with group-based enabled status. - The fix was merged on the master branch before the stable/2026.1 branch was cut, so no specific stable/2026.1 patch exists. The fix is included in the gazpacho (29.0.0) release.

OSSA History ~~~~~~~~~~~~ - 2026-08-05 - Errata 1 - 2026-04-14 - Original Version

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

On 4/14/26 9:51 AM, Goutham Pacha Ravi wrote: ================================================================================== OSSA-2026-007: LDAP identity backend does not convert enabled attribute to boolean ==================================================================================

:Date: April 14, 2026 :CVE: CVE-2026-pending

Affects ~~~~~~~ - Keystone: >=8.0.0 <25.0.1, >=26.0.0 <26.1.1, >=27.0.0 <27.0.1, >=28.0.0 <28.0.1

Description ~~~~~~~~~~~ Benedikt Trefzer and Andrew Bogott independently reported a vulnerability in the Keystone LDAP identity backend. When the userenabledinvert configuration option was False (the default), Keystone did not correctly interpret the LDAP enabled attribute, causing users disabled in LDAP to be treated as enabled and allowed to authenticate. Deployments using the LDAP identity backend without userenabledinvert=True or userenabledemulation are affected.

Patches ~~~~~~~ -https://review.opendev.org/982409 (2024.2/dalmatian) -https://review.opendev.org/982408 (2025.1/epoxy) -https://review.opendev.org/982407 (2025.2/flamingo) -https://review.opendev.org/958205 (2026.1/gazpacho)

Credits ~~~~~~~ - Benedikt Trefzer from Cirrax GmbH (CVE-2026-pending) - Andrew Bogott from Wikimedia Foundation (CVE-2026-pending) - Grzegorz Grasza from Red Hat (CVE-2026-pending)

References ~~~~~~~~~~ -https://launchpad.net/bugs/2121152 -https://launchpad.net/bugs/2141713

Notes ~~~~~ - To work around this vulnerability, set userenabledinvert=True and use an LDAP attribute with inverted semantics such as nsAccountLock, or use userenabledemulation with group-based enabled status. - A CVE request was filed with MITRE on 2026-04-10. - The fix was merged on the master branch before the stable/2026.1 branch was cut, so no specific stable/2026.1 patch exists. The fix is included in the gazpacho (29.0.0) release.

-- Goutham Pacha Ravi (gouthamr) OpenStack Vulnerability Management Team

============================================================ OSSA-2026-033: Portgroup shard filter bypasses project scope ============================================================

:Date: August 05, 2026 :CVE: CVE-2026-71201

Affects ~~~~~~~ - Ironic: >=34.0.0 <35.0.2, >=36.0.0 <38.0.1

Description ~~~~~~~~~~~ Chen YuXiang of Institute of Computing Technology, Chinese Academy of Sciences reported an issue in Ironic's API. When a project reader requests a list of portgroups filtered by shard, all portgroups in that shard are returned, not just those in their project.

This is a similar vulnerability to the one originally advisoried in OSSA-2026-026 -- that issue impacted ports; this impacts portgroups.

Patches ~~~~~~~ - https://review.opendev.org/999762 (2026.1/gazpacho) - https://review.opendev.org/999656 (2026.2/hibiscus (development)) - https://review.opendev.org/999765 (Bugfix/34.0) - https://review.opendev.org/999764 (Bugfix/37.0) - https://review.opendev.org/999763 (Bugfix/38.0)

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

Notes ~~~~~ - Ironic bugfix branch patches will be available in git for interested   operators. We will not perform an additional release from these   branches.

In OpenStack Ironic through 38.0.0, a project reader that makes a crafted request to Ironic can return Portgroups assigned to Nodes owned or leased by another project.

In OpenStack Swift through 2.38.0, the S3API middleware does not sanitize Swift-native control headers (X-Copy-From, X-Copy-From-Account) from S3 API requests when s3acl=true. An attacker can inject these headers into a signed PUT request targeting their own bucket, causing Swift to perform a server-side copy from another tenant's private object. The source object authorization is bypassed because the S3API middleware has already authorized the request against the destination. The attacker can read any object whose projectid, container name, and object name are known, regardless of the source object's ACLs or ownership. This requires the non-default s3acl=true configuration.

In OpenStack Swift through 2.38.0, S3API middleware does not enforce that semantic x-amz- headers are covered by the SigV4 signature on presigned URL requests. An attacker who obtains a presigned PUT URL can inject an unsigned X-Amz-Copy-Source header, causing Swift to perform a server-side copy from an arbitrary source object using the signer's authorization context. The attacker can read any object the signer has access to, provided the target projectid, container name, and object name are known. This affects all deployments using the default s3acl=false configuration.

In OpenStack Swift through 2.38.0, the proxy server Accept header parser contains a regular expression vulnerable to catastrophic backtracking (ReDoS). The "qdtext" pattern (?:[^"]|\\.) allows an unauthenticated remote attacker to send a crafted Accept header that causes exponential CPU consumption in the proxy worker. A payload of 32 backslash-character pairs exceeds 30 seconds of CPU time. No authentication is required. Repeated requests can exhaust all proxy worker threads, resulting in a complete denial of service.

In OpenStack Neutron before 28.0.2, the subnetpool onboarding API does not verify ownership of the target subnets. An authenticated user can onboard subnets from another project's shared network into their own subnetpool, mutating the victim's subnet state and altering L3 routing and address scope behavior for victim routers.

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

====================================================== OSSA-2026-030: Swift S3API header authorization bypass ======================================================

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

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

Description ~~~~~~~~~~~ Patches ~~~~~~~ - https://review.opendev.org/998948 (2025.1/epoxy) - https://review.opendev.org/998949 (2025.1/epoxy) - https://review.opendev.org/998946 (2025.2/flamingo) - https://review.opendev.org/998947 (2025.2/flamingo) - https://review.opendev.org/998944 (2026.1/gazpacho) - https://review.opendev.org/998945 (2026.1/gazpacho) - https://review.opendev.org/998942 (2026.2/hibiscus (development)) - https://review.opendev.org/998943 (2026.2/hibiscus (development))

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

References ~~~~~~~~~~ - https://launchpad.net/bugs/2158733 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending - 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

======================================================================= OSSA-2026-029: Zaqar EXTRA-SPEC header bypasses Keystone authentication =======================================================================

:Date: July 23, 2026 :CVE: CVE-2026-66139

Affects ~~~~~~~ - Zaqar: >=12.0.0 <20.1.1, ==21.0.0, ==22.0.0

Description ~~~~~~~~~~~ Errata ~~~~~~ Patches ~~~~~~~ - https://review.opendev.org/998411 (2025.1/epoxy) - https://review.opendev.org/998410 (2025.2/flamingo) - https://review.opendev.org/998400 (2026.1/gazpacho) - https://review.opendev.org/998272 (2026.2/hibiscus (development))

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

Notes ~~~~~ - https://review.opendev.org/998223 proposes removing the EXTRA-SPEC feature entirely as a follow-up hardening measure.

OSSA History ~~~~~~~~~~~~ - 2026-07-24 - Errata 1 - 2026-07-23 - Original Version

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

On 7/23/26 12:45 PM, Goutham Pacha Ravi wrote: ======================================================================= OSSA-2026-029: Zaqar EXTRA-SPEC header bypasses Keystone authentication =======================================================================

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

Affects ~~~~~~~ - Zaqar: >=12.0.0 <20.1.1, ==21.0.0, ==22.0.0

Description ~~~~~~~~~~~ Chen YuXiang from the Institute of Computing Technology, Chinese Academy of Sciences reported that the Zaqar messaging service bypasses Keystone authentication when an EXTRA-SPEC header is present in the request. An unauthenticated attacker who knows a project UUID can read, enumerate, create, and delete that project's queues without a Keystone token. The EXTRA-SPEC header was intended to support an alternative authentication mechanism, but the backend validation was never implemented, resulting in a complete authentication bypass. All deployments running Zaqar 12.0.0 or later are affected.

Patches ~~~~~~~ - https://review.opendev.org/998272 (2026.2/hibiscus (development)) - https://review.opendev.org/998400 (2026.1/gazpacho) - https://review.opendev.org/998410 (2025.2/flamingo) - https://review.opendev.org/998411 (2025.1/epoxy)

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

Notes ~~~~~ - A CVE assignment is pending from MITRE. This advisory will be updated   when the CVE is assigned. - https://review.opendev.org/998223 proposes removing the EXTRA-SPEC   feature entirely as a follow-up hardening measure.

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

In OpenStack Ironic Python Agent through 11.6.0, a project-scoped user with the manager role can achieve arbitrary code execution on a running Ironic-Python-Agent via a maliciously constructed configuration, because the value of ntpserver is passed to a shell.