CVE-2026-1035 identifies a time-of-check to time-of-use (TOCTOU) race condition vulnerability in the Red Hat Build of Keycloak, specifically within the TokenManager class responsible for enforcing refresh token reuse policies. When strict refresh token rotation is enabled—a security feature designed to prevent reuse of refresh tokens—the validation and update operations for refresh token usage are not performed atomically. This lack of atomicity means that if multiple refresh requests occur concurrently, they can bypass the single-use enforcement mechanism, allowing multiple access tokens to be issued from the same refresh token. This undermines the security guarantees of refresh token rotation, potentially allowing an attacker to reuse tokens beyond their intended single-use scope. The vulnerability requires network access and low privileges but does not require user interaction. The CVSS v3.1 base score is 3.1, reflecting low severity due to limited impact on confidentiality, integrity, and availability. There are no known exploits in the wild, and no patches or mitigations have been explicitly linked yet. The flaw primarily affects organizations using Red Hat's Keycloak build for identity and access management, especially those enforcing strict refresh token rotation policies.

The primary impact of this vulnerability is the weakening of refresh token rotation security in Keycloak, potentially allowing an attacker to obtain multiple access tokens from a single refresh token. This could lead to extended unauthorized access if an attacker intercepts or obtains a refresh token, as the single-use enforcement designed to limit token reuse is bypassed. While the vulnerability does not directly compromise confidentiality or availability, it degrades the integrity of the token lifecycle management, increasing the risk of token replay attacks. Organizations relying on Keycloak for secure authentication and session management may face increased risk of unauthorized access persistence. The impact is mitigated by the requirement for network access and low privileges, and the absence of known exploits reduces immediate risk. However, in environments with high concurrency and strict token rotation policies, the vulnerability could be exploited to undermine session security.

To mitigate this vulnerability, organizations should monitor Red Hat and Keycloak advisories closely and apply patches or updates as soon as they become available. In the interim, consider the following specific actions: 1) Limit concurrent refresh token requests from clients to reduce race condition windows; 2) Implement additional server-side synchronization or locking mechanisms around refresh token validation and update processes if customization is possible; 3) Review and tighten network access controls to restrict exposure of Keycloak endpoints to trusted clients only; 4) Enhance logging and monitoring to detect abnormal refresh token usage patterns indicative of replay attempts; 5) Educate developers and administrators on the risks of non-atomic token operations and encourage secure coding practices for token management; 6) Evaluate the necessity of strict refresh token rotation in your environment and consider alternative session management strategies if immediate patching is not feasible. These steps go beyond generic advice by focusing on concurrency control and operational monitoring specific to this race condition.