Red Hat Keycloak EUVD-2026-30879

Exploitation requires: (1) an authenticated client with at least low-privilege access (CVSS PR:L confirmed), meaning a valid client credential or token within the target Keycloak realm; (2) the Keycloak Authorization Services feature must be enabled and the Protection API must be active on the target realm - deployments not using Authorization Services are not affected; (3) the realm must contain at least two distinct Resource Servers, as the vulnerability involves cross-server UUID access - single-Resource-Server realms are not exposed to the cross-boundary impact; (4) the attacker must know or successfully obtain the UUID of a resource belonging to a different Resource Server, which constitutes the High Attack Complexity (AC:H) condition. Exploitation is limited by the UUID acquisition requirement - brute-forcing 128-bit UUIDs is not feasible, so the attacker depends on a secondary disclosure vector. Authentication level is confirmed as low-privilege (PR:L) by the CVSS vector; unauthenticated access is not sufficient.

The CVSS base score of 6.8 (Medium-High) is meaningful but must be contextualized. The High Attack Complexity (AC:H) is the primary dampening factor: successful exploitation requires the attacker to already possess or successfully enumerate a resource UUID belonging to a different Resource Server in the same realm. UUIDs are not inherently secret but are also not trivially guessable, making brute-force enumeration impractical in most deployments - the attacker likely needs an information disclosure primitive or prior realm-level read access to obtain a valid UUID. The Low Privilege requirement (PR:L) confirms that any legitimate authenticated client can attempt the attack; no administrative role is required. Confidentiality and Integrity impacts are both High, meaning successful exploitation grants full read-modify-delete access to another server's protected resources - a meaningful blast radius in multi-tenant or microservices architectures sharing a Keycloak realm. No EPSS score was provided in the available intelligence, limiting probabilistic exploitation forecasting. There is no CISA KEV listing and no public POC identified, suggesting the vulnerability has not yet been weaponized at scale. Real-world risk is most acute in environments running multiple Resource Servers within a single Keycloak realm with Authorization Services enabled - a common microservices pattern. Single-Resource-Server deployments are not affected by the cross-server boundary issue.

An attacker operating as a legitimate low-privileged client registered under Resource Server A within a multi-tenant Keycloak realm obtains the UUID of a sensitive resource registered by Resource Server B - for example, through an application-layer information disclosure or by observing token claims. The attacker sends a crafted GET request to the Keycloak Protection API endpoint using the obtained UUID, receiving the full resource definition in response without any authorization error. The attacker may then issue PUT requests to modify the resource's attributes or DELETE requests to remove it entirely, causing data tampering or denial of access for the legitimate Resource Server B. No public exploit code has been identified at time of analysis, but the attack is straightforward to implement manually once a valid cross-server UUID is in hand.