Red Hat Keycloak EUVD-2026-45225

Exploitation requires three concurrent conditions: (1) the attacker must possess valid OAuth client credentials (client_id and client_secret) for a client registered in the target Keycloak realm - these are application-level secrets, not user passwords; (2) the target user account must have an active, user-approved CIBA authentication request that was initiated before the account became locked - this means the user must have actively approved the back-channel authentication prompt; and (3) the user account must subsequently enter a locked state due to brute-force protection before the attacker redeems the auth_req_id at the token endpoint. Exploitation is limited by: requirement for valid OAuth client credentials (not anonymous); dependency on user interaction to approve the CIBA request (UI:R); dependency on a race window between CIBA approval and account lockout; and the CIBA flow must be enabled and in use on the affected Keycloak instance - organizations not using CIBA are not affected.

The real-world risk is moderate and scenario-constrained. The CVSS vector AV:N/AC:L/PR:N/UI:R reflects a network-exploitable path with low complexity, but the PR:N designation warrants scrutiny: exploitation requires valid OAuth client credentials, which are application-level secrets, not user-level credentials - this is closer to PR:L in practice. The UI:R requirement is load-bearing: the legitimate target user must actively approve the CIBA authentication request before the lockout occurs, making this a race-condition style attack dependent on external user behavior. The C:L impact is accurate - only access and refresh tokens for a single locked account are disclosed, with no integrity or availability consequence. No EPSS data was provided in the intelligence feed; given the specificity of conditions required (valid client credentials, pending CIBA approval, user locked mid-flow), opportunistic or automated exploitation at scale is unlikely. The CVE is not in the CISA KEV catalog, and no POC exists per available data. This is a genuine but situationally limited security gap - organizations where CIBA is actively used alongside brute-force lockout policies face elevated real-world risk compared to those not using CIBA. The absence of CWE assignment and exact fix version data from the references reduces confidence in scope determination.

An attacker who controls a registered OAuth client in the Keycloak realm initiates a CIBA authentication request for a targeted user account and waits for the user to approve the push notification or out-of-band prompt - which the user does, believing it to be a legitimate sign-in. If the target user's account is then locked by brute-force protection (whether triggered by the attacker on a separate channel or by prior failed attempts), the attacker can still call the CIBA token redemption endpoint with the approved auth_req_id and receive valid access and refresh tokens, effectively bypassing the lockout mechanism. No public POC has been identified, but the exploitation technique is mechanically straightforward for any party already possessing valid client credentials.