Skip to content

Commit dc7dd91

Browse files
garloffgarloff
committed
Blog post for CVE-2026-22797.
Now prefixed with an explanation why this one is late by our normal standards. Signed-off-by: Kurt Garloff <kurt@garloff.de>
1 parent b1da3c3 commit dc7dd91

1 file changed

Lines changed: 130 additions & 0 deletions

File tree

‎blog/2026-01-23-cve-2026-22797.md‎

Lines changed: 130 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,130 @@
1+
---
2+
slug: openstack_oauth2_privescalation_cve_2026_22797
3+
title: CVE-2026-22797 OpenStack privilege escalation with oauth2 tokens
4+
authors: [garloff]
5+
tags: [security, openstack, cve]
6+
---
7+
8+
## Prefix
9+
10+
This advisory was drafted a few days ago, before the issue was public.
11+
As the issue turned out to only affect very specific configurations (which are
12+
not used in any standard SCS setting), we did not publish it with the urgency
13+
that we normally apply to protect our partners in time for a vulnerability becoming
14+
public.
15+
16+
Instead, we have taken the time to sort out the publication place in the the new Docs
17+
blog space, as described by the previous blog post.
18+
19+
## The vulnerability
20+
21+
Keystone is the central Identity and Access Management component in OpenStack.
22+
Whenever you talk to an OpenStack service, you authenticate to keystone via
23+
one of the supported methods. In return, keystone will issue a token that
24+
entitles you to have certain privileges when talking to the individual services.
25+
26+
One of the supported ways to authenticate is to use oauth2 tokens.
27+
When keystonemiddleware investigates these
28+
tokens it adds headers that indicate privileges associated with the account.
29+
30+
Unfortunately, keystonemiddleware does not clear headers when receiving
31+
oauth2 tokens, so an authenticated user can send oauth2 tokens with
32+
headers that actually indicate admin privileges and can trick services
33+
into assuming elevated privileges.
34+
The issue was introduced with keystonemiddleware 10.5.0 when support for
35+
`external_oauth2_tokens` was added.
36+
37+
The vulnerability has been assigned [CVE-2026-22797](https://cve.report/CVE-2026-22797).
38+
39+
The issue was reported by Grzegorz Grasza of RedHat.
40+
41+
## Impact on OpenStack deployments
42+
43+
When keystone is configured to accept oauth2 tokens for authentication, anyone
44+
able to produce and send any valid tokens may inject headers to impersonate other
45+
users or assume additional roles up to and including admin privileges. Admin
46+
privileges allow unrestricted access via the API and are only meant to be used
47+
by the cloud operators.
48+
49+
_To abuse this vulnerability, the attacker must be an authenticated
50+
user of the platform. In addition, the platform must be configured to
51+
accept oauth2 tokens, which is not a supported configuration in yaook
52+
nor a simple change versus the default configuration is OSISM._
53+
54+
To make services accept oauth2 tokens, their config would need
55+
to be changed via `paste.ini`
56+
57+
```ini
58+
[pipeline:main]
59+
pipeline = ext_oauth2_token
60+
61+
[filter:ext_oauth2_token]
62+
paste.filter_factory = keystonemiddleware.external_oauth2_token:filter_factory
63+
```
64+
65+
in order to be affected. This is not the case in any default configurations and
66+
also not when using the OIDC federation with keycloak that is documented for SCS.
67+
68+
Providers are advised to investigate whether they have done changes to enable oauth2
69+
tokens via keystonemiddleware as depicted above and assume that they are affected
70+
in that case.
71+
72+
## Embargo
73+
74+
The issue has been reported to the OpenStack Vulnerability Management Team in
75+
private. The reporters and upstream developers have worked together to address
76+
the issue with fixes and an embargo date has been set to Thursday, 2026-01-15,
77+
15:00 UTC (16:00 CET). At this point in
78+
time, the patches get merged and the OpenStack Security Advisory
79+
([OSSA-2026-001](https://security.openstack.org/ossa/OSSA-2026-001.html))
80+
is published. The issue is tracked in OpenStack issue
81+
[#2219018](https://bugs.launchpad.net/keystonemiddleware/+bug/2129018), which should become
82+
publically accessible after the lift of the embargo and the publication
83+
of this advisory.
84+
85+
Under the used responsible disclosure approach, the information was shared with
86+
a select group of trustable users of OpenStack, so they can prepare updates and
87+
protect their infrastructure at the time this issue becomes public.
88+
89+
## Mitigation and Fixes
90+
91+
The fix is straightforward and consists of clearing headers and explicitly
92+
unsetting the critical headers. For affected setups, it is recommended to update
93+
the keystone services immediately.
94+
95+
For clouds that can not update keystone directly, the dangerous headers could
96+
be filtered out by a reverse proxy or similar network infrastructure in front
97+
of the openstack API services or the oauth2 tokens could be temporarily disabled
98+
by reverting back to the standard
99+
100+
```ini
101+
[filter:authtoken]
102+
paste.filter_factory = keystonemiddleware.auth_token:filter_factory
103+
```
104+
105+
### Links to specific information from related OpenStack distributions
106+
107+
- [ALASCA](https://alasca.cloud/) has issued an
108+
[advisory for yaook](https://lists.alasca.cloud/hyperkitty/list/yaook@lists.alasca.cloud/thread/Q2GZ7PNXHJ7YHRDALKXTHZMTHS7PM5NE/)
109+
basically stating that it's not really possible to use yaook in a way that it would be affected.
110+
- [OSISM](https://osism.tech/) has published an
111+
[advisary for OSISM](https://osism.tech/docs/appendix/security/ossa-2026-001/)
112+
with more details how to get a fixed keystone container deployed in case you
113+
have manually enabled such oauth2 tokens.
114+
115+
## Thanks
116+
117+
The authors would like to thank Grzegorz Grasza, Thomas Goirand (zigo),
118+
Jay Faulkner, David Wilde, Artem Goncharov and Jeremy Stanley for their
119+
work on this issue.
120+
121+
## Sovereign Cloud Stack Security Contact
122+
123+
SCS security contact is <mailto:security@scs.community>, as published on
124+
<https://scs.community/.well-known/security.txt>.
125+
126+
## Version history
127+
128+
- Initial Draft, v0.1, 2026-01-13, 22:30 CET.
129+
- Release, v1.0, 2026-01-20, 08:30 CET.
130+
- Release to SCS docs blog, v1.1, 2026-01-23, 10:30 CET.

0 commit comments

Comments
 (0)