CVE-2026-9802: Keycloak Auth Bypass Vulnerability

CVE-2026-9802 Overview

A flaw in Keycloak allows revoked refresh tokens to be replayed after a server restart. The issue affects deployments where revokeRefreshToken=true is enabled and persistent session storage is configured. A server restart resets internal timing mechanisms used to enforce revocation state, creating a window in which previously revoked tokens become valid again. An attacker who has captured a refresh token can obtain unauthorized access to the victim's account, leading to information disclosure or privilege escalation [CWE-613].

Critical Impact

Revoked refresh tokens become replayable after Keycloak restarts, granting attackers unauthorized access to victim accounts.

Affected Products

• Keycloak deployments with revokeRefreshToken=true enabled
• Keycloak instances using persistent session storage
• Red Hat Build of Keycloak and Red Hat Single Sign-On distributions

Discovery Timeline

• 2026-05-28 - CVE CVE-2026-9802 published to NVD
• 2026-05-28 - Last updated in NVD database

Technical Details for CVE-2026-9802

Vulnerability Analysis

Keycloak supports one-time-use refresh tokens through the revokeRefreshToken setting. When enabled, each refresh token is invalidated after a single use, and the server tracks the revocation state to reject replays. This protection depends on internal timing references that the server maintains in memory and aligns with persistent session storage.

The vulnerability stems from improper persistence of refresh token validity state across restarts [CWE-613]. When the Keycloak server restarts, the internal timing mechanisms reset, and the persistent session store no longer accurately reflects which refresh tokens have already been consumed. Tokens that were correctly revoked before the restart can be presented again to the token endpoint and accepted as valid.

Root Cause

The root cause is an insufficient session expiration check tied to in-memory timing state. Revocation tracking is not fully reconciled against persistent storage during startup. The server treats previously revoked tokens as fresh because the reference point used to evaluate token freshness is reinitialized.

Attack Vector

The attacker must first capture a valid refresh token from the victim. Token capture typically requires a prior compromise such as a malicious client, log exposure, network interception, or browser-side theft. After the targeted Keycloak instance restarts, the attacker submits the captured token to the /token endpoint with grant_type=refresh_token. The server issues new access and refresh tokens, granting the attacker the victim's session privileges. Exploitation requires user interaction during the initial token capture phase and depends on a restart event occurring after revocation.

No verified public proof-of-concept code is available. See the Red Hat CVE-2026-9802 Advisory and Red Hat Bug Report #2482467 for vendor technical details.

Detection Methods for CVE-2026-9802

Indicators of Compromise

• Successful refresh_token grants issued shortly after a Keycloak restart for tokens previously logged as revoked.
• Multiple successful refresh operations using the same token identifier (jti) across different sessions.
• Authentication events for a user from a new IP address or user agent immediately following a service restart.

Detection Strategies

• Correlate Keycloak audit events of type REFRESH_TOKEN with prior REVOKE_GRANT or TOKEN_EXCHANGE events for the same jti or session identifier.
• Alert on token refresh activity occurring within a defined window after a Keycloak process restart, especially for high-privilege accounts.
• Monitor for refresh token reuse anomalies where the issuance timestamp predates the most recent server start time.

Monitoring Recommendations

• Forward Keycloak event logs and admin events to a centralized SIEM for correlation with restart and deployment events.
• Track service restart frequency and align it with spikes in token refresh activity per realm and client.
• Enable client-level event logging for all OIDC clients that issue long-lived refresh tokens.

How to Mitigate CVE-2026-9802

Immediate Actions Required

• Apply the Keycloak security update referenced in the Red Hat CVE-2026-9802 Advisory once available for your distribution.
• Force revocation of all active sessions and refresh tokens after patching to invalidate any tokens captured before remediation.
• Rotate signing keys for affected realms to invalidate outstanding tokens that may have been intercepted.

Patch Information

Refer to the Red Hat CVE-2026-9802 Advisory and Red Hat Bug Report #2482467 for fixed package versions and vendor remediation guidance. Apply updates to all Keycloak nodes in a cluster and restart in a coordinated manner.

Workarounds

• Reduce refresh token lifetimes in realm settings to shrink the replay window available to an attacker.
• Enforce client authentication on all confidential clients to prevent refresh token use without a valid client secret or assertion.
• Invalidate all user sessions after each Keycloak restart through administrative action until the patch is applied.
• Restrict network access to the Keycloak token endpoint to known client IP ranges where feasible.

# Administrative session invalidation after restart using kcadm
kcadm.sh config credentials --server https://sso.example.com \
  --realm master --user admin
kcadm.sh create realms/<realm>/logout-all