Suse
CVE-2026-33496
HIGH
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Lifecycle Timeline
3DescriptionGitHub Advisory
Description
Ory Oathkeeper is vulnerable to authentication bypass due to cache key confusion. The oauth2_introspection authenticator cache does not distinguish tokens that were validated with different introspection URLs. An attacker can therefore legitimately use a token to prime the cache, and subsequently use the same token for rules that use a different introspection server.
Preconditions
Ory Oathkeeper has to be configured with multiple oauth2_introspection authenticator servers, each accepting different tokens. The authenticators also must be configured to use caching. An attacker has to have a way to gain a valid token for one of the configured introspection servers.
Mitigation
Ory Oathkeeper now includes the introspection server URL in the cache key, preventing confusion of tokens.
Update to the patched version of Ory Oathkeeper. If that is not immediately possible, disable caching for oauth2_introspection authenticators.
AnalysisAI
Ory Oathkeeper contains a cache key confusion vulnerability in its oauth2_introspection authenticator that allows attackers to bypass authentication by reusing tokens across different introspection servers. Attackers with a valid token for one configured introspection server can exploit the cache mechanism to gain unauthorized access to resources protected by different introspection servers. This vulnerability requires the specific precondition of multiple oauth2_introspection authenticators with caching enabled, and a patch is available from the vendor.
Technical ContextAI
Ory Oathkeeper is a cloud-native identity and access proxy written in Go (pkg:go/github.com_ory_oathkeeper) that performs authentication and authorization for APIs and services. The vulnerability stems from CWE-305 (Authentication Bypass by Primary Weakness), where the oauth2_introspection authenticator's caching mechanism fails to include the introspection server URL as part of the cache key. When OAuth2 token introspection is performed, the cache stores the validation result using only the token value, not the combination of token and introspection endpoint. This design flaw allows a token validated against one authorization server to be incorrectly accepted when presented to rules configured with a different introspection server, as the cache returns a positive result without re-validating against the correct endpoint.
RemediationAI
Update Ory Oathkeeper to the patched version that includes commit 198a2bc82a99e0a77bd0ffe290cbdd5285a1b17c, which adds the introspection server URL to the cache key to prevent token confusion. The patch and upgrade instructions are available through the GitHub security advisory at https://github.com/ory/oathkeeper/security/advisories/GHSA-4mq7-pvjg-xp2r. If immediate patching is not possible, disable caching for all oauth2_introspection authenticators by removing or commenting out the cache configuration in the Oathkeeper configuration files. This workaround will prevent the vulnerability but may impact performance by requiring introspection on every request. Organizations should review their authenticator configurations to confirm whether they use multiple oauth2_introspection servers with caching, as only those configurations are vulnerable.
Same weakness CWE-305 – Authentication Bypass by Primary Weakness
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: High| Product | Status |
|---|---|
| openSUSE Leap 15.6 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Fixed |
| openSUSE Leap 15.5 | Fixed |
Share
External POC / Exploit Code
Leaving vuln.today
GHSA-4mq7-pvjg-xp2r