Keycloak CVE-2026-9802

Three concurrent conditions must be met for exploitation: (1) revokeRefreshToken=true must be explicitly enabled in the Keycloak realm configuration - this is not the default in all deployments and must be verified per realm; (2) persistent session storage (e.g., an external database or cache backend) must be configured rather than in-memory-only session handling; (3) the Keycloak server must undergo a restart after the refresh token was captured by the attacker but before the token's natural expiry. Additionally, the attacker must have already obtained a valid refresh token belonging to the target victim, meaning token capture is a prerequisite, not part of this exploit itself. CVSS UI:R reflects that the victim's prior authenticated interaction was required for the token to be issued and captured. Exploitation is therefore limited by: the requirement for prior token theft, dependence on a server restart event, the specific non-default realm configuration, and the need for the captured token to still be within its configured lifetime window at the time of replay.

The CVSS 6.8 (Medium) score reflects a constrained but non-trivial attack path. The vector AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N signals that exploitation requires high complexity - the attacker must have previously obtained a refresh token, and a server restart must occur within the window before the token's natural expiry. PR:N indicates the attacker does not require their own authenticated session on the Keycloak instance; however, UI:R confirms the victim's prior interaction was necessary for token capture. The confidentiality and integrity impacts are both rated High, reflecting the account takeover potential. No EPSS score was provided in the supplied intelligence, so probabilistic exploitation likelihood cannot be quantified from this data. The absence of a KEV listing and the AC:H complexity rating together suggest this is not a broadly automated threat, but is realistic in targeted scenarios (e.g., post-phishing token theft followed by an opportunistic or induced restart). The actual organizational risk is amplified if the affected Keycloak instance is a federated SSO gateway protecting numerous downstream applications, as a single token replay could cascade into multi-system access.

An attacker intercepts or exfiltrates a victim's OAuth 2.0 refresh token - for example, via a prior phishing campaign, a compromised browser, or a man-in-the-middle on an insecure network segment. The token is later revoked (e.g., the user logs out or an admin revokes sessions), but a subsequent Keycloak server restart resets the internal revocation timing state. The attacker then presents the revoked token to the Keycloak token endpoint, which now evaluates it as valid, issuing a fresh access token and granting unauthorized access to the victim's account and any downstream resources protected by that identity.