Keycloak CVE-2026-9087

Exploitation requires (1) Keycloak's account-linking flow to be reachable for the targeted realm and IdP - i.e., a configured idpAlias that supports user-initiated or admin-initiated linking; (2) the attacker to control a second, distinct upstream account on the same IdP (idpAlias) used by the victim - feasible for public/social IdPs, much harder for closed enterprise IdPs; (3) victim user interaction (CVSS UI:R) to complete the upstream verification step under attacker direction (e.g., clicking a crafted linking URL while authenticated to the upstream IdP); and (4) the attacker to know or guess the victim's local userId and the target idpAlias. No Keycloak credentials are needed on the attacker side (CVSS PR:N), and the network attack vector means the flow is exercised over normal HTTPS. Limiting factors: realms that disable account linking, IdPs where obtaining a second account is non-trivial, and the requirement for victim interaction within the linking flow all materially reduce realistic exploitability.

Signals diverge: CVSS 3.1 is 8.1 with AV:N/AC:L/PR:N/UI:R (high confidentiality and integrity, no availability impact), and CISA SSVC rates Technical Impact as total, which would normally argue for prioritization. However, EPSS is only 0.03% (8th percentile), SSVC Exploitation is 'none', Automatable is 'no', and no public exploit identified at time of analysis - consistent with a flaw that is impactful when exploited but requires a targeted setup (controlling a second upstream account on the same IdP and inducing victim interaction in the linking flow). The PR:N rating reflects that the attacker side of the flow does not require Keycloak credentials, but the attacker must control an upstream IdP account, which is an implicit prerequisite not captured by CVSS - so the real exploitability bar is higher than PR:N alone suggests. Net assessment: real but not urgent across the fleet; prioritize patching for Keycloak deployments that broker public or self-service IdPs (e.g., social login, large enterprise federations) where obtaining a second upstream account is trivial.

An attacker registers or already controls a second account on an IdP that the target Keycloak realm brokers (for example, a public OIDC or social provider). The attacker initiates an account-linking flow tied to the victim's local Keycloak userId and idpAlias, then induces the victim - via a phishing link satisfying CVSS UI:R - to complete the upstream verification step; because the cross-session proof is not bound to the upstream subject, the attacker's separate upstream account is accepted as the linked identity. The attacker can subsequently log in to the victim's local Keycloak account via the attacker-controlled upstream account, achieving account takeover; no public exploit identified at time of analysis.