Keycloak CVE-2026-109082

Exploitation requires the Keycloak realm to have the CIBA (Client-Initiated Backchannel Authentication) grant/flow enabled and reachable, and the attacker to act as a public client (no client secret) - the core flaw is that Keycloak does not verify the client is authorized to use the CIBA flow, letting public clients bypass this requirement. Exploitation is critically LIMITED by required user interaction (UI:R): the victim must actively approve the attacker-initiated backchannel login request on their authentication device, so a successful attack depends on social engineering the user. It is further limited by HIGH attack complexity (AC:H) and by CIBA not being enabled in every deployment, which meaningfully narrows the real-world attack surface below what the network/unauthenticated vector alone suggests.

This is a medium-severity (CVSS 6.8) authentication/authorization flaw in Keycloak's CIBA implementation, and the signals are consistent with a real-but-conditional threat rather than a mass-exploitation emergency. The CVSS vector (AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N) shows an unauthenticated (PR:N), network-reachable issue with HIGH confidentiality and integrity impact (account takeover), but it is tempered by AC:H (the attacker must orchestrate a CIBA flow) and UI:R (the victim must approve the login request) - meaning exploitation depends on successful social engineering, not a purely automated attack. No EPSS score, KEV listing, or public POC was provided in the input, so there is no evidence of active exploitation or widespread weaponization. The flaw is genuine and worth patching promptly in CIBA-enabled deployments, but the combination of high attack complexity plus required user interaction places it below drop-everything priority. Note a nuance: the vector marks PR:N (unauthenticated) while the root cause is that public clients bypass the authorization check - this is an authorization-weakness being exploited by an unauthenticated/secret-less client, not a contradiction, but defenders should confirm whether their deployment actually exposes CIBA to public clients.

An attacker leverages a public client (one with no client secret) to initiate a Client-Initiated Backchannel Authentication flow against a target user, which Keycloak fails to verify the client is authorized to use. The attacker then socially engineers the victim into approving the backchannel login prompt on their authenticator/device, and upon approval the attacker obtains tokens granting full access to the victim's account without ever possessing a client secret. No public exploit identified at time of analysis, so this reflects the described mechanism rather than observed in-the-wild activity.