Blog post for CVE-2026-22797.

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.

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