CVE-2026-1035: Keycloak Auth Bypass Vulnerability

CVE-2026-1035 Overview

A race condition vulnerability was discovered in the Keycloak identity and access management server during refresh token processing. The flaw exists in the TokenManager class responsible for enforcing refresh token reuse policies. When strict refresh token rotation is enabled, the validation and update of refresh token usage are not performed atomically, creating a Time-of-Check Time-of-Use (TOCTOU) vulnerability.

This allows concurrent refresh requests to bypass single-use enforcement and issue multiple access tokens from the same refresh token. As a result, Keycloak's refresh token rotation hardening—a security control designed to limit the impact of token theft—can be undermined by attackers with valid credentials who can issue multiple parallel requests.

Critical Impact

Attackers can exploit this race condition to bypass refresh token rotation policies, potentially maintaining persistent access even after token revocation attempts and undermining session security controls in Keycloak deployments.

Affected Products

• Keycloak Server (versions with strict refresh token rotation enabled)
• Red Hat Single Sign-On (SSO) deployments using Keycloak
• Applications relying on Keycloak's refresh token rotation for security hardening

Discovery Timeline

• January 21, 2026 - CVE-2026-1035 published to NVD
• January 21, 2026 - Last updated in NVD database

Technical Details for CVE-2026-1035

Vulnerability Analysis

This vulnerability is classified as CWE-367: Time-of-Check Time-of-Use (TOCTOU) Race Condition. The flaw stems from a non-atomic operation in Keycloak's token management subsystem.

When a client presents a refresh token to obtain a new access token, the TokenManager class performs two distinct operations: (1) checking whether the refresh token has already been used, and (2) marking it as used. Because these operations are not performed within an atomic transaction or protected by appropriate locking mechanisms, a narrow window exists between the check and the update.

The network-accessible nature of this vulnerability means an attacker with low-privilege credentials can exploit it remotely, though the high attack complexity requires precise timing of concurrent requests. The impact is limited to integrity—specifically, the ability to bypass refresh token rotation policies—with no direct confidentiality or availability impact.

Root Cause

The root cause is the lack of atomicity in the refresh token validation and consumption workflow within the TokenManager class. When refresh token rotation is configured in strict mode, Keycloak is supposed to invalidate a refresh token immediately after use. However, the implementation performs the "is token already used?" check and the "mark token as used" update as separate, non-atomic database operations.

This design flaw creates a race window where multiple concurrent refresh requests can all pass the "is used" check before any of them complete the "mark as used" update, allowing each request to successfully obtain new tokens.

Attack Vector

The attack requires an authenticated attacker with a valid refresh token. The exploitation involves:

1. The attacker obtains a legitimate refresh token through normal authentication flows
2. Multiple concurrent HTTP requests are sent to Keycloak's token endpoint, each presenting the same refresh token
3. Due to the race condition, multiple requests pass the single-use validation before any request marks the token as consumed
4. Each successful request receives a new access token and potentially a new refresh token
5. This effectively defeats refresh token rotation, allowing the attacker to maintain multiple valid sessions

The vulnerability requires precise timing and high concurrency to exploit reliably, explaining the network attack vector with high complexity designation. For detailed technical information, see the Red Hat CVE-2026-1035 Advisory and Red Hat Bug Report #2430314.

Detection Methods for CVE-2026-1035

Indicators of Compromise

• Multiple successful token refresh operations using the same refresh token within a short time window (milliseconds)
• Unusual patterns of concurrent token refresh requests from the same client or IP address
• Detection of multiple valid access tokens associated with a single refresh token lineage
• Audit logs showing rapid, repeated token refresh requests that would normally be rejected

Detection Strategies

• Implement log analysis rules to detect multiple successful token refresh operations with identical refresh token identifiers
• Monitor for anomalous spikes in concurrent token endpoint requests from single sources
• Configure alerting on token refresh patterns that deviate from normal client behavior baselines
• Utilize SentinelOne Singularity Platform to monitor authentication service behavior and detect exploitation attempts

Monitoring Recommendations

• Enable detailed audit logging for all token refresh operations in Keycloak
• Correlate token refresh events with session management logs to identify inconsistencies
• Monitor database query patterns for the token storage tables to detect race condition exploitation
• Implement real-time alerting on authentication anomalies through SentinelOne's behavioral AI capabilities

How to Mitigate CVE-2026-1035

Immediate Actions Required

• Review your Keycloak deployment configuration to assess exposure to this vulnerability
• Monitor token refresh logs for signs of exploitation while awaiting patches
• Consider implementing additional rate limiting on token refresh endpoints as a defense-in-depth measure
• Evaluate whether strict refresh token rotation is critical for your security posture and assess risk tolerance

Patch Information

Consult the Red Hat CVE-2026-1035 Advisory for official patch information and updates from Red Hat. Monitor the Red Hat Bug Report #2430314 for ongoing remediation progress and patch availability announcements.

Organizations should subscribe to Red Hat security announcements and Keycloak project updates to receive notification when patches become available. Apply security updates promptly once released by the vendor.

Workarounds

• Implement strict rate limiting on the token endpoint to reduce the feasibility of concurrent exploitation attempts
• Consider deploying a reverse proxy or API gateway with request queuing to serialize token refresh requests per client
• If refresh token rotation is not critical to your security model, consider temporarily disabling strict rotation until patches are available
• Implement additional session monitoring and anomaly detection at the application layer

# Example: Configure rate limiting in nginx for Keycloak token endpoint
# Add to your nginx server block configuration

limit_req_zone $binary_remote_addr zone=token_limit:10m rate=2r/s;

location /auth/realms/*/protocol/openid-connect/token {
    limit_req zone=token_limit burst=5 nodelay;
    proxy_pass http://keycloak_backend;
}