Red Hat Build Of Keycloak EUVD-2026-18208

Keycloak installations with SingleUseObjectProvider enabled (default configuration). Remote unauthenticated attacker can forge authorization codes. Requires knowledge of valid client IDs and redirect URIs. No victim interaction needed. Affects Keycloak versions using vulnerable SingleUseObjectProvider without proper type/namespace isolation.

This vulnerability presents elevated real-world risk despite requiring high attack complexity. The CVSS 7.4 score reflects critical factors: network-based attack vector (AV:N) requiring no user interaction (UI:N) or privileges (PR:N), with high impact to confidentiality and integrity (C:H/I:H). The AC:H rating suggests exploitation requires sophisticated understanding of Keycloak's internal token management, precise timing, or specific environmental conditions-likely involving race conditions or collisions in the key-value store. No confirmed active exploitation exists (not present in CISA KEV), and no public exploit code has been identified, reducing immediate risk. However, the privilege escalation potential to admin-level access makes this a critical concern for identity infrastructure. Organizations using Keycloak as their authentication backbone face substantial risk if exploited, as admin tokens grant full control over user accounts, clients, and realm configuration. The lack of authentication requirements (PR:N) significantly lowers the barrier for remote attackers who can reach the Keycloak server. SSVC consideration: while not currently automatable due to AC:H complexity, the technical impact (admin access) is severe, warranting prioritized patching in production IAM deployments.

An unauthenticated attacker with network access to a Keycloak server identifies the SingleUseObjectProvider's namespace isolation weakness through reconnaissance of the token endpoint behavior. The attacker crafts a series of carefully-timed requests that insert malicious entries into the global key-value store, exploiting the lack of type checking to create entries that appear as legitimate authorization codes to Keycloak's token validation logic. By presenting this forged authorization code to the token endpoint, the attacker bypasses the normal OAuth 2.0 authentication flow and receives a valid access token with administrative privileges. With the admin token, the attacker gains full control over the Keycloak realm, including the ability to create backdoor accounts, extract credential hashes, modify client configurations, and potentially pivot to protected downstream applications trusting Keycloak's authentication assertions.