CVE-2026-1035: 
Java vulnerability analysis and mitigation

CVE-2026-1035 is a Time-of-Check Time-of-Use (TOCTOU) race condition vulnerability in the Keycloak server's refresh token processing logic, specifically within the TokenManager class. When strict refresh token rotation is enabled (refreshTokenMaxReuse set to zero), the validation and update of refresh token usage are not performed atomically, allowing concurrent refresh requests to bypass single-use enforcement and obtain multiple valid access tokens from a single refresh token. The vulnerability affects org.keycloak:keycloak-services versions up to and including 26.2.5, and was disclosed on January 21, 2026 (Red Hat CVE, GitHub Advisory). It carries a CVSS v3.1 base score of 3.1 (Low), assigned by Red Hat (Red Hat CVE).

The root cause is classified as CWE-367 (Time-of-check Time-of-use Race Condition). The flaw resides in the validateTokenReuse method of the TokenManager class: when a refresh token is submitted, Keycloak checks whether it has already been used and then updates the usage counter in two separate, non-atomic operations. An attacker with a valid refresh token can exploit this window by sending multiple concurrent token refresh requests before the usage counter is incremented, causing all requests to pass the single-use check and each receiving a distinct, valid access token (Red Hat Bugzilla, GitHub Advisory). Exploitation requires network access and low-level privileges (a valid refresh token), but has high attack complexity due to the need for precise timing of concurrent requests (Red Hat CVE).

Successful exploitation undermines Keycloak's refresh token rotation hardening, allowing an attacker who possesses a single refresh token to obtain multiple valid access tokens. This primarily affects integrity (low impact per CVSS), as the attacker can extend the effective lifetime of a compromised refresh token and maintain unauthorized session access beyond what the strict rotation policy intends. There is no direct confidentiality or availability impact, but the ability to reuse a refresh token could facilitate session persistence or unauthorized access to protected resources in downstream applications relying on Keycloak for authentication (GitHub Advisory, Red Hat Bugzilla).

1. Obtain a valid refresh token: Authenticate to a Keycloak instance (with strict refresh token rotation enabled) as a legitimate or compromised low-privileged user to receive an initial refresh token via the standard OAuth2/OIDC token endpoint.
2. Identify the token endpoint: Locate the Keycloak realm's token endpoint, typically at https://<keycloak-host>/realms/<realm>/protocol/openid-connect/token.
3. Craft concurrent refresh requests: Prepare multiple simultaneous HTTP POST requests to the token endpoint, each using the same refresh token and the grant_type=refresh_token parameter.
4. Race the TOCTOU window: Send all concurrent requests at the same time (e.g., using threading in Python, curl --parallel, or a load testing tool like ab or wrk) to exploit the non-atomic check-then-update in validateTokenReuse.
5. Collect multiple access tokens: If the race condition is won, multiple requests will pass the single-use check before the usage counter is updated, and each will receive a distinct, valid access token — effectively bypassing the refresh token rotation policy (Red Hat Bugzilla, GitHub Advisory).

• Network: Multiple simultaneous or near-simultaneous HTTP POST requests to /realms/<realm>/protocol/openid-connect/token with the same refresh_token value originating from the same client IP or user agent within milliseconds of each other.
• Logs: Keycloak server logs showing the same refresh token being accepted and exchanged for access tokens more than once (e.g., duplicate token IDs in audit/event logs); events of type REFRESH_TOKEN for the same token ID appearing multiple times in rapid succession.
• Application: Multiple active sessions or access tokens issued to the same user within an unusually short time window, especially when strict token rotation is configured.

Red Hat has addressed CVE-2026-1035 in Red Hat build of Keycloak 26.4.11, released via security advisories RHSA-2026:6477 and RHSA-2026:6478 on April 2, 2026 (Red Hat Errata). The upstream Keycloak project addressed the issue in release 26.5.6 (Keycloak Release). IBM DataPower Operations Dashboard users should refer to IBM's advisory for applicable fixes (IBM Advisory). As a workaround, organizations may consider disabling strict refresh token rotation (though this reduces security posture) or implementing rate limiting and concurrency controls at the reverse proxy or API gateway layer to reduce the feasibility of concurrent token refresh attacks.

The vulnerability received limited public attention given its low CVSS score and high exploitation complexity. It was noted in the Keycloak 26.5.6 release announcement and included alongside higher-severity CVEs in the Red Hat build of Keycloak 26.4.11 security advisory (Red Hat Errata). A brief technical write-up was published by Infinitsec covering the TOCTOU race condition mechanics (Infinitsec).