Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:L
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:L
Lifecycle Timeline
7Blast Radius
ecosystem impact- 5 maven packages depend on io.openremote:openremote-manager (5 direct, 0 indirect)
Ecosystem-wide dependent count for version 1.22.1.
DescriptionGitHub Advisory
Summary
A user who has write:admin in one Keycloak realm can call the Manager API to update Keycloak realm roles for users in another realm, including master. The handler uses the {realm} path segment when talking to the identity provider but does not check that the caller may administer that realm. This could result in a privilege escalation to master realm administrator if the attacker controls any user in master realm.
Details
In manager/src/main/java/org/openremote/manager/security/UserResourceImpl.java, there is no check to validate if the caller should be able to administer a realm they're trying to update.
@Override
public void updateUserRealmRoles(RequestParams requestParams, String realm, String userId, String[] roles) {
try {
identityService.getIdentityProvider().updateUserRealmRoles(
realm,
userId,
roles);
} catch (ClientErrorException ex) {
ex.printStackTrace(System.out);
throw new WebApplicationException(ex.getCause(), ex.getResponse().getStatus());
} catch (Exception ex) {
throw new WebApplicationException(ex);
}
}PoC
- Create a new Keycloak realm other than
master. Add a user and grant that user the OpenRemote client rolewrite:admin. Remember the realm name (call itNEW_REALM). - In Keycloak realm
master, pick a low-privilege user (noadminrealm role). Copy that user’s UUID (<master-user-uuid>). - Authenticate as the user from step 1 and obtain a Bearer access token (
<token>) forNEW_REALM. - Replace placeholders and run:
curl -k -X PUT "https://<host>/api/<NEW_REALM>/user/master/userRealmRoles/<master-user-uuid>" \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '["admin"]'- In the Keycloak Admin Console, realm master, that user, Role mapping. Confirm the admin realm role is assigned.
Impact
An attacker with the OpenRemote client role write:admin in any realm can call this API with {realm} set to another realm (for example master) and change Keycloak realm roles for users there. That can grant admin on master to a user UUID they target, which gives Keycloak administrator access for the master realm.
AnalysisAI
OpenRemote Manager allows privilege escalation to Keycloak master realm administrator through improper authorization in the Manager API. Users with write:admin permission in any non-master realm can manipulate realm role assignments in other realms, including master, by exploiting missing authorization checks in the updateUserRealmRoles endpoint. An attacker controlling any user in the master realm can grant themselves admin privileges, achieving full Keycloak administrator access. Vendor-released patch version 1.22.1 addresses this vulnerability. No public exploit code identified at time of analysis, though a detailed proof-of-concept is documented in the advisory.
Technical ContextAI
OpenRemote Manager (pkg:maven/io.openremote:openremote-manager) is a Java-based IoT platform that integrates with Keycloak for identity and access management across multiple realms. The vulnerability exists in the UserResourceImpl.java REST API handler, specifically the updateUserRealmRoles method. This endpoint accepts a {realm} path parameter but fails to validate whether the authenticated caller has administrative privileges for that target realm - a classic CWE-284 (Improper Access Control) flaw. The Java code directly forwards the realm parameter to identityService.getIdentityProvider().updateUserRealmRoles() without checking if the caller's write:admin permission scope includes that realm. In Keycloak's multi-tenant architecture, realm isolation is security-critical; the master realm has elevated privileges to manage all other realms. By exploiting this missing authorization boundary check, an attacker with write:admin in realm A can issue API calls targeting realm B (including master), effectively bypassing Keycloak's intended realm isolation model.
RemediationAI
Upgrade OpenRemote Manager to version 1.22.1 or later, which implements proper authorization checks to validate that callers can only administer realms for which they have appropriate permissions. The patch is available via the GitHub release at https://github.com/openremote/openremote/releases/tag/1.22.1 and advisory at https://github.com/openremote/openremote/security/advisories/GHSA-49vv-25qx-mg44. For environments unable to immediately upgrade, implement compensating controls by restricting network access to the Manager API endpoint /api/{realm}/user/{target-realm}/userRealmRoles/{userId} to only trusted administrator networks or localhost, though this significantly degrades functionality. Alternatively, use a reverse proxy or API gateway to enforce additional authorization checks verifying that the authenticated user's realm matches the {target-realm} path parameter before forwarding requests to the Manager API - however this requires custom development and thorough testing to avoid breaking legitimate cross-realm administrative workflows. Audit existing Keycloak realm role assignments, particularly in the master realm, for unauthorized admin role grants that may indicate prior exploitation. Review application logs for suspicious PUT requests to /api/*/user/master/userRealmRoles/* paths originating from non-master realm authentication contexts.
Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m
Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti
Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent
Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug
JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up
Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up
The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow
Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla
The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during
Same weakness CWE-284 – Improper Access Control
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-25096
GHSA-49vv-25qx-mg44