The vulnerability​

OpenStack allows the creation of Application Credentials to give its bearer access to a project with the privileges of the user who created the AppCreds. Application Credentials can have a limited lifetime and can be revoked. They can also be restricted (which means that they can not be used to create additional application credentials) or can be assigned roles with lower privileges, limiting the privileges that the bearer has.

When AppCreds are used to create EC2 credentials, keystone failed to require unrestricted AppCreds and failed to require the member role, giving AppCreds that are restricted or that have limited roles the ability to create EC2 credentials with the full privileges of the user who created the AppCred.

This issue was reported by Maxence Bornecque from Orange Cyberdefense CERT Vulnerability Intelligence Watch Team and has been assigned CVE-2026-33551.

Impact on the SCS software ecosystem​

This issue affects OpenStack environments that allow the creation of EC2 style credentials, which is typically used for S3 access or EC2 compatibility. This is typically the case for SCS clouds, as S3 compatibility is a requirement.

While creating AppCreds with roles with lower privileges is not a very common use case, it is supported by OpenStack clouds and is actually a good practice to limit the privileges of running components or the delegated privileges for human bearers of the AppCred. The fact that EC2 credentials can be used to work around and regain the privileges of the user who created the original AppCred is a serious issue, as it breaks the principle of least privileges and may weaken or break security models for applications or delegated authorizations.

Note that this vulnerability does not allow to escalate privileges further than the original AppCred creator's privileges and does require the attacker to get access to the limited AppCred in the first place.

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 Tuesday, 2026-04-07, 15:00 UTC (17:00 CEST). At this point in time, the patches get merged and the OpenStack Security Advisory OSSA-2026-005 is published. The issue is tracked in OpenStack issue #2142138, 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 user data in time for the publication.

Mitigation and Fixes​

The temporary fix for this issue would be to disable the creation of EC2 credentials which however would prevent to enable new S3 access.

There are patches from the upstream OpenStack keystone developers available. They add a check in the EC2 credential creation path that requires the AppCred to be unrestricted and to have at least member access to the project.

The SCS ecosystem software providers provide fixed keystone images and installation instructions here as soon as the updated images are available:

• OSISM
• yaook

Thanks​

The author would like to thank Maxence Bornecque, Grzegorz Grasza, Douglas Mendizabal, Artem Goncharov, and Jeremy Stanley for reporting, fixing and coordinating this issue.

Sovereign Cloud Stack Security Contact​

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

Version history​

• Typo fixes and yaook link, v1.0, 2026-04-09, 10:30 CEST
• Initial draft, v0,9, 2026-04-08, 13:45 CEST

The vulnerability​

OpenStack supports a variety of image formats to ease migration from other virtualization platforms. The qemu-img tools are used to deal with these images. Unfortunately, OpenStack developers had to learn that qemu-img is not as robust as expected when dealing with untrusted images. This has lead to CVE-2022-47951 and CVE-2024-32498 and CVE-2024-40767 .

Analyzing all potentially vulnerable code paths, at least one had been overlooked by developers before: When resizing VMs in Nova to a flavor with a new root disk/ephemeral disk size, and Nova's flat image backend is in use, qemu-img is called on the backing image file without an explicit format specifier, opening up the possibility to overwrite files on the host system by writing a malicious QCOW header to a root or ephemeral disk.

This vulnerability has been assigned CVE-2026-24708.

Impact on the SCS software ecosystem​

By default, Nova uses cow images, i.e. use_cow_images in nova.conf defaults to True.

This value is not changed in either OSISM nor yaook, so neither of these implementations is affected by the vulnerability. Operators need to have made a deliberate effort to override this setting.

If this setting is set to False, authenticated users may write malicious QCOW2 or VMDK headers to the disk and then use the VM resize to overwrite files on the host with zeros, causing failure of the compute host.

The overwriting of arbitrary files with zeroes has been reproduced using QCOW headers; it may be possible to do more controlled damage (e.g. writing non-zeros) using more exotic features in e.g. the VMDK headers and this way cause more than a Denial-of-Service but gain privileges or exfiltrate data.

Operators that are using use_cow_images=False in their nova config are advised to apply the fixes urgently or change this setting temporarily.

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 Tuesday, 2026-02-17, 15:00 UTC (16:00 CET). At this point in time, the patches get merged and the OpenStack Security Advisory OSSA-2026-002 is published. The issue is tracked in OpenStack issue #2137507, 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 user data in time for the publication.

Mitigation and Fixes​

The temporary fix for this issue is to avoid use_cow_images=false in /etc/nova.conf. This will stop this issue from being triggered. Alternatively, full glance format-inspector protection should help against this.

There are patches from the upstream OpenStack developers available. They work by passing -f raw to qemu-img when a resize happens with raw images and -f qcow2 for QCOW2 images. Other images are disallowed for resizing.

The SCS ecosystem software providers will provide fixed nova-compute images and installation instructions here as soon as the updated images are available:

• yaook
• OSISM

Thanks​

The author would like to thank Dan Smith, Jay Faulkner, Sylvain Bauza, Melanie Witt, and Jeremy Stanley for reporting, reproducing, fixing and coordinating this issue.

Version history​

• Mention glance format-inspector protection, v1.0, 2026-02-17, 15:30 CET.
• Typos fixed, v0.6, 2026-02-16, 15:45 CET.
• Initial Draft, v0.5, 2026-02-16, 15:00 CET.

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.

Evolution of SCS activities​

Previously, we had a project web site that covered many areas of work that was done in the SCS project until it was successfully completed at the end of 2024. It covered the standardization work as well as the development of the reference implementation and also had a vast collection of links and technical content, a lot of which was related to the reference implementation. For newcomers, it was somewhat hard to distill the various aspects and goals of SCS though.

With the end of the funded project, we split the activities into different organizations with distinct goals:

1. The Forum SCS Standards is responsible for governing the standardization process. While it pulls significant input from the various software projects that belong to the SCS ecosystem, it is neutral towards them beyond the preference for standards compliance. This reflects that there can and ideally should be several implementations for a standard. The new website serves as an overall entrance point to Sovereign Cloud Stack with a focus on the standardization and certification.
2. The SCS community consists of individuals and organizations that develop, support, test, use, or otherwise contribute to the software and standards that implement and codify SCS. The community elects a project board that organizes and motivates contributions. The work of the community is mainly visible on the Documentation web site and the github site.

Blog articles​

Blog articles with technical content relating to a specific implementation (or a set of implementations) are not a great fit for the general web site. The good news is that the SCS project's rich Documentation site is architected in a way that it assembles documentation from various places. Unlike the Forum, it does not need to prioritize neutrality as top priority, but benefits and prefers those projects that contribute useful content to it.

We have decided to use docusaurus' blog feature to publish blog articles here. We appreciate contributions.

Old blog content​

The blog content from the old web site has been migrated over into the archive on the new site. You can also find the other types of community news there.

Some news that might fit the Blog category have also been published in the main news section on the new web site.