YAOOK Security Advisory for keystone cve-2026-pending OSSA-2026-037

What are OSSA-2026-037 and how do they affect YAOOK?

Grzegorz Grasza (Red Hat) and Tim Shephard (roiai.ca) independently identified that OpenStack Keystone does not consistently enforce scope restrictions on tokens obtained via delegated authentication methods (ec2credential, application credential, OAuth1 access tokens). The underlying issue is the same: delegated tokens can perform operations or access projects beyond their intended scope. Two separate CVEs have been requested for distinct attack vectors that share this root cause.

Delegation bypass in trust, OAuth 1 and application credential operations (CVE-2026-pending, LP#2153453):
Tokens obtained via EC2 credential authentication can create new application credentials and authorise OAuth1 request tokens, thereby establishing new delegations that persist independently of the original credential and survive its revocation. Both EC2 and OAuth1 tokens can create trusts that delegate roles beyond the scope of the requesting token, because trust role validation checks the trustor’s full role assignments rather than the token’s scoped roles.

Token reauthentication escape (CVE-2026-pending, LP#2158538):
Tokens obtained via application credential or EC2 credential authentication can escape their intended project scope through token-method reauthentication. An application credential token scoped to a single project can be exchanged via a POST request to /v3/auth/tokens without an explicit scope, causing Keystone to issue a new token scoped to the owner’s default project. For EC2-derived tokens, the bypass is more widespread: as they do not carry any delegation markers, they can be rescoped to any project where the underlying user has role assignments.

Is my cluster vulnerable?

The following images are vulnerable:
  • Keystone images prior to version 3.0.94
  • yaook release prior to 3.4.0
If this image is used in your cluster for the Keystone deployment, the cluster is vulnerable.
 
The fixed image has been built in a private pipeline which has been published alongside this advisory to prove the image provenance.

Upgrading

A new stable release will be published according to the release cycle and hotfix releases will be produced starting now. You can upgrade to that release simply by updating your operators.
 
However, we recommend adding a YAOOK_OP_VERSIONS_OVERRIDE variable to your Keystone operator container to pull the image before the YAOOK comprehensive release is ready.
 
The best way to do this is to set the following in the values.yaml of your keystone-operator (make sure to merge this correctly with an existing values.yaml, if you have that).
operator:
    extraEnv:
    - name: YAOOK_OP_VERSIONS_OVERRIDE
    value: |
 {
 "registry.yaook.cloud/yaook/keystone-2024.1": "registry.yaook.cloud/yaook/keystone-2024.1:3.0.94",
 "registry.yaook.cloud/yaook/keystone-2024.2": "registry.yaook.cloud/yaook/keystone-2024.2:3.0.94",
 "registry.yaook.cloud/yaook/keystone-2025.1": "registry.yaook.cloud/yaook/keystone-2025.1:3.0.94",
            "registry.yaook.cloud/yaook/keystone-2025.2": "registry.yaook.cloud/yaook/keystone-2025.2:3.0.94",
            "registry.yaook.cloud/yaook/keystone-2026.1": "registry.yaook.cloud/yaook/keystone-2026.1:3.0.94"
 }
If you are not using Helm, you can add the environment variable to the env section of your keystone-operator's Deployment's pod template.
de_DE_formal
de_DE_formal