diff --git a/blog/2026-01-23-cve-2026-22797.md b/blog/2026-01-23-cve-2026-22797.md new file mode 100644 index 0000000000..08d7ca4987 --- /dev/null +++ b/blog/2026-01-23-cve-2026-22797.md @@ -0,0 +1,130 @@ +--- +slug: openstack_oauth2_privescalation_cve_2026_22797 +title: CVE-2026-22797 OpenStack privilege escalation with oauth2 tokens +authors: [garloff] +tags: [security, openstack, 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](https://nvd.nist.gov/vuln/detail/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` + +```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](https://security.openstack.org/ossa/OSSA-2026-001.html)) +is published. The issue is tracked in OpenStack issue +[#2219018](https://bugs.launchpad.net/keystonemiddleware/+bug/2129018), 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 + +```ini +[filter:authtoken] +paste.filter_factory = keystonemiddleware.auth_token:filter_factory +``` + +### Links to specific information from related OpenStack distributions + +- [ALASCA](https://alasca.cloud/) has issued an + [advisory for yaook](https://lists.alasca.cloud/hyperkitty/list/yaook@lists.alasca.cloud/thread/Q2GZ7PNXHJ7YHRDALKXTHZMTHS7PM5NE/) + basically stating that it's not really possible to use yaook in a way that it would be affected. +- [OSISM](https://osism.tech/) has published an + [advisary for OSISM](https://osism.tech/docs/appendix/security/ossa-2026-001/) + 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](mailto:security@scs.community), as published on +[https://scs.community/.well-known/security.txt](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. diff --git a/blog/authors.yml b/blog/authors.yml index 920460af29..e79a15c584 100644 --- a/blog/authors.yml +++ b/blog/authors.yml @@ -12,12 +12,12 @@ itrich: garloff: name: Kurt Garloff - title: CEO @ S7n Cloud Services, former CTO SCS + title: CEO @ S7n Cloud Services, former CTO @ SCS url: https://github.com/garloff image_url: https://github.com/garloff.png fkr: name: Felix Kronlage-Dammers - title: Leader Forum SCS-Standards + title: Leader Forum SCS-Standards @ OSBA url: https://github.com/fkr image_url: https://github.com/fkr.png