Skip to main content

OSSA-2026-001: Privilege Escalation via Identity Headers in External OAuth2 Tokens

PropertyValue
Date2026-01-15 (Errata: 2026-01-16)
CVECVE-2026-22797
SeverityHigh
Affected Projectkeystonemiddleware
ReporterGrzegorz Grasza (Red Hat)

Summary​

A critical vulnerability was discovered in the external_oauth2_token middleware of OpenStack keystonemiddleware. The middleware fails to sanitize incoming authentication headers before processing OAuth 2.0 tokens, allowing authenticated attackers to escalate privileges or impersonate other users.

Affected Versions​

keystonemiddleware VersionStatus
>= 10.5.0, < 10.7.2Vulnerable
>= 10.8.0, < 10.9.1Vulnerable
>= 10.10.0, < 10.12.1Vulnerable
>= 10.12.1Fixed
>= 11.0.0 (Gazpacho)Fixed

The vulnerable code was introduced in keystonemiddleware 10.5.0 when the external_oauth2_token module was added.

Impact on OSISM​

This vulnerability only affects OSISM deployments that use external OAuth 2.0 authorization servers for OpenStack authentication. Standard OSISM deployments using the default auth_token middleware with Keystone-native authentication are not affected.

You are potentially affected if:

  • Your deployment uses the external_oauth2_token middleware instead of the standard auth_token middleware
  • You have configured an external OAuth 2.0 / OpenID Connect (OIDC) identity provider for OpenStack authentication

How to Check if You Are Affected​

Check in the Configuration Repository​

In OSISM, custom Keystone paste configurations are managed via overlay files in the configuration repository. The file environments/kolla/files/overlays/keystone/keystone-paste.ini is deployed to /etc/keystone/keystone-paste.ini in the Keystone container (which serves as the api-paste.ini).

  1. Check if you have a custom paste configuration:

    # In your configuration repository
    ls -la environments/kolla/files/overlays/keystone/keystone-paste.ini

  2. If this file exists, check for the ext_oauth2_token filter:

    grep "ext_oauth2_token" environments/kolla/files/overlays/keystone/keystone-paste.ini

  3. If the file does not exist or the grep returns no results, your deployment uses the standard authentication and is not affected.

Check on the Running Deployment​

Alternatively, check directly on a control node:

docker exec keystone grep "ext_oauth2_token" /etc/keystone/keystone-paste.ini

If no results are returned, your deployment is not affected.

Vulnerability Details​

The external_oauth2_token middleware only conditionally sets certain identity headers (e.g., X-Is-Admin-Project is only set when the token has admin privileges). This conditional logic leaves spoofed header values intact when the expected conditions are not met.

An authenticated attacker could exploit this by injecting forged identity headers such as:

  • X-Is-Admin-Project
  • X-Roles
  • X-User-Id
  • X-User-Domain-Id

This allows privilege escalation to admin roles or impersonation of other users.

Remediation​

For OSISM Releases​

A fix will be included in upcoming OSISM releases that ship a patched keystonemiddleware version. Consult the OSISM Release Notes for version information and availability.

Alternatively, you can use rolling tags to override the Keystone container image with a version that includes the fix. Configure the following in environments/kolla/images.yml:

keystone_tag: "2024.2"  # or "2025.1", depending on your OpenStack release

Mitigation​

If you use external OAuth 2.0 authentication, consider the following measures:

  1. Restricting network access to OpenStack API endpoints
  2. Monitoring for suspicious API requests with unusual identity headers
  3. Temporarily reverting to Keystone-native authentication if feasible

References​