Red Hat Keycloak EUVD-2026-40300

Exploitation requires an attacker to hold the manage-clients permission within the target Keycloak realm - this is a non-default, explicitly assigned delegated administrative role, confirmed by the CVSS PR:H metric. This permission is typically granted in multi-tenant or DevOps-oriented Keycloak deployments where application teams manage their own client registrations. Exploitation is specifically enabled by Keycloak's failure to enforce privilege-tier restrictions when configuring role mappers, meaning the role mapper creation feature itself must be accessible (no additional non-default configuration is required beyond holding manage-clients). Exploitation is limited by: the requirement for an existing authenticated user account with manage-clients; the absence of this permission in most standard user accounts; and the need for network access to the Keycloak admin console or REST API endpoint. Default installations where only the realm-admin role holds manage-clients are not practically exposed beyond insider threat scenarios.

The NVD CVSS 3.1 score of 6.5 reflects the PR:H prerequisite that meaningfully constrains exploitation to users who have already been explicitly granted manage-clients. Despite C:H and I:H impact metrics - reflecting full token compromise and realm control - the score is kept moderate by the high-privilege requirement and absence of a scope change in Red Hat's scoring. However, independently assessed, the jump from manage-clients to realm-admin is a classic privilege boundary crossing that arguably warrants S:C (scope changed), which would raise the severity considerably. There is no EPSS data provided to quantify exploitation probability, no CISA KEV listing, and no public POC, meaning real-world urgency is currently moderate rather than critical. The most significant real-world risk is in multi-tenant or delegated-admin Keycloak deployments where manage-clients permissions are distributed to non-realm-admin operators or external teams - exactly the scenario Keycloak's permission model is designed to support. In those environments, the assumed trust boundary between manage-clients and realm-admin is completely broken. Environments where only full realm admins hold manage-clients are effectively not exposed to meaningful exploitation beyond insider threat.

A Keycloak operator with manage-clients permission - such as a developer or tenant administrator in a multi-tenant deployment - accesses the admin console or REST API and injects a hardcoded role mapper targeting the realm-admin role into a client they control. When any user subsequently authenticates through that client, the issued JWT contains the realm-admin role claim, and the attacker (or a user they control) can present this token to Keycloak admin APIs to gain full control over the realm, including the ability to create accounts, modify other clients, and access all protected resources. No public POC has been identified, but the technique is straightforward for anyone familiar with Keycloak's admin API.