CVE-2026-90997 in Keycloakinfo

Summary

by MITRE • 09/17/2026

A flaw was found in Keycloak. When deployed in stateless mode with MySQL or MariaDB, a mismatch in row-count semantics between the database driver and Keycloak's application logic allows an attacker to bypass replay protection. This vulnerability enables an attacker who intercepts single-use security artifacts, such as JWT client assertions, DPoP proofs, or one-time password (TOTP) codes, to replay them. Successful exploitation grants unauthorized access to the token endpoint or login flow.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 09/17/2026

The identified vulnerability in Keycloak represents a critical failure in stateless authentication mechanisms when operating with MySQL or MariaDB database backends. This flaw stems from an architectural mismatch between the application logic designed for transactional consistency and the specific row-count semantics implemented by these particular relational database drivers. In standard secure implementations, single-use security artifacts such as JSON Web Token (JWT) client assertions, Demonstration of Proof-of-Possession (DPoP) proofs, or Time-based One-Time Passwords must be strictly consumed once to prevent replay attacks. However, due to the discrepancy in how the database driver reports affected rows during update operations, Keycloak fails to reliably detect that a specific artifact has already been processed and invalidated. This logical error effectively nullifies the intended one-time-use constraint, creating a window of opportunity for malicious actors to exploit this inconsistency.

From an operational perspective, this vulnerability allows an attacker who intercepts valid security artifacts in transit or through other means to reuse them against the authentication infrastructure. Since Keycloak relies on these database records to track consumed tokens and proofs, the inability to correctly identify previously processed entries means that a captured JWT client assertion can be submitted multiple times as if it were fresh. Similarly, intercepted DPoP proofs or TOTP codes can be replayed successfully because the system does not accurately register their prior consumption in the stateless session store. This breakdown in integrity checks undermines the fundamental security model of mutual authentication and proof-of-possession protocols that Keycloak is designed to enforce.

The impact of successful exploitation is severe, granting unauthorized access to sensitive endpoints within the identity provider ecosystem. Specifically, attackers can bypass replay protection mechanisms on the token endpoint, potentially obtaining valid access tokens for compromised users or services without possessing their actual credentials. Furthermore, this flaw compromises login flows that depend on single-use artifacts, allowing adversaries to authenticate as legitimate entities by reusing intercepted data. This capability facilitates account takeover attacks, privilege escalation, and unauthorized access to protected resources, significantly weakening the overall security posture of deployments relying on Keycloak for identity management with MySQL or MariaDB backends in stateless mode.

To mitigate this risk, administrators should immediately assess their deployment configuration and consider migrating away from stateless modes when using vulnerable database drivers until a patched version is available. Applying vendor-provided patches that correct the row-count handling logic is essential to restore proper replay protection semantics. Additionally, implementing network-level controls such as mutual TLS can reduce the likelihood of artifact interception in transit, although this does not fully address the backend logical flaw. Organizations should also review their database driver versions and ensure they are aligned with Keycloak’s tested compatibility matrix to avoid similar semantic mismatches. Regular auditing of authentication logs for anomalous patterns of repeated token usage may help detect ongoing exploitation attempts while mitigation strategies are being deployed.

This vulnerability aligns with CWE-347, which describes Improper Verification of Cryptographic Signature, as the system fails to properly verify that a cryptographic proof has not been previously used. It also maps to MITRE ATT&CK technique T1588, specifically obtaining credentials through interception or replay attacks against authentication mechanisms. The core issue reflects CWE-697, Incorrect Calculation, where the application logic miscalculates the state of consumed resources due to external dependency behavior. Addressing these root causes requires both software updates and rigorous configuration reviews to ensure that security controls function as intended across all supported database environments.

Responsible

Redhat

Reservation

09/14/2026

Disclosure

09/17/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Might our Artificial Intelligence support you?

Check our Alexa App!