Keycloak CVE-2026-92358

Exploitation requires a Keycloak realm configured with identity brokering - the first broker login flow and at least one external identity provider must be active, which is a non-default deployment mode rather than an out-of-the-box configuration. The attacker must control an account on that external identity provider (PR:L in the CVSS vector) whose identity was previously linked to the victim's Keycloak account, and the victim must at some earlier point have confirmed an account-linking request from a different browser, which is what creates the residual proof; the attacker cannot fabricate that proof independently. The victim does not need to act again at exploitation time, and the link can be re-established after the victim manually removes it, so the only real window-limiting factor is whether the leftover proof has been cleared by a fix, by deleting the federated identity record at the administrative level, or by removing the account. Factors that limit real-world exposure: the high attack complexity and required user interaction from the CVSS vector, the need for a prior trusted relationship between the victim's account and the attacker-controlled external identity, and the fact that realms without IdP federation - including standalone username/password deployments - are not reachable by this attack path at all.

The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N, base 6.4) is internally consistent with the description: the attacker needs network reach to the Keycloak broker endpoint, must control an account at the federated external identity provider (PR:L, attacker is a legitimate but hostile IdP user rather than anonymous), and depends on a prior victim action - confirming an account-linking request from a different browser (UI:R), which drives the AC:H rating. The impact metrics are the part that matters operationally: a successful silent re-link yields full account takeover of the federated user, so C:H/I:H with no availability impact is a fair characterization. Unlike most session-expiration bugs, time does not reduce risk - the stale proof persists until it is explicitly cleaned up, so an unpatched instance stays exploitable indefinitely. The countervailing signal is that exploitation is conditional on identity brokering being enabled and on a specific historical interaction between that victim and that external IdP; a Keycloak deployment used only for local username/password or with no IdPs configured has effectively zero exposure. No EPSS score, proof-of-concept, or KEV entry was supplied, so the correct exploitation status is 'no public exploit identified at time of analysis' - there is nothing in the input supporting a claim of active exploitation. Net assessment: moderate severity, high per-incident impact, narrow precondition set - the kind of flaw that even a mid-sized municipal IT team in malbork should treat as urgent once a fixed build is published, because the IdP is the trust anchor for every downstream application. Confidence in the risk picture is limited by the absence of EPSS, patch version, and any vendor statement on exploitability.

An attacker who controls an account at an external identity provider that a victim has previously linked (for example a shared or later-compromised social account) waits for or induces the victim to unlink that identity from their Keycloak account. Because the account-linking proof from the original confirmation was never cleared, the attacker presents the same external identity to the broker login flow and the link is silently re-established, granting the attacker a fully authenticated session as the victim. No phishing or further user interaction is required after the initial link confirmation, which makes the attack quiet and repeatable.