Keycloak CVE-2026-90997

Exploitation requires the target to run Keycloak in stateless mode with a MySQL or MariaDB backend - this specific driver/application row-count semantic mismatch is the root cause and is a hard prerequisite (PostgreSQL/other backends or non-stateless deployments are not indicated as affected). The attacker must also intercept a still-valid single-use security artifact (a JWT client assertion, DPoP proof, or TOTP code) before replaying it, which is what the CVSS AC:H reflects. Limiting factors: the non-default stateless+MySQL/MariaDB configuration, the need for interception capability (network position or access to captured artifacts, potentially requiring defeat of TLS), and the narrow validity window of single-use artifacts. No prior authentication (PR:N) or user interaction (UI:N) on the attacker's part is required once a valid artifact is captured.

This is a genuine, credible authentication-bypass finding rather than an inflated high-CVSS score. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, 7.4 High) is internally consistent with CWE-294 (Authentication Bypass by Capture-replay): network-reachable, no privileges needed (the replayed artifact IS the authentication), but AC:H correctly reflects that the attacker must first intercept a valid single-use artifact AND the target must run a specific deployment (stateless mode on MySQL/MariaDB). No EPSS score, no CISA KEV listing, and no public exploit code were provided, so there is no signal of active or automatable exploitation - exploitation status is 'no public exploit identified at time of analysis'. The dual gate (interception capability + non-default DB/stateless configuration) means this is a targeted-opportunity flaw against specific Keycloak deployments, not a mass-exploitable internet-wide bug, despite the network attack vector. The primary limiting factor conflicting with the network vector is the AC:H interception requirement - worth verifying whether the artifacts traverse TLS (which would further raise the interception bar). Given Keycloak's role as a central identity broker, successful replay against the token endpoint or login flow has high blast radius, so patching should be prioritized wherever the vulnerable configuration exists.

An attacker positioned to observe authentication traffic against a Keycloak instance running in stateless mode backed by MySQL or MariaDB captures a single-use security artifact - a JWT client assertion, DPoP proof, or TOTP code - and replays it to the token endpoint or login flow. Because the row-count mismatch between the DB driver and Keycloak's logic causes the replay-detection check to falsely believe the artifact has not been used, the replay succeeds and grants unauthorized access. No public proof-of-concept is available at time of analysis.