One post tagged with "cve"

Prefix​

This advisory was drafted a few days ago, before the issue was public. As the issue turned out to only affect very specific configurations (which are not used in any standard SCS setting), we did not publish it with the urgency that we normally apply to protect our partners in time for a vulnerability becoming public.

Instead, we have taken the time to sort out the publication place in the the new Docs blog space, as described by the previous blog post.

The vulnerability​

Keystone is the central Identity and Access Management component in OpenStack. Whenever you talk to an OpenStack service, you authenticate to keystone via one of the supported methods. In return, keystone will issue a token that entitles you to have certain privileges when talking to the individual services.

One of the supported ways to authenticate is to use oauth2 tokens. When keystonemiddleware investigates these tokens it adds headers that indicate privileges associated with the account.

Unfortunately, keystonemiddleware does not clear headers when receiving oauth2 tokens, so an authenticated user can send oauth2 tokens with headers that actually indicate admin privileges and can trick services into assuming elevated privileges. The issue was introduced with keystonemiddleware 10.5.0 when support for external_oauth2_tokens was added.

The vulnerability has been assigned CVE-2026-22797.

The issue was reported by Grzegorz Grasza of RedHat.

Impact on OpenStack deployments​

When keystone is configured to accept oauth2 tokens for authentication, anyone able to produce and send any valid tokens may inject headers to impersonate other users or assume additional roles up to and including admin privileges. Admin privileges allow unrestricted access via the API and are only meant to be used by the cloud operators.

To abuse this vulnerability, the attacker must be an authenticated user of the platform. In addition, the platform must be configured to accept oauth2 tokens, which is not a supported configuration in yaook nor a simple change versus the default configuration is OSISM.

To make services accept oauth2 tokens, their config would need to be changed via paste.ini

[pipeline:main]
pipeline = ext_oauth2_token

[filter:ext_oauth2_token]
paste.filter_factory = keystonemiddleware.external_oauth2_token:filter_factory

in order to be affected. This is not the case in any default configurations and also not when using the OIDC federation with keycloak that is documented for SCS.

Providers are advised to investigate whether they have done changes to enable oauth2 tokens via keystonemiddleware as depicted above and assume that they are affected in that case.

Embargo​

The issue has been reported to the OpenStack Vulnerability Management Team in private. The reporters and upstream developers have worked together to address the issue with fixes and an embargo date has been set to Thursday, 2026-01-15, 15:00 UTC (16:00 CET). At this point in time, the patches get merged and the OpenStack Security Advisory (OSSA-2026-001) is published. The issue is tracked in OpenStack issue #2219018, which should become publically accessible after the lift of the embargo and the publication of this advisory.

Under the used responsible disclosure approach, the information was shared with a select group of trustable users of OpenStack, so they can prepare updates and protect their infrastructure at the time this issue becomes public.

Mitigation and Fixes​

The fix is straightforward and consists of clearing headers and explicitly unsetting the critical headers. For affected setups, it is recommended to update the keystone services immediately.

For clouds that can not update keystone directly, the dangerous headers could be filtered out by a reverse proxy or similar network infrastructure in front of the openstack API services or the oauth2 tokens could be temporarily disabled by reverting back to the standard

[filter:authtoken]
paste.filter_factory = keystonemiddleware.auth_token:filter_factory

Links to specific information from related OpenStack distributions​

• ALASCA has issued an advisory for yaook basically stating that it's not really possible to use yaook in a way that it would be affected.
• OSISM has published an advisary for OSISM with more details how to get a fixed keystone container deployed in case you have manually enabled such oauth2 tokens.

Thanks​

The authors would like to thank Grzegorz Grasza, Thomas Goirand (zigo), Jay Faulkner, David Wilde, Artem Goncharov and Jeremy Stanley for their work on this issue.

Sovereign Cloud Stack Security Contact​

SCS security contact is security@scs.community, as published on https://scs.community/.well-known/security.txt.

Version history​

• Initial Draft, v0.1, 2026-01-13, 22:30 CET.
• Release, v1.0, 2026-01-20, 08:30 CET.
• Release to SCS docs blog, v1.1, 2026-01-23, 10:30 CET.