Red Hat Keycloak EUVD-2026-45173

Exploitation requires the attacker to hold an active Keycloak delegated administrator account with explicit organization management permissions - this is not a default or low-barrier role. The Keycloak organizations feature must be enabled and actively configured on the target deployment; instances not using the organizations capability are not affected. The attacker must have authenticated API access to the Keycloak instance. Exploitation is strictly bounded by PR:H: unauthenticated users and standard (non-delegated) users cannot exploit this flaw. The integrity impact is limited to unauthorized user account creation and organization membership manipulation - there is no confidentiality exposure (no data exfiltration) and no availability disruption. Non-Red Hat upstream Keycloak deployments may also be affected but are not covered by Red Hat's CPE scope.

The CVSS 4.9 score (AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N) accurately captures the primary risk limiter: PR:H requires the attacker to already hold a delegated administrator account with explicit organization management permissions. This constrains the realistic threat population to malicious insiders or attackers who have already compromised such an account. No EPSS score was provided, so probabilistic exploitation likelihood cannot be quantified from the available data. Neither CISA KEV listing nor any proof-of-concept code has been identified at time of analysis, which is consistent with the medium severity and high privilege prerequisite. The I:H signal is meaningful in practice: unauthorized user creation in Keycloak can cascade into downstream applications and services that rely on Keycloak for identity federation, potentially enabling unauthorized access to those services. Organizations that use Keycloak's organizations feature with delegated admins should treat this as a real priority; those not using delegated organization management are not in the attack surface.

A delegated Keycloak organization administrator - granted org management but not user management permissions - sends an invitation to a fabricated, non-existent email address. Rather than waiting for (or relying on) email delivery, the administrator immediately queries the Keycloak API to retrieve the secret registration token embedded in that invitation. Using the recovered token URL, the administrator registers a new user account under their control and enrolls it in the organization, effectively backdooring the org with an account that bypasses the normal user provisioning approval chain. No public proof-of-concept has been identified at time of analysis.