CVE-2026-49439: OpenRemote IoT Platform Auth Bypass Flaw

CVE-2026-49439 Overview

CVE-2026-49439 is a missing authorization vulnerability [CWE-862] in OpenRemote, an open-source Internet-of-Things (IoT) platform. Prior to version 1.24.1, the predicted datapoint write endpoint allows users holding only the read:assets privilege to write predicted datapoints. The authorization check confirms read access but does not verify that the caller has write permissions on the target attribute. This lets low-privileged users inject predicted values into assets they should only be able to view, undermining data integrity in downstream analytics and automation rules.

Critical Impact
Authenticated users with read-only asset privileges can write predicted datapoint values, corrupting IoT time-series data and potentially influencing automation logic that consumes those predictions.

Affected Products

OpenRemote Manager versions prior to 1.24.1
OpenRemote IoT platform deployments exposing the predicted datapoint REST endpoint
Any integration relying on predicted datapoint integrity for automation or analytics

Discovery Timeline

2026-09-11 - CVE-2026-49439 published to NVD
2026-09-14 - Last updated in NVD database

Technical Details for CVE-2026-49439

Vulnerability Analysis

The vulnerability resides in AssetPredictedDatapointResourceImpl.java within the OpenRemote Manager module. The predicted datapoint write endpoint performs an authorization check that validates the presence of the read:assets role but omits a corresponding write-permission check for the targeted attribute. As a result, any authenticated user granted read access to assets can submit predicted datapoint values through the endpoint.

Predicted datapoints feed forecasting, dashboards, and rule engines in OpenRemote deployments. An attacker abusing this endpoint can inject arbitrary time-series values, skew forecasts, and influence rule-based automations that key off predicted trends. Because the endpoint accepts values without validating the caller's write authorization, this is a broken access control issue rather than a code execution flaw.

Root Cause

The root cause is missing authorization enforcement [CWE-862] on the predicted datapoint write path. Only the read role is validated, and restricted-user checks on the attribute occur after the authorization decision that should have blocked the write. Version 1.24.1 restructures the check order and ensures the attribute is resolved and gated before write acceptance.

Attack Vector

Exploitation requires network access to the OpenRemote Manager API and a valid account with the read:assets role. The attacker sends a crafted HTTP request to the predicted datapoint write endpoint referencing an asset and attribute they can read, submitting attacker-controlled predicted values. No user interaction is required.

java

                throw new WebApplicationException(Response.Status.FORBIDDEN);
            }

+           Attribute<?> attribute = asset.getAttribute(attributeName).orElseThrow(() ->
+               new WebApplicationException(Response.Status.NOT_FOUND)
+           );
+
            // If logged in, user should have READ ASSETS role
            if(isAuthenticated() && !hasResourceRole(ClientRole.READ_ASSETS.getValue(), Constants.KEYCLOAK_CLIENT_ID)) {
                LOG.info("Forbidden access for user '" + getUsername() + "': " + asset.getRealm());
                throw new WebApplicationException(Response.Status.FORBIDDEN);
            }

-           Attribute<?> attribute = asset.getAttribute(attributeName).orElseThrow(() ->
-               new WebApplicationException(Response.Status.NOT_FOUND)
-           );
-
            // If restricted, the attribute should also be restricted
            if(isRestrictedUser()) {
                attribute.getMeta().getValue(MetaItemType.ACCESS_RESTRICTED_READ).ifPresentOrElse((v) -> {

Source: OpenRemote patch commit 583dbbf. The patch reorders resolution of the target attribute and tightens the authorization flow so that read-only users cannot proceed to the write path.

Detection Methods for CVE-2026-49439

Indicators of Compromise

Unexpected HTTP PUT or POST requests to the predicted datapoint API originating from accounts that possess only the read:assets Keycloak role.
Predicted datapoint values that diverge sharply from historical patterns or from values produced by legitimate prediction services.
Repeated writes to predicted datapoints targeting attributes the calling user has never written to before.

Detection Strategies

Review OpenRemote Manager access logs for calls to the predicted datapoint write endpoint and correlate the caller's Keycloak role assignments.
Compare write activity against expected service accounts; predicted datapoint writes should typically originate from integration or prediction service identities.
Alert on schema anomalies in the predicted datapoint time-series that coincide with requests from low-privileged users.

Monitoring Recommendations

Enable verbose request logging on the OpenRemote Manager REST API and forward logs to a centralized analytics platform.
Baseline predicted datapoint write volume per user and role, and alert on deviations.
Monitor Keycloak audit logs for accounts that hold read:assets but exhibit write-like API behavior.

How to Mitigate CVE-2026-49439

Immediate Actions Required

Upgrade OpenRemote to version 1.24.1 or later, which enforces authorization on the predicted datapoint write endpoint.
Audit Keycloak role assignments and remove read:assets from accounts that do not require it.
Review predicted datapoint history for anomalous writes since deployment and revert corrupted series where feasible.

Patch Information

The fix is delivered in OpenRemote 1.24.1 via commit 583dbbf. See the OpenRemote GitHub Security Advisory GHSA-xj53-j257-hxvg and the patch commit for implementation details.

Workarounds

Restrict network access to the OpenRemote Manager API using a reverse proxy or network policy that blocks the predicted datapoint write endpoint for non-service identities.
Temporarily revoke the read:assets role from untrusted users until the upgrade is applied.
Place a Web Application Firewall (WAF) rule in front of the Manager API to deny predicted datapoint write methods from clients lacking a service token.

bash

# Upgrade OpenRemote Manager container to the patched release
docker pull openremote/manager:1.24.1
docker compose up -d manager

# Verify the running version
curl -s https://<openremote-host>/api/master/info | jq '.version'