Keystone

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 handle_scoped_token() function in the mapped authentication plugin returns response data without an expires_at 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.

Published: 2026-05-28T00:00:00.000Z
Updated: 2026-05-28T19:43:05.616Z

An issue was discovered in OpenStack Keystone before 29.0.2. POST /v3/credentials did not validate that the caller-supplied project_id 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 app_cred_id, enabling cross-project lateral movement within the credential owner's role footprint.

Published: 2026-05-01T00:00:00.000Z
Updated: 2026-05-28T18:38:35.182Z

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.

Published: 2026-05-28T00:00:00.000Z
Updated: 2026-05-28T19:41:55.135Z

An issue was discovered in OpenStack Keystone before 29.0.2. The Keystone RBAC policy enforcer in enforce_call unconditionally merges the raw JSON request body into the policy enforcement dictionary via policy_dict.update(json_input.copy()), overwriting trusted target data that was previously set from database lookups. Because flask.request.get_json 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., user_id, project_id) 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).

Published: 2026-05-28T00:00:00.000Z
Updated: 2026-05-28T19:42:27.483Z

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.

Published: 2026-05-28T00:00:00.000Z
Updated: 2026-05-28T19:38:42.097Z

In OpenStack Keystone before 28.0.1, the LDAP identity backend does not convert the user enabled attribute to a boolean when the user_enabled_invert configuration option is False (the default). The _ldap_res_to_model method in the UserApi class only performed string-to-boolean conversion when user_enabled_invert 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 user_enabled_invert=True or user_enabled_emulation are affected.

Published: 2026-04-14T20:05:03.274Z
Updated: 2026-04-14T20:14:44.539Z

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.

Published: 2026-04-10T00:00:00.000Z
Updated: 2026-04-10T13:50:43.389Z

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.

Published: 2025-11-17T00:00:00.000Z
Updated: 2025-11-17T23:04:04.827Z

A flaw was found in openstack-keystone. Only the first 72 characters of an application secret are verified allowing attackers bypass some password complexity which administrators may be counting on. The highest threat from this vulnerability is to data confidentiality and integrity.

Published: 2022-08-26T15:25:41.000Z
Updated: 2025-02-13T16:28:24.713Z

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 security_compliance.lockout_failure_attempts are affected.

Published: 2021-08-06T00:00:00.000Z
Updated: 2024-08-04T01:37:16.259Z

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.

Published: 2020-05-06T23:42:42.000Z
Updated: 2024-08-04T12:04:22.870Z

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.

Published: 2020-05-06T23:43:01.000Z
Updated: 2024-08-04T12:04:22.558Z

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.

Published: 2020-05-06T23:43:10.000Z
Updated: 2024-08-04T12:04:22.540Z

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.

Published: 2020-05-06T23:43:20.000Z
Updated: 2024-08-04T12:04:22.561Z

OpenStack Keystone through 14.0.1 has a user enumeration vulnerability because invalid usernames have much faster responses than valid ones for a POST /v3/auth/tokens request. NOTE: the vendor's position is that this is a hardening opportunity, and not necessarily an issue that should have an OpenStack Security Advisory

Published: 2018-12-17T06:00:00.000Z
Updated: 2024-11-14T20:09:49.052Z

In the Federation component of OpenStack Keystone before 11.0.4, 12.0.0, and 13.0.0, an authenticated "GET /v3/OS-FEDERATION/projects" request may bypass intended access restrictions on listing projects. An authenticated user may discover projects they have no authority to access, leaking all projects in the deployment and their attributes. Only Keystone with the /v3/OS-FEDERATION endpoint enabled via policy.json is affected.

Published: 2018-07-31T14:00:00.000Z
Updated: 2024-08-05T09:29:51.575Z

The identity service in OpenStack Identity (Keystone) before 2015.1.3 (Kilo) and 8.0.x before 8.0.2 (Liberty) and keystonemiddleware (formerly python-keystoneclient) before 1.5.4 (Kilo) and Liberty before 2.3.3 does not properly invalidate authorization tokens when using the PKI or PKIZ token providers, which allows remote authenticated users to bypass intended access restrictions and gain access to cloud resources by manipulating byte fields within a revoked token.

Published: 2016-02-03T15:00:00.000Z
Updated: 2024-08-06T07:51:28.547Z

OpenStack Identity (Keystone) before 2014.1.5 and 2014.2.x before 2014.2.4 logs the backend_argument configuration option content, which allows remote authenticated users to obtain passwords and other sensitive backend information by reading the Keystone logs.

Published: 2015-05-12T19:00:00.000Z
Updated: 2024-08-06T05:47:58.237Z

The catalog url replacement in OpenStack Identity (Keystone) before 2013.2.3 and 2014.1 before 2014.1.2.1 allows remote authenticated users to read sensitive configuration options via a crafted endpoint, as demonstrated by "$(admin_token)" in the publicurl endpoint field.

Published: 2014-10-02T14:00:00.000Z
Updated: 2024-08-06T10:50:17.826Z

OpenStack Identity (Keystone) before 2013.2.4, 2014.x before 2014.1.2, and Juno before Juno-2 allows remote authenticated trustees to gain access to an unauthorized project for which the trustor has certain roles via the project ID in a V2 API trust token request.

Published: 2014-10-26T20:00:00.000Z
Updated: 2024-08-06T10:50:16.883Z

OpenStack Identity (Keystone) before 2013.2.4, 2014.1 before 2014.1.2, and Juno before Juno-2 does not properly handle chained delegation, which allows remote authenticated users to gain privileges by leveraging a (1) trust or (2) OAuth token with impersonation enabled to create a new token with additional roles.

Published: 2014-06-17T14:00:00.000Z
Updated: 2024-08-06T10:43:06.436Z

OpenStack Identity (Keystone) before 2014.1.1 does not properly handle when a role is assigned to a group that has the same ID as a user, which allows remote authenticated users to gain privileges that are assigned to a group with the same ID.

Published: 2014-11-03T23:00:00.000Z
Updated: 2024-08-06T09:05:39.227Z

The ec2tokens API in OpenStack Identity (Keystone) before Havana 2013.2.1 and Icehouse before icehouse-2 does not return a trust-scoped token when one is received, which allows remote trust users to gain privileges by generating EC2 credentials from a trust-scoped token and using them in an ec2tokens API request.

Published: 2013-12-14T17:00:00.000Z
Updated: 2024-08-06T17:39:01.159Z

OpenStack Identity (Keystone) Folsom, Grizzly 2013.1.3 and earlier, and Havana before havana-3 does not properly revoke user tokens when a tenant is disabled, which allows remote authenticated users to retain access via the token.

Published: 2013-09-30T20:00:00.000Z
Updated: 2024-08-06T16:38:01.462Z

HTTPSConnections in OpenStack Keystone 2013, OpenStack Compute 2013.1, and possibly other OpenStack components, fail to validate server-side SSL certificates.

Published: 2019-11-01T18:38:01.000Z
Updated: 2024-08-06T15:27:41.145Z

OpenStack Keystone Folsom, Grizzly before 2013.1.3, and Havana, when using LDAP with Anonymous binding, allows remote attackers to bypass authentication via an empty password.

Published: 2013-08-20T22:00:00.000Z
Updated: 2024-08-06T15:27:40.992Z

OpenStack Identity (Keystone) before 2013.1 allows remote attackers to cause a denial of service (memory consumption and crash) via multiple long requests.

Published: 2014-06-02T15:00:00.000Z
Updated: 2024-08-06T15:20:37.486Z

OpenStack Keystone Grizzly before 2013.1, Folsom 2012.1.3 and earlier, and Essex does not properly check if the (1) user, (2) tenant, or (3) domain is enabled when using EC2-style authentication, which allows context-dependent attackers to bypass access restrictions.

Published: 2013-04-12T22:00:00.000Z
Updated: 2024-08-06T14:18:09.876Z

A flaw was found in OpenStack Keystone. A remote attacker could exploit this vulnerability by sending a large HTTP request, specifically by providing a long tenant name when requesting a token. This could lead to a denial of service, consuming excessive CPU and memory resources on the affected system.

Published: 2013-04-12T22:00:00.000Z
Updated: 2026-04-07T06:55:17.958Z

OpenStack Keystone Essex 2012.1.3 and earlier, Folsom 2012.2.3 and earlier, and Grizzly grizzly-2 and earlier allows remote attackers to cause a denial of service (disk consumption) via many invalid token requests that trigger excessive generation of log entries.

Published: 2013-02-24T19:00:00.000Z
Updated: 2024-08-06T14:18:09.570Z

OpenStack Keystone Essex before 2012.1.2 and Folsom before folsom-3 does not properly handle authorization tokens for disabled tenants, which allows remote authenticated users to access the tenant's resources by requesting a token for the tenant.

Published: 2012-10-09T15:00:00.000Z
Updated: 2024-08-06T20:35:09.684Z

The (1) OS-KSADM/services and (2) tenant APIs in OpenStack Keystone Essex before 2012.1.2 and Folsom before folsom-2 do not properly validate X-Auth-Token, which allow remote attackers to read the roles for an arbitrary user or get, create, or delete arbitrary services.

Published: 2012-10-09T15:00:00.000Z
Updated: 2024-08-06T20:35:09.608Z