OpenRemote Manager CVE-2026-41166

Attacker must hold the write:admin client role in any Keycloak realm configured within the OpenRemote deployment. Attacker must possess or control a user UUID in the target realm they wish to compromise (typically master realm) - this could be their own low-privilege account in master, a service account, or any user whose credentials they can obtain after privilege escalation. Multi-realm Keycloak deployment is required; single-realm deployments do not expose the cross-realm attack surface. The Manager API endpoint /api/{realm}/user/{target-realm}/userRealmRoles/{userId} must be network-accessible to the attacker, which is the default configuration in standard OpenRemote deployments. Exploitation does NOT require the attacker to already have admin privileges (contradicting CVSS PR:N) but DOES require low-privilege authenticated access (write:admin role), suggesting CVSS vector may be misscored. The high attack complexity (AC:H) reflects the need to discover valid user UUIDs in the target realm and understand the multi-realm architecture, though Keycloak APIs often expose user enumeration capabilities that lower this barrier.

This represents a critical privilege escalation path despite the CVSS 7.0 (High) base score. The CVSS vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:L indicates network-accessible exploitation with high attack complexity and no privileges required, which appears inconsistent with the actual exploitation conditions. The description clearly states an attacker must first possess write:admin role in any realm and control a user UUID in the target realm - both PR:L (low privileges required) prerequisites not reflected in PR:N. This discrepancy suggests the CVSS vector may be incorrectly scored or the attack scenario involves an unauthenticated step not detailed in the description. Real-world risk is HIGH for multi-tenant OpenRemote deployments where different realms represent trust boundaries (e.g., separate customer environments). The attack grants complete Keycloak master realm control, enabling the attacker to create users, modify all realm configurations, and pivot to infrastructure access. EPSS data not available. Not listed in CISA KEV, indicating no confirmed widespread exploitation, though the detailed PoC in GitHub advisory GHSA-49vv-25qx-mg44 significantly lowers the barrier to exploitation. Attack complexity is rated High (AC:H) likely due to requiring specific knowledge of target user UUIDs and realm names, but this is easily obtainable through reconnaissance in most deployments. The high integrity impact (I:H) accurately reflects the severity of unauthorized realm role manipulation.

An attacker creates a user account in a newly provisioned Keycloak realm (e.g., 'tenant-acme') and obtains the write:admin OpenRemote client role through legitimate access or social engineering. They enumerate the master realm via Keycloak's public endpoints to discover a low-privilege user UUID (e.g., a service account or dormant user). Using their tenant-acme credentials, they authenticate to the OpenRemote Manager API and craft a PUT request to /api/tenant-acme/user/master/userRealmRoles/{target-uuid} with payload ["admin"]. The vulnerable updateUserRealmRoles handler processes the 'master' realm parameter without validating authorization, granting the admin role in master realm to the target user UUID. The attacker then authenticates as that master realm user and gains full Keycloak administrator access, enabling them to create backdoor accounts, extract secrets, modify authentication flows, or compromise all tenant realms.