Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
42 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 29.0.2, 28.0.2 or 27.0.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 29.0.2, 28.0.2 or 27.0.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 29.0.2, 28.0.2 or 27.0.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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).
Recommended action: Upgrade to 29.0.2, 28.0.2 or 27.0.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 28.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 26.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 28.0.0, 27.0.0 or 26.0.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 19.0.1, 18.0.1, 17.0.1 or 16.0.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 16.0.0 or 15.0.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 16.0.1 or 15.0.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 16.0.1 or 15.0.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenStack Keystone 15.0.0 and 16.0.0 is affected by Data Leakage in the 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 (for example) leak sign-on information for Time-based One Time Passwords (TOTP). Deployments with enforcescope set to false are affected. (There will be a slight performance impact for the list credentials API once this issue is fixed.)
Recommended action: Upgrade to 16.0.1 or 15.0.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 8.0.0a0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenStack Keystone, as used in OpenStack Folsom before folsom-rc1 and OpenStack Essex (2012.1), allows remote attackers to add an arbitrary user to an arbitrary tenant via a request to update the user's default tenant to the administrative API. NOTE: this identifier was originally incorrectly assigned to an open redirect issue, but the correct identifier for that issue is CVE-2012-3540.
Recommended action: Upgrade to 2012.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The (1) mamcache and (2) KVS token backends in OpenStack Identity (Keystone) Folsom 2012.2.x and Grizzly before 2013.1.4 do not properly compare the PKI token revocation list with PKI tokens, which allow remote attackers to bypass intended access restrictions via a revoked PKI token.
Recommended action: Upgrade to 2013.1.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenStack Keystone Folsom (2012.2) does not properly perform revocation checks for Keystone PKI tokens when done through a server, which allows remote attackers to bypass intended access restrictions via a revoked PKI token.
Recommended action: Upgrade to 2012.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The LDAP backend in OpenStack Identity (Keystone) Grizzly and Havana, when removing a role on a tenant for a user who does not have that role, adds the role to the user, which allows local users to gain privileges.
Recommended action: Upgrade to 8.0.0a0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenStack Identity (Keystone) Grizzly 2013.1.1, when DEBUG mode logging is enabled, logs the (1) admintoken and (2) LDAP password in plaintext, which allows local users to obtain sensitive by reading the log file.
Recommended action: Upgrade to 8.0.0a0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The V3 API in OpenStack Identity (Keystone) 2014.1.x before 2014.1.2.1 and Juno before Juno-3 updates the issuedat 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/.
Recommended action: Upgrade to 8.0.0a0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 8.0.0a0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 8.0.0a0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 8.0.0a0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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."
Recommended action: Upgrade to 8.0.0a0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Fernet Token Provider in OpenStack Identity (Keystone) 9.0.x before 9.0.1 (mitaka) allows remote authenticated users to prevent revocation of a chain of tokens and bypass intended access restrictions by rescoping a token.
Recommended action: Upgrade to 9.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenStack Keystone before 2012.1.3 does not invalidate existing tokens when granting or revoking roles, which allows remote authenticated users to retain the privileges of the revoked roles.
Recommended action: Upgrade to 2012.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.