CVE-2026-49439: 
Java vulnerability analysis and mitigation

CVE-2026-49439 is a missing authorization vulnerability in OpenRemote's IoT platform that allows users with only read:assets privileges to write predicted datapoints via the PUT /api/{realm}/asset/predicted/{assetId}/{attributeName} endpoint. It affects io.openremote:openremote-manager versions prior to 1.24.1. The vulnerability was published by ebariaux on June 3, 2026, and added to the GitHub Advisory Database on July 6, 2026. It carries a CVSS v3.1 base score of 4.3 (Medium) (GitHub Advisory).

The root cause is CWE-862 (Missing Authorization): the writePredictedDatapoints method in AssetPredictedDatapointResourceImpl.java incorrectly checked the READ_ASSETS role (ClientRole.READ_ASSETS) instead of the WRITE_ATTRIBUTES role when authorizing write operations, allowing the assetPredictedDatapointService.updateValues(...) call to proceed for read-only users. Additionally, the restricted-user path checked ACCESS_RESTRICTED_READ metadata instead of ACCESS_RESTRICTED_WRITE, and unauthenticated access checked ACCESS_PUBLIC_READ instead of ACCESS_PUBLIC_WRITE. The fix (commit 583dbbf) corrects all three permission checks to use write-appropriate roles and metadata (GitHub Advisory, Patch Commit).

Successful exploitation allows any authenticated user with read:assets privileges to tamper with predicted datapoints for any asset within their accessible realm, violating data integrity. In IoT and smart building contexts (OpenRemote's primary use case), corrupted predicted datapoints could mislead automated decision-making systems, affect energy management, or disrupt building automation workflows. There is no confidentiality or availability impact, and the scope is limited to the affected component (GitHub Advisory).

A public proof-of-concept is included in the advisory itself, demonstrating that a user with only read:assets can issue a PUT request to write arbitrary predicted datapoint values and receive an HTTP 204 success response. Exploitation requires only a valid low-privileged account and network access to the API. There is no evidence of in-the-wild exploitation, no known threat actor attribution, and the CVE is not listed in the CISA KEV catalog. The EPSS score is not yet published (GitHub Advisory).

1. Obtain credentials: Acquire or register an account in the target OpenRemote realm with only the read:assets role — no write:assets or WRITE_ATTRIBUTES role is needed.
2. Authenticate: Obtain a valid access token via the OpenRemote Keycloak authentication endpoint for the target realm.
3. Identify target asset: Use the read API (e.g., GET /api/{realm}/asset/{assetId}) to enumerate accessible assets and their attribute names.
4. Craft the write request: Send a PUT request to PUT /api/{realm}/asset/predicted/{assetId}/{attributeName} with a JSON body containing the desired timestamp and value, e.g., [{"x":1779199999001,"y":1337}], and include the Bearer token in the Authorization header.
5. Confirm write: A HTTP 204 response confirms the predicted datapoint was written successfully, bypassing the intended authorization check (GitHub Advisory, Patch Commit).

• Network: Unexpected PUT requests to /api/{realm}/asset/predicted/{assetId}/{attributeName} originating from accounts that do not hold WRITE_ATTRIBUTES or write:assets roles.
• Logs: API access logs showing HTTP 204 responses to PUT /api/*/asset/predicted/* endpoints for users authenticated with read-only tokens; log entries from AssetPredictedDatapointResourceImpl without corresponding write-role authorization.
• Database: Predicted datapoint records with unexpected values, timestamps, or sources inconsistent with configured prediction services — particularly entries where the writing user's role audit trail shows only READ_ASSETS.

Upgrade io.openremote:openremote-manager to version 1.24.1 or later, which corrects the authorization checks to require WRITE_ATTRIBUTES for write operations and ACCESS_RESTRICTED_WRITE/ACCESS_PUBLIC_WRITE metadata for restricted and unauthenticated access respectively. No configuration-based workaround is documented; the only effective remediation is upgrading to the patched version. As an interim measure, administrators should audit user roles and remove read:assets from accounts that do not require it, minimizing the attack surface (GitHub Advisory, Patch Commit).