Skip to main content
VulnerabilityPublished Updated

CVE-2026-1035: Red Hat build of Keycloak 26.4 · Time-of-check Time-of-use (TOCTOU) Race Condition

Affects Red Hat build of Keycloak 26.4Source CVE Database V5

0

Not known to be exploited · CVSS 3.1 Low.

Data as of 26 Oct 2026, 12:29 UTC

CVSS 3.1 base score
3.1Low
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.3% chance of exploitation in 30 days – higher than 22% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 21 Jan 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Affected software

ProductAffectedFixed in
Red HatRed Hat build of Keycloak 26.4Affected–Fixed in–
Red HatRed Hat build of Keycloak 26.4Affected–Fixed in–
Red HatRed Hat build of Keycloak 26.4.11Affected–Fixed in–
Red HatRed Hat JBoss Enterprise Application Platform 8Affected–Fixed in–
Red HatRed Hat JBoss Enterprise Application Platform Expansion PackAffected–Fixed in–
Red HatRed Hat Single Sign-On 7Affected–Fixed in–

AI-suggested

To mitigate CVE-2026-1035, organizations should prioritize applying any official patches or updates released by Red Hat for Keycloak 26.4 that address this race condition. In the absence of immediate patches, administrators can implement concurrency controls such as synchronizing refresh token validation and update operations to ensure atomicity, preventing simultaneous refresh requests from bypassing single-use enforcement. Rate limiting refresh token requests per user or client can reduce the likelihood of concurrent exploitation. Monitoring and logging refresh token usage patterns for anomalies can help detect potential abuse. Additionally, reviewing and potentially relaxing strict refresh token rotation policies temporarily may reduce risk until a fix is applied. Employing multi-factor authentication and session management best practices can further limit the impact of compromised tokens. Finally, organizations should stay informed about updates from Red Hat and Keycloak communities regarding this vulnerability and apply recommended security advisories promptly.

Description

A flaw was found in the Keycloak server during refresh token processing, specifically 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. 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 can be undermined.

References

Community reviews

Loading reviews…