CVE-2026-15572: Keycloak Privilege Escalation Vulnerability

CVE-2026-15572 Overview

CVE-2026-15572 is a high-severity privilege escalation flaw in Keycloak's Dynamic Client Registration (DCR) security policy management. The Allowed Protocol Mapper Types policy restricts which data mapper types a client can use. However, Keycloak fails to re-validate the mapper type during a client update when the mapper's configuration remains unchanged. An attacker with client registration privileges can register an allowed mapper, then swap its type for a restricted, high-privilege mapper such as one that hardcodes administrative roles. The attacker gains full administrative access to the Keycloak realm. Red Hat has issued advisories RHSA-2026:50846 through RHSA-2026:50849 to address the flaw.

Critical Impact
Authenticated attackers with client registration privileges can bypass protocol mapper restrictions and obtain full administrative control of the affected Keycloak realm.

Affected Products

Red Hat build of Keycloak (see RHSA-2026:50846, RHSA-2026:50847, RHSA-2026:50848, RHSA-2026:50849)
Red Hat Single Sign-On distributions relying on Dynamic Client Registration
Upstream Keycloak deployments exposing DCR with the Allowed Protocol Mapper Types policy

Discovery Timeline

2026-08-05 - CVE-2026-15572 published to NVD
2026-08-05 - Last updated in NVD database
2026-08-05 - Red Hat security advisories RHSA-2026:50846–RHSA-2026:50849 released

Technical Details for CVE-2026-15572

Vulnerability Analysis

The flaw is a type confusion issue [CWE-843] in Keycloak's DCR update logic. The Allowed Protocol Mapper Types client policy enforces which protocol mappers a client may include. Enforcement runs when a mapper's configuration changes, but the code path skips revalidation when the configuration payload is identical to the stored value. An attacker exploits this gap by decoupling the mapper's protocolMapper identifier from its configuration during an update. The result is that a mapper previously accepted as benign can be substituted with a high-privilege implementation, such as the hardcoded role mapper, without triggering policy checks. Because Keycloak issues tokens based on the resulting mapper set, the attacker obtains tokens carrying administrative roles for the realm.

Root Cause

The root cause is incomplete input validation during client updates. Keycloak treats mapper type and mapper config as a single validation unit and short-circuits policy evaluation when the configuration hash is unchanged. This design assumption breaks when the type field is mutated independently, allowing a restricted mapper class to be loaded despite an active Allowed Protocol Mapper Types policy.

Attack Vector

Exploitation requires network access to the Keycloak admin or DCR endpoints and low-privilege credentials sufficient to register or update a client via the DCR API. The attacker first registers a client containing a permitted mapper (for example, a user attribute mapper) with a configuration crafted to match the hardcoded role mapper's expected fields. The attacker then sends a client update request that changes only the mapper's protocolMapper type to the restricted mapper, leaving the configuration bytes untouched. Keycloak accepts the update without re-running the policy, and subsequent OpenID Connect tokens issued to the client include the injected administrative role claim.

No public proof-of-concept code is available. See the Red Hat CVE Summary for CVE-2026-15572 and Red Hat Bug #2499592 for vendor technical details.

Detection Methods for CVE-2026-15572

Indicators of Compromise

Keycloak audit events showing CLIENT_UPDATE operations where a protocolMappers entry's protocolMapper field changed but its config object did not.
Newly issued access tokens containing administrative realm roles for service accounts tied to dynamically registered clients.
Creation of protocol mappers of type oidc-hardcoded-role-mapper or saml-hardcoded-role-mapper on clients that previously used only user attribute or property mappers.

Detection Strategies

Enable Keycloak admin event logging and forward CLIENT_UPDATE, CLIENT_REGISTER, and PROTOCOL_MAPPER events to a SIEM for correlation.
Alert on any client update where the mapper type transitions from an allowed type to a hardcoded role or group mapper.
Baseline the population of protocol mappers per client and flag deviations, particularly additions of role-carrying mappers on clients created through DCR.

Monitoring Recommendations

Monitor issuance of tokens containing realm-admin, create-realm, or other privileged realm roles to non-interactive clients.
Review DCR initial access tokens and rotate any that were valid before patching.
Track authentication events from clients registered via DCR and correlate with downstream administrative API calls.

How to Mitigate CVE-2026-15572

Immediate Actions Required

Apply the Red Hat fixes referenced in RHSA-2026:50846, RHSA-2026:50847, RHSA-2026:50848, and RHSA-2026:50849 to all Keycloak and Red Hat build of Keycloak instances.
Audit every client created or updated through Dynamic Client Registration and remove any unexpected hardcoded role or group mappers.
Rotate DCR initial access tokens and revoke sessions and refresh tokens for clients suspected of tampering.
Restrict DCR endpoints to trusted networks and require initial access tokens for registration.

Patch Information

Red Hat released fixed packages under advisories RHSA-2026:50846, RHSA-2026:50847, RHSA-2026:50848, and RHSA-2026:50849. The patch enforces re-validation of the protocolMapper type on every client update regardless of whether the mapper configuration changed. Administrators should apply the vendor-supplied packages that match their Keycloak distribution and restart the affected server.

Workarounds

Disable Dynamic Client Registration on affected realms until patching is complete.
Remove the Allowed Protocol Mapper Types policy dependency by requiring administrator approval for all client creations and updates.
Restrict the manage-clients and DCR roles to a minimal set of trusted service accounts and enforce network-level access controls on the registration endpoints.

bash

# Temporarily disable anonymous Dynamic Client Registration on a realm
kcadm.sh update realms/<realm> -s registrationAllowed=false
kcadm.sh update realms/<realm>/client-registration-policy/anonymous -s enabled=false