CVE-2026-12388: Keycloak IdP Mapper Privilege Escalation – Red Hat Security Advisory
A vulnerability in Keycloak's identity provider mapper system allows administrators with limited permissions to escalate their access to full realm control. By creating a 'Hardcoded Role' mapper, a restricted admin can assign themselves high-level administrative roles like realm-admin, circumventing the permission boundaries that were supposed to limit their authority. This is a privilege escalation vulnerability that turns a controlled administrative account into an unrestricted one.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 6.5 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N
- Weaknesses (CWE)
- CWE-266
- Affected products
- 1 configuration(s)
- Published / Modified
- 2026-06-30 / 2026-07-01
NVD description (verbatim)
A flaw was found in the Identity Provider (IdP) mapper component of Keycloak, which is used to manage how user information from external services is mapped to Keycloak users. An administrator with limited permissions to manage identity providers can exploit this flaw by creating a "Hardcoded Role" mapper that assigns high-level administrative roles (like realm-admin) to themselves or others. This allows a restricted administrator to bypass security checks and gain full control over the entire realm.
2 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
The flaw exists in Keycloak's IdP mapper component, which translates user attributes and roles from external identity sources into Keycloak user models. The mapper fails to properly validate or restrict which roles can be assigned through the 'Hardcoded Role' mapper configuration. An administrator account with limited identity provider management permissions can exploit this to inject administrative roles into their own account or other accounts, bypassing role-based access control (RBAC) enforcement. The vulnerability is classified under CWE-266 (Improper Privilege Management), indicating a fundamental breakdown in permission verification during role assignment.
Business impact
Compromised Keycloak administrators can gain unrestricted control over the entire authentication realm, including the ability to modify other users, grant themselves additional permissions, alter security policies, and potentially access or modify sensitive identity data across all integrated applications. This transforms a limited administrative account into a full realm administrator, enabling attackers to conduct lateral movement, data theft, or service disruption across all systems relying on the Keycloak instance for authentication. Organizations with federated identity architectures face particularly high risk, as Keycloak often serves as a central trust anchor.
Affected systems
Red Hat build of Keycloak is confirmed affected. Any Keycloak instance where administrators have been granted limited permissions (such as manage-identity-providers but not full realm-admin rights) is vulnerable if those administrators have malicious intent or compromised credentials. The vulnerability applies across all deployment models: on-premises, containerized, and cloud-hosted.
Exploitability
Exploitation requires valid administrative credentials with at least limited identity provider management permissions. No public exploit code is known at this time, and the vulnerability does not appear on the KEV (Known Exploited Vulnerabilities) catalog, indicating no evidence of active exploitation in the wild as of the published date. However, the attack is straightforward to execute for anyone holding the required permissions: navigate to identity provider configuration, create or modify a hardcoded role mapper, and add administrative roles. The low complexity (AC:L) and high privilege requirement (PR:H) reflect that while execution is simple, the attacker must already be inside the administrative boundary.
Remediation
Apply security updates from Red Hat addressing CVE-2026-12388 in your Keycloak deployment. Verify the specific patched version against Red Hat's official advisory. In the interim, restrict identity provider management permissions to only highly trusted administrators and implement additional monitoring for role mapper creation and modification events. Review existing identity provider configurations for suspicious hardcoded role assignments, particularly those assigning realm-admin or other high-privilege roles.
Patch guidance
Consult Red Hat's official security advisory for CVE-2026-12388 to identify the patched version(s) for your Keycloak build. Apply updates in a test environment first to ensure compatibility with your federated authentication setup. Since Keycloak often serves as a critical authentication hub, coordinate patching with minimal service windows and test failover procedures. If you are running on Kubernetes or OpenShift, update your container images and redeploy pods after patching. Verify that identity provider mappings continue to function correctly post-patch.
Detection guidance
Monitor Keycloak logs for creation or modification of identity provider mappers, particularly 'Hardcoded Role' mappers that assign sensitive roles. Alert on any role mapper changes that include realm-admin, admin, or other high-privilege roles in the hardcoded assignments. Audit administrative user accounts for unexpected role escalations, especially changes occurring outside of normal administration windows. If available, enable detailed audit logging on identity provider configuration changes. Compare current mapper configurations against your baseline to identify unauthorized additions.
Why prioritize this
Although rated MEDIUM severity (CVSS 6.5), this vulnerability warrants prompt attention because it directly enables privilege escalation within a critical authentication component. Keycloak typically acts as a centralized identity broker; compromise of its administrative controls undermines the security posture of every application depending on it. The requirement for existing administrative access limits the immediate risk to insider threats and lateral movement scenarios, but organizations should not delay patching. Prioritize instances where identity provider management is delegated to multiple administrators.
Risk score, explained
The CVSS 3.1 score of 6.5 (MEDIUM) reflects the combination of high-privilege requirement (PR:H), network-accessible attack vector (AV:N), and low attack complexity (AC:L), balanced against the confidentiality and integrity impact being high (C:H, I:H) while availability is not impacted (A:N). The severity reflects that while the vulnerability is easy to exploit, it requires pre-existing administrative credentials, which reduces exploitability in pure external attack scenarios. However, for organizations concerned with insider threats or credential compromise, the impact reaches the upper end of MEDIUM severity.
Frequently asked questions
Do we need to patch immediately if our Keycloak admins are trusted and not federated across external providers?
Yes, because the vulnerability is an insider-threat vector and applies regardless of the number or type of external identity providers. Additionally, credential compromise, shared access, or disgruntled insiders can create risk. Patching should be prioritized in your standard security update cycle, ideally within 30 days.
Does this vulnerability allow unauthenticated attackers to gain admin access?
No. An attacker must already possess valid administrator credentials with at minimum identity provider management permissions. External, unauthenticated users cannot exploit this directly. However, if an admin account is compromised through phishing, malware, or credential stuffing, this vulnerability becomes a critical escalation path.
Will patching require us to reconfigure our identity provider mappers?
Consult Red Hat's patch release notes for any breaking changes. In most cases, legitimate mapper configurations will continue to function after patching. However, you should test in a non-production environment and validate that user provisioning and role assignment still work correctly before deploying to production.
How can we detect if someone has already exploited this in our environment?
Review Keycloak's audit and event logs for identity provider mapper creation or modification events, particularly any that added realm-admin or other sensitive roles. Check user accounts for unexpected role escalations. If you have external monitoring (SIEM), correlate Keycloak configuration changes with user permission changes. A forensic review of mapper configurations is essential.
This analysis is based on the vulnerability description and CVE metadata current as of the publication date. Specific patch version numbers, remediation timelines, and affected product builds should be verified against Red Hat's official security advisory and product documentation. Exploitation details and proof-of-concept code are not provided. Organizations should conduct their own risk assessment based on their deployment architecture, user access controls, and threat model. This information is for informational purposes and does not constitute official vendor guidance. Source: NVD (public-domain), retrieved 2026-08-09. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-4629MEDIUMKeycloak Privilege Escalation via Role Mapper Injection
- CVE-2026-5136HIGHForeman Usergroup Privilege Escalation Vulnerability
- CVE-2026-9795HIGHKeycloak FGAPv2 Fine-Grained Admin Permissions Bypass
- CVE-2026-10070MEDIUMmacrozheng mall Admin Authorization Bypass in /admin/update/
- CVE-2026-10152MEDIUMImproper Access Control in TaleLin lin-cms-spring-boot Book Endpoint
- CVE-2026-10215MEDIUMDolibarr Leave Request API Authorization Bypass
- CVE-2026-10217MEDIUMGoClaw Privilege Escalation in RoleAdmin Gateway (CVSS 6.3)
- CVE-2026-10218MEDIUMGoClaw Improper Authorization Vulnerability (CVSS 5.4)