Total
44 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-33551 | 1 Openstack | 1 Keystone | 2026-06-05 | N/A | 3.5 LOW |
| 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. | |||||
| CVE-2026-43001 | 1 Openstack | 1 Keystone | 2026-06-02 | N/A | 7.9 HIGH |
| 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. | |||||
| CVE-2026-42998 | 1 Openstack | 1 Keystone | 2026-06-02 | N/A | 6.0 MEDIUM |
| 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. | |||||
| CVE-2026-42999 | 1 Openstack | 1 Keystone | 2026-06-02 | N/A | 6.0 MEDIUM |
| 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). | |||||
| CVE-2026-43000 | 1 Openstack | 1 Keystone | 2026-06-02 | N/A | 6.0 MEDIUM |
| 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. | |||||
| CVE-2026-44394 | 1 Openstack | 1 Keystone | 2026-06-02 | N/A | 6.0 MEDIUM |
| 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. | |||||
| CVE-2014-3520 | 1 Openstack | 1 Keystone | 2026-05-06 | 6.5 MEDIUM | N/A |
| 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. | |||||
| CVE-2013-2014 | 2 Fedoraproject, Openstack | 2 Fedora, Keystone | 2026-05-06 | 5.0 MEDIUM | N/A |
| OpenStack Identity (Keystone) before 2013.1 allows remote attackers to cause a denial of service (memory consumption and crash) via multiple long requests. | |||||
| CVE-2015-7546 | 2 Openstack, Oracle | 3 Keystone, Keystonemiddleware, Solaris | 2026-05-06 | 6.0 MEDIUM | 7.5 HIGH |
| 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. | |||||
| CVE-2014-2237 | 1 Openstack | 1 Keystone | 2026-05-06 | 5.0 MEDIUM | N/A |
| The memcache token backend in OpenStack Identity (Keystone) 2013.1 through 2.013.1.4, 2013.2 through 2013.2.2, and icehouse before icehouse-3, when issuing a trust token with impersonation enabled, does not include this token in the trustee's token-index-list, which prevents the token from being invalidated by bulk token revocation and allows the trustee to bypass intended access restrictions. | |||||
| CVE-2015-3646 | 2 Openstack, Oracle | 2 Keystone, Solaris | 2026-05-06 | 4.0 MEDIUM | N/A |
| 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. | |||||
| CVE-2014-2828 | 1 Openstack | 1 Keystone | 2026-05-06 | 7.8 HIGH | N/A |
| The V3 API in OpenStack Identity (Keystone) 2013.1 before 2013.2.4 and icehouse before icehouse-rc2 allows remote attackers to cause a denial of service (CPU consumption) via a large number of the same authentication method in a request, aka "authentication chaining." | |||||
| CVE-2014-0204 | 1 Openstack | 1 Keystone | 2026-05-06 | 6.5 MEDIUM | N/A |
| 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. | |||||
| CVE-2014-3476 | 2 Openstack, Suse | 2 Keystone, Cloud | 2026-05-06 | 6.0 MEDIUM | N/A |
| 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. | |||||
| CVE-2014-3621 | 3 Canonical, Openstack, Redhat | 4 Ubuntu Linux, Keystone, Enterprise Linux and 1 more | 2026-05-06 | 4.0 MEDIUM | N/A |
| 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. | |||||
| CVE-2014-5252 | 2 Canonical, Openstack | 2 Ubuntu Linux, Keystone | 2026-05-06 | 4.9 MEDIUM | N/A |
| The V3 API in OpenStack Identity (Keystone) 2014.1.x before 2014.1.2.1 and Juno before Juno-3 updates the issued_at value for UUID v2 tokens, which allows remote authenticated users to bypass the token expiration and retain access via a verification (1) GET or (2) HEAD request to v3/auth/tokens/. | |||||
| CVE-2014-5253 | 2 Canonical, Openstack | 2 Ubuntu Linux, Keystone | 2026-05-06 | 4.9 MEDIUM | N/A |
| OpenStack Identity (Keystone) 2014.1.x before 2014.1.2.1 and Juno before Juno-3 does not properly revoke tokens when a domain is invalidated, which allows remote authenticated users to retain access via a domain-scoped token for that domain. | |||||
| CVE-2014-5251 | 2 Canonical, Openstack | 2 Ubuntu Linux, Keystone | 2026-05-06 | 4.9 MEDIUM | N/A |
| The MySQL token driver in OpenStack Identity (Keystone) 2014.1.x before 2014.1.2.1 and Juno before Juno-3 stores timestamps with the incorrect precision, which causes the expiration comparison for tokens to fail and allows remote authenticated users to retain access via an expired token. | |||||
| CVE-2012-5483 | 1 Openstack | 1 Keystone | 2026-04-29 | 2.1 LOW | N/A |
| tools/sample_data.sh in OpenStack Keystone 2012.1.3, when access to Amazon Elastic Compute Cloud (Amazon EC2) is configured, uses world-readable permissions for /etc/keystone/ec2rc, which allows local users to obtain access to EC2 services by reading administrative access and secret values from this file. | |||||
| CVE-2012-3426 | 1 Openstack | 3 Essex, Horizon, Keystone | 2026-04-29 | 4.9 MEDIUM | N/A |
| OpenStack Keystone before 2012.1.1, as used in OpenStack Folsom before Folsom-1 and OpenStack Essex, does not properly implement token expiration, which allows remote authenticated users to bypass intended authorization restrictions by (1) creating new tokens through token chaining, (2) leveraging possession of a token for a disabled user account, or (3) leveraging possession of a token for an account with a changed password. | |||||