OpenStack Keystone Flaws Expose Multiple Paths to Cloud Privilege Escalation

The recent Keystone advisory is unusual because the vulnerabilities are scattered across several features but keep affecting the same class of security controls. Application credentials, trusts, RBAC enforcement, project ownership validation, token expiration. Different code paths. Similar failures.

Most require authentication already. The concern is what happens after access exists. Several of the disclosed vulnerabilities affect how Keystone validates identity, ownership, delegation, and authorization. For environments running OpenStack, that puts the focus on privilege expansion rather than initial compromise.

What Is OpenStack Keystone?

Most OpenStack services do not evaluate identity independently. A user authenticates to Keystone, receives a token, and presents that token to other services. Nova uses Keystone identities when processing compute requests. Neutron relies on the Keystone project and role information when handling network operations. Horizon uses Keystone during authentication and authorization workflows. Similar trust relationships exist throughout the platform.

Keystone also manages application credentials, trusts, federation, project membership, and role assignments. Those functions appear repeatedly throughout the advisory because they are the mechanisms responsible for determining who an identity represents and what actions that identity can perform.

That position gives Keystone an unusual amount of influence over the OpenStack security posture. A bug in Nova typically affects compute operations. A bug in Keystone can affect how identities, permissions, projects, and delegated access are interpreted across multiple services at the same time. The vulnerabilities disclosed in this advisory target several of those mechanisms directly.

Do These Attacks Require Authentication?

In most cases, yes. The advisory does not describe a collection of unauthenticated remote code execution vulnerabilities. Attackers generally need some form of existing access before these cloud security vulnerabilities become relevant.

These vulnerabilities start becoming relevant once an identity already exists inside Keystone. That might be a service account used by automation, an application credential tied to a deployment pipeline, or a federated account brought in through an external identity provider. None of those identities necessarily begin with administrative access. The interesting part is what happens after authentication succeeds. Several of the disclosed flaws affect the checks Keystone performs when validating ownership, evaluating permissions, creating delegated access, or issuing new credentials. 

Those identities often start with limited permissions. The next challenge is finding a way to extend access, bypass restrictions, or operate outside the boundaries originally assigned to the account. Several of the Keystone vulnerabilities affect exactly those controls.

Why These Vulnerabilities Are Related

At first glance, the advisory reads like a collection of unrelated implementation bugs. One issue affects application credentials. Another involves trust relationships. Others target OpenStack RBAC, policy enforcement, project ownership validation, LDAP integration, or token handling. The code paths are different, but the failures keep landing in the same place.

Keystone is responsible for validating identity, ownership, authorization, delegation, and access scope. The disclosed vulnerabilities challenge one or more of those decisions. That shared theme is what makes the advisory interesting. Rather than exposing a single weakness, the bugs reveal multiple ways identity and authorization controls can become unreliable under specific conditions.

How the Vulnerabilities Could Be Exploited

Looking at the vulnerabilities through attack scenarios provides a clearer picture than reviewing each CVE in isolation.

Impersonating Another User (CVE-2026-42998)

This issue involved application credential authentication. Keystone failed to verify that the user supplied during authentication actually owned the application credential being presented. Under normal conditions, an application credential should remain tied to the identity that created it. Ownership is part of the trust decision. The vulnerability weakened that relationship. The immediate concern is not simply access; activity can become associated with the wrong user. Audit trails become harder to trust, and administrative actions may appear to originate from an account that never performed them.

Combining Trust Relationships and Privilege Escalation (CVE-2026-43000)

Trust relationships exist to support delegated access. A user authorizes another identity or service to act on their behalf within defined limits. The trust functionality is not unusual. Large OpenStack deployments depend on it for delegated access. What stands out here is how it interacts with the impersonation flaw. Once Keystone accepts the wrong identity, the trust system starts operating on that decision. The result is not a single authorization failure. New trust relationships can be created with privileges the original account never possessed.

Weakening RBAC Enforcement (CVE-2026-42999)

OpenStack RBAC is one of the primary mechanisms OpenStack uses to separate users, operators, auditors, service accounts, and administrators. The vulnerability involved Keystone incorporating untrusted JSON request data into policy evaluation decisions. Authorization systems depend on trusted inputs. Once policy evaluation begins consuming attacker-controlled attributes, permission decisions become harder to predict and harder to trust.

Crossing Project Boundaries (CVE-2026-43001)

Project isolation sits at the center of OpenStack's multi-tenant model. Researchers found that Keystone did not correctly validate project ownership during EC2 credential creation. Under certain conditions, users could create credentials associated with projects they did not own. Organizations depend on project boundaries to separate departments, customers, workloads, and environments. When credential ownership and project ownership become disconnected, those boundaries become less reliable.

Access That Refuses to Expire (CVE-2026-44394)

Token expiration is intended to limit how long compromised access remains useful. The advisory describes a situation where federated token rescoping did not preserve original expiration restrictions. A user could repeatedly obtain newly scoped tokens with fresh lifetimes. During incident response, token expiration often serves as a containment mechanism.

Additional Keystone Vulnerabilities

• Restricted Application Credentials (CVE-2026-33551): This vulnerability allowed restricted credentials to create EC2 credentials despite intended permission boundaries.
• LDAP Account State Validation (CVE-2026-40683): Researchers found conditions where Keystone improperly handled LDAP user-enabled status values, creating a gap between how an account appears in the directory and how Keystone interprets it.

What OpenStack Administrators Should Do

Applying vendor patches should be the immediate priority. Administrators should also review how application credentials are used, examine existing trust relationships, validate RBAC assignments, and review federated identity deployments. Historical activity deserves attention as well. Because these vulnerabilities involve privilege escalation, successful exploitation may look like legitimate user activity.

Keystone logs are the most valuable starting point for auditing:

• Application credential creation activity
• Unexpected EC2 credential generation
• Cross-project credential creation attempts
• New trust relationship creation
• Role assignment changes
• Token rescoping activity

Conclusion

The Keystone advisory is best understood as a collection of failures affecting identity and authorization controls. Keystone is making decisions about identity and authority that other OpenStack services rely on without question. For organizations operating Linux-based OpenStack environments, that makes Keystone one of the highest-value services to patch and review. When trust decisions fail at the identity layer, the effects rarely stay confined to the identity service itself.

Want more Linux security news, vulnerability analysis, and software supply chain updates? Subscribe to the LinuxSecurity Newsletter and get the latest threats, advisories, and expert insights delivered directly to your inbox.

Related Reading

• Linux Privilege Escalation Patterns and Mitigation Strategies
• Privilege Escalation Risks: Controls for Linux Security
• Securing Linux Cloud Workloads: Key Practices for Safety