Red Hat Keycloak CVE-2026-12388

Exploitation requires an existing Keycloak account with the identity provider management administrative role - this is a non-default, explicitly delegated privilege that realm administrators must grant. The attack is specific to the 'Hardcoded Role' mapper type within IdP mapper configuration; Keycloak instances with no configured external identity providers or with no delegated IdP admin accounts are not exploitable. CVSS PR:H confirms that standard authenticated users without administrative scope cannot trigger this flaw. Exploitation is further limited to network-accessible Keycloak admin console endpoints (AV:N), meaning airgapped or internally-restricted management planes reduce exposure. The primary limiting factor is the requirement for delegated IdP management access, making this a targeted insider-threat or privilege-boundary-abuse scenario rather than an opportunistic remote attack.

The CVSS 3.1 score of 6.5 (Medium) is derived from vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N. The PR:H requirement is the primary risk limiter: exploitation demands an existing account with identity provider management privileges, which is not a default role and must be explicitly delegated by a realm administrator. This constrains the attack surface to insider-threat and supply-chain scenarios, or environments where IdP admin delegation is broadly distributed. The C:H/I:H impact reflects that successful exploitation yields unrestricted realm control - including the ability to create new admin users, exfiltrate realm configuration, and modify authentication policies. EPSS data is not available in the provided intelligence, so exploitation probability cannot be quantified probabilistically. No CISA KEV listing and no public POC have been identified, so there is no evidence of active or opportunistic exploitation at time of analysis. The real-world priority is elevated in SaaS, MSP, or enterprise SSO deployments with delegated administration models; organizations with monolithic all-or-nothing admin grants face minimal additional exposure.

A semi-trusted administrator - for example, a partner organization's account provisioned with identity provider management scope in a shared Keycloak realm - logs into the Keycloak admin console and navigates to the IdP mapper configuration for any configured external provider. The attacker creates a new Hardcoded Role mapper targeting the built-in realm-admin role; on the attacker's next login through that IdP, the realm-admin role is silently assigned to their account. The attacker then exercises unrestricted realm control, including creating backdoor admin accounts, exporting user credential hashes, or altering authentication flows. No public POC is identified at time of analysis.