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.

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

: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

An issue was discovered in OpenStack ironic-python-agent 1.0.0 through 11.5.0. Ironic Python Agent (IPA) sometimes executes grub-install from within a chroot of the deployed partition image, leading to code execution in the case of a malicious image.

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.

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.

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.

An issue was discovered in OpenStack oslo.messaging 1.0.0 through 17.3.0. The oslo.messaging RabbitMQ driver does not perform TLS hostname verification when connecting to the message broker. When sslcafile is configured, the driver enables certificate chain validation but does not pass the expected broker hostname into the underlying TLS stack. Any certificate signed by the deployment CA is accepted regardless of hostname, allowing an attacker who can intercept control-plane traffic to impersonate the RabbitMQ broker and perform a man-in-the-middle attack on RPC and notification traffic. All OpenStack services using oslo.messaging with RabbitMQ over TLS 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-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

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

: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

An issue was discovered in OpenStack Nova before 30.2.2, 31 before 31.2.1, and 32 before 32.1.1. By writing a malicious QCOW header to a root or ephemeral disk and then triggering a resize, a user may convince Nova's Flat image backend to call qemu-img without a format restriction, resulting in an unsafe image resize operation that could destroy data on the host system. Only compute nodes using the Flat image backend (usually configured with usecowimages=False) are affected.

Unconstrained disk format handling vulnerability in OpenStack Nova when invoking the qemu-img utility. The flaw occurs because Nova does not strictly enforce the expected disk image format before calling qemu-img. An authenticated attacker can write a crafted QCOW2 header to a raw ephemeral or root disk. When Nova later performs operations such as instance resize, qemu-img interprets the disk as QCOW2 and overwrites arbitrary files on the compute host that Nova has write access to. This can be exploited without additional privileges or user interaction, allowing attackers to destroy other users’ data, corrupt Nova-managed files, or cause denial of service on the compute node.

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.

Glance through 0.8.5 contains an IP address spoofing vulnerability in the authentication handler that allows unauthenticated attackers to bypass brute-force lockout protections by supplying arbitrary values in the X-Forwarded-For request header when the server proxied option is enabled. Attackers can manipulate the leftmost value of the X-Forwarded-For header to make each login attempt appear to originate from a distinct IP address, preventing the per-IP failed-login counter from reaching the lockout threshold and enabling unlimited credential guessing against the authentication endpoint.

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

OpenStack Ironic before 35.0.1 allows ipmitool execution in a non-default configuration that has a console interface.

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

: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

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.

An issue was discovered in OpenStack Keystone 13 through 29. POST /v3/credentials did not validate that the caller-supplied projectid for an EC2-type credential matched the project of the authenticating application credential. This allowed an attacker holding an unrestricted application credential for project A to create an EC2 credential targeting project B; a subsequent /v3/ec2tokens exchange would then issue a Keystone token scoped to project B while still carrying the original appcredid, enabling cross-project lateral movement within the credential owner's role footprint.

OpenStack Glance before 29.1.1, 30.x before 30.1.1, and 31.0.0 is affected by Server-Side Request Forgery (SSRF). By use of HTTP redirects, an authenticated user can bypass URL validation checks and redirect to internal services. Only glance image import functionality is affected. In particular, the web-download and glance-download import methods are subject to this vulnerability, as is the optional (not enabled by default) ovfprocess image import plugin.

An issue was discovered in OpenStack Keystone 14 through 26 before 26.1.1, 27.0.0, 28.0.0, and 29.0.0. Restricted application credentials can create EC2 credentials. By using a restricted application credential to call the EC2 credential creation API, an authenticated user with only a reader role may obtain an EC2/S3 credential that carries the full set of the parent user's S3 permissions, effectively bypassing the role restrictions imposed on the application credential. Only deployments that use restricted application credentials in combination with the EC2/S3 compatibility API (swift3 / s3api) are affected.

Maxence Bornecque from Orange Cyberdefense CERT Vulnerability Intelligence Watch Team reported a vulnerability in Keystone's EC2 credential creation endpoint. By using a restricted application credential to call the EC2 credential creation API, an authenticated user with only a reader role may obtain an EC2/S3 credential that carries the full set of the parent user's S3 permissions, effectively bypassing the role restrictions imposed on the application credential. Only deployments that use restricted application credentials in combination with the EC2/S3 compatibility API (swift3 / s3api) are affected.

Server-Side Request Forgery (SSRF) vulnerability in the web-download import workflow of OpenStack Glance. The issue arises because validateimporturi() validates only the initial URI using string-based hostname comparison, and urllib.request.urlopen() automatically follows HTTP redirects without revalidating the redirect destination. Additionally, alternative IP encodings (decimal, hexadecimal, octal representations) are not normalized prior to blacklist checks, allowing encoded internal IP addresses (e.g., 0x7f000001 for 127.0.0.1) to bypass validation. An authenticated user can supply a crafted URI that either redirects to an internal resource or directly references an encoded internal IP address, resulting in unauthorized internal network access and potential sensitive data exfiltration.

An issue was discovered in OpenStack Keystone 13 through 29. POST /v3/credentials did not validate that the caller-supplied projectid for an EC2-type credential matched the project of the authenticating application credential. This allowed an attacker holding an unrestricted application credential for project A to create an EC2 credential targeting project B; a subsequent /v3/ec2tokens exchange would then issue a Keystone token scoped to project B while still carrying the original appcredid, enabling cross-project lateral movement within the credential owner's role footprint.

An issue was discovered in OpenStack oslo.messaging 1.0.0 through 17.3.0. The oslo.messaging RabbitMQ driver does not perform TLS hostname verification when connecting to the message broker. When sslcafile is configured, the driver enables certificate chain validation but does not pass the expected broker hostname into the underlying TLS stack. Any certificate signed by the deployment CA is accepted regardless of hostname, allowing an attacker who can intercept control-plane traffic to impersonate the RabbitMQ broker and perform a man-in-the-middle attack on RPC and notification traffic. All OpenStack services using oslo.messaging with RabbitMQ over TLS are affected.

OpenStack Keystone before 26.0.1, 27.0.0, and 28.0.0 allows a /v3/ec2tokens or /v3/s3tokens request with a valid AWS Signature to provide Keystone authorization.