CVE-2026-54641 in OpenRemoteinfo

Summary

by MITRE • 10/13/2026

OpenRemote is an open-source internet-of-things platform. Prior to 1.24.2, the get, getUserClientRoles, and getUserRealmRoles methods in manager/src/main/java/org/openremote/manager/security/UserResourceImpl.java authorize callers with the read:admin role without confirming that the target UUID belongs to the requested and authenticated realm. A realm administrator can supply a user identifier from another tenant or the master realm and retrieve that user's profile, client roles, and realm roles, breaking tenant isolation and exposing privileged account information. This issue is fixed in version 1.24.2.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 10/13/2026

OpenRemote serves as an open-source platform for managing internet-of-things devices, relying heavily on robust identity management to maintain security across multi-tenant deployments. In versions prior to 1.24.2, a critical authorization flaw exists within the user resource implementation located in manager/src/main/java/org/openremote/manager/security/UserResourceImpl.java. The vulnerability specifically affects three methods: get, getUserClientRoles, and getUserRealmRoles. These endpoints are designed to retrieve detailed profile information for users, including their associated client roles and realm-level permissions. While these operations require the read:admin role for execution, the underlying logic fails to validate that the target user identifier belongs to the same tenant or realm as the authenticated administrator initiating the request.

The core technical flaw is a broken access control mechanism where the system authorizes requests based solely on the caller's administrative privileges without verifying the scope of those privileges relative to the requested resource. A realm administrator, who should only have visibility into users within their own specific domain, can supply a user identifier from a different tenant or even the master realm. By doing so, the application retrieves and returns sensitive profile data, client roles, and realm roles for that external user. This behavior fundamentally breaks the principle of multi-tenant isolation, allowing administrators to access information they are not authorized to view based on their assigned scope.

The operational impact of this vulnerability is significant in environments where OpenRemote manages multiple distinct organizations or departments with separate security domains. An attacker who obtains valid credentials for a realm administrator account can exploit this flaw to enumerate users across other tenants. This exposure reveals privileged account information, including role assignments that could facilitate further attacks such as privilege escalation or lateral movement within the broader infrastructure. The leakage of user profiles and role mappings provides attackers with valuable intelligence about the security posture of adjacent tenants, potentially aiding in targeted social engineering or more sophisticated intrusion attempts against higher-privilege accounts in those other domains.

This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically reflecting a failure to enforce proper restrictions on authorized individuals accessing specific resources. From an offensive security perspective, this behavior is consistent with ATT&CK technique T1078, Valid Accounts, as it allows an authenticated user to leverage their existing credentials to access unauthorized data across trust boundaries. The lack of tenant-aware validation in the API endpoints creates a direct path for cross-tenant data exfiltration without requiring additional exploitation steps beyond credential theft or compromise.

To mitigate this risk, organizations running OpenRemote must upgrade immediately to version 1.24.2 or later, where the developers have implemented proper checks to ensure that user identifiers are validated against the authenticated realm of the caller. Until an upgrade is performed, administrators should strictly limit access to these endpoints and monitor for unusual patterns in API calls involving cross-tenant resource references. Additionally, implementing strict network segmentation between tenants can help contain potential damage if a single tenant's administrator account is compromised. Regular audits of administrative role assignments and continuous monitoring for anomalous data retrieval activities are recommended practices to detect any exploitation attempts before they lead to significant security breaches.

Responsible

GitHub M

Reservation

06/15/2026

Disclosure

10/13/2026

Moderation

accepted

EPSS

0.00293

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!