Add CVE-2026-33551 announcement.

blog/2026-04-08-cve-2026-33551.md

@@ -0,0 +1,91 @@
+---
+title: CVE-2026-33551 OpenStack privilege escalation with EC2 credentials from Application Credentials
+authors: [garloff]
+slug: openstack_privescal_ec2_creds_from_appcreds_cve_2026_33551
+tags: [security, openstack, cve]
+---
+
+## 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](https://nvd.nist.gov/vuln/detail/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 coponents or the delegated privileges for
+human bearers of the AppCred. The fact that EC2 credentials can be used to
+work around an 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 creators 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](https://security.openstack.org/ossa/OSSA-2026-005.html) is
+published. The issue is tracked in OpenStack issue
+[#2142138](https://bugs.launchpad.net/nova/+bug/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](https://osism.tech/docs/appendix/security/ossa-2026-005)
+- [yaook]<!--(https://yaook.cloud/security-advisories-cve-2026-33551)--> (TBD)
+
+## 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](mailto:security@scs.community), as published on
+[https://sovereigncloudstack.org/.well-known/security.txt](https://sovereigncloudstack.org/.well-known/security.txt).
+
+## Version history
+
+- Initial draft, v0,9, 2026-04-08, 13:45 CEST