|
| 1 | +--- |
| 2 | +title: CVE-2026-33551 OpenStack privilege escalation with EC2 credentials from Application Credentials |
| 3 | +authors: [garloff] |
| 4 | +slug: openstack_privescal_ec2_creds_from_appcreds_cve_2026_33551 |
| 5 | +tags: [security, openstack, cve] |
| 6 | +--- |
| 7 | + |
| 8 | +## The vulnerability |
| 9 | + |
| 10 | +OpenStack allows the creation of Application Credentials to give its bearer |
| 11 | +access to a project with the privileges of the user who created the AppCreds. |
| 12 | +Application Credentials can have a limited lifetime and can be revoked. They |
| 13 | +can also be _restricted_ (which means that they can not be used to create |
| 14 | +additional application credentials) or can be assigned roles with lower |
| 15 | +privileges, limiting the privileges that the bearer has. |
| 16 | + |
| 17 | +When AppCreds are used to create EC2 credentials, keystone failed to |
| 18 | +require _unrestricted_ AppCreds and failed to require the member role, |
| 19 | +giving AppCreds that are _restricted_ or that have limited roles the |
| 20 | +ability to create EC2 credentials with the full privileges of the user |
| 21 | +who created the AppCred. |
| 22 | + |
| 23 | +This issue was reported by Maxence Bornecque from Orange Cyberdefense CERT |
| 24 | +Vulnerability Intelligence Watch Team and has been assigned |
| 25 | +[CVE-2026-33551](https://nvd.nist.gov/vuln/detail/CVE-2026-33551). |
| 26 | + |
| 27 | +## Impact on the SCS software ecosystem |
| 28 | + |
| 29 | +This issue affects OpenStack environments that allow the creation of EC2 |
| 30 | +style credentials, which is typically used for S3 access or EC2 compatibility. |
| 31 | +This is typically the case for SCS clouds, as S3 compatibility is a requirement. |
| 32 | + |
| 33 | +While creating AppCreds with roles with lower privileges is not a very common |
| 34 | +use case, it is supported by OpenStack clouds and is actually a good practice |
| 35 | +to limit the privileges of running coponents or the delegated privileges for |
| 36 | +human bearers of the AppCred. The fact that EC2 credentials can be used to |
| 37 | +work around an regain the privileges of the user who created the original |
| 38 | +AppCred is a serious issue, as it breaks the principle of least privileges |
| 39 | +and may weaken or break security models for applications or delegated |
| 40 | +authorizations. |
| 41 | + |
| 42 | +Note that this vulnerability does not allow to escalate privileges further |
| 43 | +than the original AppCred creators privileges and does require the attacker |
| 44 | +to get access to the limited AppCred in the first place. |
| 45 | + |
| 46 | +## Embargo |
| 47 | + |
| 48 | +The issue has been reported to the OpenStack Vulnerability Management Team in |
| 49 | +private. The reporters and upstream developers have worked together to address |
| 50 | +the issue with fixes and an embargo date |
| 51 | +has been set to Tuesday, 2026-04-07, 15:00 UTC (17:00 CEST). At this point in |
| 52 | +time, the patches get merged and the OpenStack Security Advisory |
| 53 | +[OSSA-2026-005](https://security.openstack.org/ossa/OSSA-2026-005.html) is |
| 54 | +published. The issue is tracked in OpenStack issue |
| 55 | +[#2142138](https://bugs.launchpad.net/nova/+bug/2142138), which should become |
| 56 | +publically accessible after the lift of the embargo and the publication |
| 57 | +of this advisory. |
| 58 | + |
| 59 | +Under the used responsible disclosure approach, the information was shared with |
| 60 | +a select group of trustable users of OpenStack, so they can prepare updates and |
| 61 | +protect their user data in time for the publication. |
| 62 | + |
| 63 | +## Mitigation and Fixes |
| 64 | + |
| 65 | +The temporary fix for this issue would be to disable the creation of EC2 |
| 66 | +credentials which however would prevent to enable new S3 access. |
| 67 | + |
| 68 | +There are patches from the upstream OpenStack keystone developers available. |
| 69 | +They add a check in the EC2 credential creation path that requires the |
| 70 | +AppCred to be unrestricted and to have at least member access to the project. |
| 71 | + |
| 72 | +The SCS ecosystem software providers provide fixed keystone images and |
| 73 | +installation instructions here as soon as the updated images are available: |
| 74 | + |
| 75 | +- [OSISM](https://osism.tech/docs/appendix/security/ossa-2026-005) |
| 76 | +- [yaook]<!--(https://yaook.cloud/security-advisories-cve-2026-33551)--> (TBD) |
| 77 | + |
| 78 | +## Thanks |
| 79 | + |
| 80 | +The author would like to thank Maxence Bornecque, Grzegorz Grasza, |
| 81 | +Douglas Mendizabal, Artem Goncharov, and Jeremy Stanley for reporting, |
| 82 | +fixing and coordinating this issue. |
| 83 | + |
| 84 | +## Sovereign Cloud Stack Security Contact |
| 85 | + |
| 86 | +SCS security contact is [security@scs.community](mailto:security@scs.community), as published on |
| 87 | +[https://sovereigncloudstack.org/.well-known/security.txt](https://sovereigncloudstack.org/.well-known/security.txt). |
| 88 | + |
| 89 | +## Version history |
| 90 | + |
| 91 | +- Initial draft, v0,9, 2026-04-08, 13:45 CEST |
0 commit comments