CVE-2026-8922: 
Java vulnerability analysis and mitigation

CVE-2026-8922 is a security flaw in Keycloak's OpenID Connect (OIDC) Introspection feature, where revoked tokens can remain active when both realm-level and client-level notBefore revocation policies are simultaneously configured. The vulnerability was reported on May 18, 2026, and publicly disclosed on May 19, 2026. It affects the org.keycloak:keycloak-services Maven package in versions up to and including 26.6.2. It carries a CVSS v3.1 base score of 5.4 (Medium) (Red Hat Advisory, GitHub Advisory).

The root cause is classified as CWE-303 (Incorrect Implementation of Authentication Algorithm). When both a realm-level and a client-level notBefore value are present, Keycloak's OIDC Introspection endpoint fails to properly evaluate the realm-level revocation policy, effectively ignoring it in favor of the client-level policy. This means tokens that an administrator has revoked at the realm level may still pass introspection checks and be treated as valid by relying parties. The flaw resides in the org.keycloak.protocol.oidc package within keycloak-services (Red Hat Bugzilla, GitHub Advisory). Relevant fix commits are available at keycloak/keycloak@b6cd645 and keycloak/keycloak@c5bda80, and related issues are tracked in keycloak/keycloak#49118 and #49129 (GitHub Advisory).

Successful exploitation allows an attacker holding a token that should have been revoked at the realm level to continue using it for unauthorized access, bypassing the intended revocation. This results in low confidentiality and low integrity impact — an attacker may access protected resources or perform actions they are no longer authorized to perform, for as long as the token remains valid. Availability is not directly affected. The risk is most significant in environments where realm-level revocation is used as a security response mechanism (e.g., revoking all tokens after a credential compromise), as the bypass undermines that control (Red Hat Advisory, GitHub Advisory).

1. Identify target configuration: Confirm that the target Keycloak deployment has both a realm-level notBefore revocation policy and a client-level notBefore policy configured, as the flaw only manifests when both are present.
2. Obtain a valid token: Authenticate to the Keycloak realm as a low-privileged user to obtain an OIDC access token before any revocation event occurs.
3. Trigger realm-level revocation: Wait for or observe an administrator performing a realm-level notBefore revocation (e.g., via the Keycloak admin console under Realm Settings > Sessions > "Not Before"), which should invalidate all previously issued tokens.
4. Attempt token introspection: Submit the previously obtained (now supposedly revoked) token to the OIDC Introspection endpoint (/realms/{realm}/protocol/openid-connect/token/introspect). Due to the flaw, the endpoint evaluates only the client-level notBefore policy and returns active: true.
5. Access protected resources: Use the still-active token to access APIs or resources that rely on the introspection endpoint for authorization, bypassing the intended revocation (Red Hat Bugzilla, GitHub Advisory).

• Logs: Keycloak server logs showing successful OIDC introspection responses (active: true) for tokens issued before a realm-level notBefore revocation event; audit log entries showing resource access by sessions that should have been invalidated.
• Network: Repeated introspection requests to /realms/{realm}/protocol/openid-connect/token/introspect using tokens with an iat (issued-at) timestamp predating the realm's notBefore value.
• Application Behavior: Resource servers accepting tokens that were issued prior to a realm-level revocation action, particularly when client-level notBefore policies are also in effect.

The fix is included in Keycloak version 26.6.3 and later; administrators should upgrade to this release or newer (Keycloak Release). Red Hat has issued errata RHSA-2026:25097 and RHSA-2026:25098 for affected Red Hat build of Keycloak packages (Red Hat Errata 25098, Red Hat Errata 25097). As a workaround prior to patching, administrators can remove client-level notBefore configurations so that only the realm-level policy is in effect, which avoids triggering the flawed code path.