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

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

An issue was discovered in OpenStack Keystone before 29.0.2. The Keystone RBAC policy enforcer in enforcecall unconditionally merges the raw JSON request body into the policy enforcement dictionary via policydict.update(jsoninput.copy()), overwriting trusted target data that was previously set from database lookups. Because flask.request.getjson is called with force=True, this works regardless of Content-Type or HTTP method. Any authenticated user can inject arbitrary policy target attributes (e.g., userid, projectid) into the request body to bypass RBAC checks and perform unauthorized operations on resources belonging to other users or projects. This was introduced in commit 5ea59f52 (Rocky/14.0.0).

An issue was discovered in OpenStack Keystone before 29.0.2. When combined with an application credential impersonation vulnerability, an attacker with the member role on a project can escalate to admin by chaining unrestricted application credentials with Keystone trusts. The impersonated token carries the victim's identity, which passes the trustor validation check. Keystone then validates the delegated roles against the victim's actual role assignments in the database, not the roles on the requesting token. This allows the attacker to create a trust delegating the victim's admin role to themselves. The trust persists independently, and additional trusts and application credentials can be created to maintain access. All actions are logged under the victim's identity.

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

:Date: May 28, 2026 :CVE: CVE-2026-42998, CVE-2026-42999, CVE-2026-43000, CVE-2026-43001, CVE-2026-44394

Affects ~~~~~~~ - Keystone: >=14.0.0 <27.0.2, >=28.0.0 <28.0.2, >=29.0.0 <29.0.2

Description ~~~~~~~~~~~ Patches ~~~~~~~ - https://review.opendev.org/990500 (2025.1/epoxy) - https://review.opendev.org/990501 (2025.1/epoxy) - https://review.opendev.org/990502 (2025.1/epoxy) - https://review.opendev.org/990503 (2025.1/epoxy) - https://review.opendev.org/990504 (2025.1/epoxy) - https://review.opendev.org/990495 (2025.2/flamingo) - https://review.opendev.org/990496 (2025.2/flamingo) - https://review.opendev.org/990497 (2025.2/flamingo) - https://review.opendev.org/990498 (2025.2/flamingo) - https://review.opendev.org/990499 (2025.2/flamingo) - https://review.opendev.org/990490 (2026.1/gazpacho) - https://review.opendev.org/990491 (2026.1/gazpacho) - https://review.opendev.org/990492 (2026.1/gazpacho) - https://review.opendev.org/990493 (2026.1/gazpacho) - https://review.opendev.org/990494 (2026.1/gazpacho) - https://review.opendev.org/990485 (2026.2/hibiscus) - https://review.opendev.org/990486 (2026.2/hibiscus) - https://review.opendev.org/990487 (2026.2/hibiscus) - https://review.opendev.org/990488 (2026.2/hibiscus) - https://review.opendev.org/990489 (2026.2/hibiscus)

Credits ~~~~~~~ - Boris Bobrov from SAP SE (CVE-2026-42998, CVE-2026-42999, CVE-2026-43000) - Tim Shepherd from roiai.ca (CVE-2026-43001) - Artem Goncharov from SysEleven GmbH

References ~~~~~~~~~~ - https://launchpad.net/bugs/2148398 - https://launchpad.net/bugs/2148477 - https://launchpad.net/bugs/2149775 - https://launchpad.net/bugs/2149789 - https://launchpad.net/bugs/2150089 - https://launchpad.net/bugs/2150379 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-42998 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-42999 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43000 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-43001 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-44394

Notes ~~~~~ - The fix for CVE-2026-42999 modifies the trust policy structure. Deployments with customized trust policies may experience issues with image upload and Heat service functionality until the custom policy is updated. - CVE-2026-44394 only affects deployments using SAML2 or OIDC federation.

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

An issue was discovered in OpenStack Keystone before 29.0.2. The Keystone RBAC policy enforcer in enforcecall unconditionally merges the raw JSON request body into the policy enforcement dictionary via policydict.update(jsoninput.copy()), overwriting trusted target data that was previously set from database lookups. Because flask.request.getjson is called with force=True, this works regardless of Content-Type or HTTP method. Any authenticated user can inject arbitrary policy target attributes (e.g., userid, projectid) into the request body to bypass RBAC checks and perform unauthorized operations on resources belonging to other users or projects. This was introduced in commit 5ea59f52 (Rocky/14.0.0).

An issue was discovered in OpenStack Keystone before 29.0.2. The Keystone application credential authentication plugin does not verify that the user supplied in the authentication request matches the owner of the application credential. An attacker can authenticate with their own application credential ID and secret while specifying a different user's name and domain in the request body. Keystone issues a token attributed to the victim user. The impersonated token is project-scoped and carries the intersection of the application credential's roles and the victim's actual roles on the project. This enables audit evasion, reading the victim's credentials, and acting as the victim within shared projects.

An issue was discovered in OpenStack Keystone before 29.0.2. When combined with an application credential impersonation vulnerability, an attacker with the member role on a project can escalate to admin by chaining unrestricted application credentials with Keystone trusts. The impersonated token carries the victim's identity, which passes the trustor validation check. Keystone then validates the delegated roles against the victim's actual role assignments in the database, not the roles on the requesting token. This allows the attacker to create a trust delegating the victim's admin role to themselves. The trust persists independently, and additional trusts and application credentials can be created to maintain access. All actions are logged under the victim's identity.

An issue was discovered in OpenStack Keystone before 29.0.2. The Keystone federated token rescoping mechanism does not propagate the original token's expiry to the newly issued token. When a federated user rescopes a token via POST /v3/auth/tokens, the handlescopedtoken() function in the mapped authentication plugin returns response data without an expiresat value. The token provider falls back to issuing a token with a fresh default TTL. By rescoping repeatedly before each token expires, a user can maintain access indefinitely, bypassing operator-configured token lifetime policies. This is a variant of CVE-2012-3426. Only deployments using federated identity (SAML2, OpenID Connect) 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.

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.

In OpenStack Keystone before 28.0.1, the LDAP identity backend does not convert the user enabled attribute to a boolean when the userenabledinvert configuration option is False (the default). The ldaprestomodel method in the UserApi class only performed string-to-boolean conversion when userenabledinvert was True. When False, the raw string value from LDAP (e.g., "FALSE") was used directly. Since non-empty strings are truthy in Python, users marked as disabled in LDAP were treated as enabled by Keystone, allowing them to authenticate and perform actions. All deployments using the LDAP identity backend without userenabledinvert=True or userenabledemulation are affected.

In OpenStack Keystone before 28.0.1, the LDAP identity backend does not convert the user enabled attribute to a boolean when the userenabledinvert configuration option is False (the default). The ldaprestomodel method in the UserApi class only performed string-to-boolean conversion when userenabledinvert was True. When False, the raw string value from LDAP (e.g., "FALSE") was used directly. Since non-empty strings are truthy in Python, users marked as disabled in LDAP were treated as enabled by Keystone, allowing them to authenticate and perform actions. All deployments using the LDAP identity backend without userenabledinvert=True or userenabledemulation are affected.

================================================================================== 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-005: Restricted application credentials can create EC2 credentials ============================================================================

:Date: April 07, 2026 :CVE: CVE-2026-33551

Affects ~~~~~~~ - Keystone: >=14.0.0 <26.1.1, ==27.0.0, ==28.0.0, ==29.0.0

Description ~~~~~~~~~~~ Patches ~~~~~~~ - https://review.opendev.org/983597 (2024.1/caracal) - https://review.opendev.org/983591 (2024.2/dalmatian) - https://review.opendev.org/983589 (2025.1/epoxy) - https://review.opendev.org/983588 (2025.2/flamingo) - https://review.opendev.org/983593 (2026.1/gazpacho) - https://review.opendev.org/983587 (2026.2/hibiscus)

Credits ~~~~~~~ - Maxence Bornecque from Orange Cyberdefense CERT Vulnerability Intelligence Watch Team (CVE-2026-33551)

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

Notes ~~~~~ - The unmaintained/2024.1 branch is unmaintained and will receive no new point releases, but a patch for it is provided as a courtesy.

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

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.

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.

A flaw was found in Keystone. There is a time lag (up to one hour in a default configuration) between when security policy says a token should be revoked from when it is actually revoked. This could allow a remote administrator to secretly maintain access for longer than expected.

OpenStack Keystone 10.x through 16.x before 16.0.2, 17.x before 17.0.1, 18.x before 18.0.1, and 19.x before 19.0.1 allows information disclosure during account locking (related to PCI DSS features). By guessing the name of an account and failing to authenticate multiple times, any unauthenticated actor could both confirm the account exists and obtain that account's corresponding UUID, which might be leveraged for other unrelated attacks. All deployments enabling securitycompliance.lockoutfailureattempts are affected.

An issue was discovered in OpenStack Keystone before 15.0.1, and 16.0.0. Any user authenticated within a limited scope (trust/oauth/application credential) can create an EC2 credential with an escalated permission, such as obtaining admin while the user is on a limited viewer role. This potentially allows a malicious user to act as the admin on a project another user has the admin role on, which can effectively grant that user global admin privileges.

An issue was discovered in OpenStack Keystone before 15.0.1, and 16.0.0. The list of roles provided for an OAuth1 access token is silently ignored. Thus, when an access token is used to request a keystone token, the keystone token contains every role assignment the creator had for the project. This results in the provided keystone token having more role assignments than the creator intended, possibly giving unintended escalated access.

An issue was discovered in OpenStack Keystone before 15.0.1, and 16.0.0. Any authenticated user can create an EC2 credential for themselves for a project that they have a specified role on, and then perform an update to the credential user and project, allowing them to masquerade as another user. This potentially allows a malicious user to act as the admin on a project another user has the admin role on, which can effectively grant that user global admin privileges.

An issue was discovered in OpenStack Keystone before 15.0.1, and 16.0.0. The EC2 API doesn't have a signature TTL check for AWS Signature V4. An attacker can sniff the Authorization header, and then use it to reissue an OpenStack token an unlimited number of times.

The keystone-json-assignment package in SUSE Openstack Cloud 8 before commit d7888c75505465490250c00cc0ef4bb1af662f9f every user listed in the /etc/keystone/user-project-map.json was assigned full "member" role access to every project. This allowed these users to access, modify, create and delete arbitrary resources, contrary to expectations.

A vulnerability was found in Keystone's list credentials API. Any user with a role on a project is able to list any credentials with the /v3/credentials API when enforcescope is false. Users with a role on a project are able to view any other users' credentials, which could leak sign-on information for Time-based One Time Passwords (TOTP) or othewise. Deployments running keystone with enforcescope set to false are affected. There will be a slight performance impact for the list credentials API once this issue is fixed. Affects: ==15.0.0, ==16.0.0