4 posts tagged with "openstack"

The vulnerabilities​

A series of five related vulnerabilities has been identified in OpenStack Keystone that impact how credentials are delegated and how authorization policies are enforced. These vulnerabilities allow authenticated attackers to bypass security boundaries, impersonate users, and potentially escalate privileges to cloud administrator.

The core issues are:

• RBAC Policy Bypass (CVE-2026-42999): An attacker can inject RBAC policy targets via a JSON request body, allowing them to bypass authorization on protected endpoints. This can lead to the reading of credential secrets and escalation to cloud admin.

• Application Credential Impersonation (CVE-2026-42998 & CVE-2026-43000): Keystone failed to verify if the caller owned the Application Credential being used. This allows for user impersonation within a project, which can be chained with "trust" operations to escalate privileges from a project member to an administrator.

• Cross-Project EC2 Credentials (CVE-2026-43001): Application credentials scoped to one project could be used to create EC2-style credentials for a different project, enabling lateral movement across tenant boundaries.

• Federated Token Rescoping (CVE-2026-44394): In SAML2/OIDC deployments, federated users can maintain access indefinitely by repeatedly rescoping tokens, as Keystone issues a fresh full-TTL token instead of inheriting the original expiry.

These issues were reported by Boris Bobrov (SAP SE), Tim Shepherd (roiai.ca), Erichen (Institute of Computing Technology, CAS), and Artem Goncharov (SysEleven GmbH).

Impact on the SCS software ecosystem​

These vulnerabilities pose a significant risk to SCS clouds. Because SCS environments rely heavily on S3 compatibility—which utilizes EC2-style credentials—the ability to perform cross-project lateral movement (CVE-2026-43001) is a direct threat to tenant isolation.

Furthermore, the RBAC bypass (CVE-2026-42999) is particularly severe as it undermines the fundamental security model of the cloud, potentially allowing an authenticated user to gain full administrative control over the entire Keystone service. For deployments using federated identity (SAML2/OIDC), the ability to bypass session expiration (CVE-2026-44394) also weakens the security posture regarding user lifecycle management.

Embargo​

The issues were reported to the OpenStack Vulnerability Management Team. Following coordination with the reporters and upstream developers, the official OpenStack Security Advisory OSSA-2026-015 was published on Tuesday, 2026-05-28.

Mitigation and Fixes​

The primary remediation is to upgrade Keystone to the patched versions provided by the upstream OpenStack project.

Note: For users with highly customized trust policies, please be aware that the fix for CVE-2026-42999 modifies the trust policy structure. This may require manual updates to your custom policies to ensure continued functionality for services like Heat or image uploads.

The SCS ecosystem software providers are providing fixed Keystone images:

• OSISM
• yaook

Outlook​

We see an increased velocity with which security issues are found in the IT industry. We're glad to see them reported against the open source projects that we are using and the community is working hard to address the issues. Security researchers have become more efficient due to the usage of AI tools and so have OSS developers - we expect the high volume to continue for the upcoming months and maybe beyond.

SCS has always emphasized the ability to patch with confidence on a daily basis as an important design criterium for the lifecycle management of our components. It now seems to be needed more than ever. We advise operators to prepare for this new world and ensure to work on any processual issues that are slowing them down in deployment.

References​

• OSSA-2026-015 Advisory
• Launchpad Bug #2148398, #2148477, #2149775, #2149789, #2150089, #2150379
• CVE-2026-42998, CVE-2026-42999, CVE-2026-43000, CVE-2026-43001, CVE-2026-44394

Thanks​

The author would like to thank Boris Bobrov, Tim Shepherd, Erichen, and Artem Goncharov for their work in discovering and reporting these critical vulnerabilities and the OpenStack Vulnerability Management Team for handling and coordinating this and the OpenStack Keystone upstream developers for addressing the issues.

Sovereign Cloud Stack Security Contact​

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

Version history​

• Initial draft, v0.1, 2026-05-28, 16:00 CEST
• Release, v1.0, 2026-05-29, 12:00 CEST

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.