CVE-2026-39842: Critical OpenRemote IoT Expression Injection Enables Arbitrary Server-Side Code Execution

Executive Summary

A critical expression injection vulnerability (CVE-2026-39842, CVSS 9.9) has been disclosed in OpenRemote, a popular open-source IoT platform used for smart building, energy management, and industrial automation deployments. Two interrelated injection flaws in the platform's JavaScript rules engine allow an attacker to execute arbitrary code on the server by supplying malicious script payloads through the rules interface.

The vulnerability affects all versions up to and including 1.21.0 and has no upstream patch available as of the initial disclosure date. Organizations running OpenRemote should implement mitigations immediately.

Vulnerability Overview

Affected Products

OpenRemote is an open-source IoT management platform providing device management, rules automation, dashboards, and data visualization for smart building, energy, agriculture, and industrial IoT deployments. It is self-hosted by organizations globally, often with direct access to physical infrastructure controls.

Technical Analysis

Root Cause

CVE-2026-39842 consists of two interrelated expression injection vulnerabilities in OpenRemote's JavaScript rules engine. The platform allows authenticated users to define automation rules using JavaScript, which are executed by the server via the Nashorn JavaScript engine (javax.script.ScriptEngine).

The core issue is that user-supplied rule scripts are passed to Nashorn's script execution context without meaningful sandboxing or isolation. Nashorn, as a JavaScript-to-JVM bridge, provides direct access to Java classes and the JVM runtime by default. Without explicit class access restrictions, a malicious script can:

• Import and instantiate arbitrary Java classes
• Invoke OS command execution via java.lang.ProcessBuilder
• Read and write files on the server filesystem
• Access environment variables and secrets
• Pivot to internal network resources accessible to the OpenRemote server

Attack Surface

The attack surface is the rules engine interface accessible to authenticated platform users. In many OpenRemote deployments:

• The platform is accessible over the internet or internal networks without strict access controls
• Default or weak credentials are present on installations
• The rules interface is exposed to all authenticated users, including low-privilege accounts

The CVSS "Changed" scope reflects that successful exploitation escapes the application context and compromises the underlying host OS.

Exploitation Path

An attacker with a valid OpenRemote account can navigate to the Rules section of the management console and create a new rule using the JavaScript editor. Because Nashorn grants direct access to the Java standard library without restriction, the attacker can leverage Java's ProcessBuilder or similar APIs to spawn OS processes in the context of the OpenRemote server user — achieving arbitrary command execution on the host.

Exploitation does not require administrator privileges within OpenRemote, only a standard authenticated session.

Why CVSS 9.9

The near-maximum CVSS score reflects:

The "Changed" scope metric — relatively rare in CVE scoring — is what pushes this from a 9.8 to a 9.9.

Impact Assessment

OpenRemote is commonly deployed to manage physical infrastructure including:

A compromise of an OpenRemote server may directly facilitate physical-world impact depending on what IoT devices are connected to the platform. This elevates the severity beyond a typical web application RCE.

Remediation

Immediate Actions (No Patch Available)

As no upstream patch was available at the time of disclosure, organizations must apply compensating controls:

1. Restrict Access to the Rules Engine

Limit which users can create or modify rules. If your deployment does not require user-defined rules, disable the feature entirely at the application or network layer.

2. Network Isolation

Restrict OpenRemote management port access (typically 8080/HTTP, 8443/HTTPS, 1883/MQTT) using firewall rules to allow only trusted management IP ranges. Block all public internet access to the management interface if it is not required.

3. Enforce Strong Authentication

Ensure all accounts have strong, unique passwords. If OpenRemote is integrated with an identity provider, enforce MFA for all users who have access to the rules engine.

4. Monitor for Exploitation

# Watch OpenRemote logs for unexpected rule execution or script errors
docker logs openremote --follow | grep -i "script\|rule\|nashorn\|exception"
 
# Watch for unusual child processes spawned by the OpenRemote JVM
ps auxf | grep java

5. Container Isolation

If running in Docker, ensure the OpenRemote container runs with a non-root user and does not have host network or privileged access:

# docker-compose.yml hardening
services:
  manager:
    security_opt:
      - no-new-privileges:true
    user: "1000:1000"
    cap_drop:
      - ALL

Watch for Upstream Patch

Monitor the OpenRemote GitHub repository for a patched release. Apply any security release immediately upon availability.

Detection Indicators

Post-Incident Checklist

1. Isolate the affected OpenRemote server from the network immediately
2. Preserve logs and container state for forensic analysis before remediation
3. Audit all user accounts and recently created or modified rules
4. Rotate all credentials stored in or accessible from the OpenRemote server
5. Check connected IoT devices for unexpected commands or state changes
6. Review outbound network connections for C2 activity or data exfiltration
7. Rebuild the OpenRemote instance from a known-good baseline after patch availability
8. Notify stakeholders of potential physical infrastructure exposure if applicable

References

• NVD — CVE-2026-39842
• OpenRemote GitHub Repository