Patches critical expression-injection RCE in OpenRemote rules engine

TL;DR — OpenRemote’s rules engine can execute attacker-supplied JavaScript with full JVM access, enabling low-privilege authenticated users to achieve server-side RCE and cross-tenant data access.

What happened

OpenRemote is an open-source IoT platform; its openremote-manager component includes a rules engine that lets users author and deploy automation rules.

In GHSA-7mqr-33rv-p3mp (CVE-2026-39842), OpenRemote disclosed two interrelated expression-injection issues in the rules engine:

• Unsandboxed Nashorn JavaScript execution: user-supplied JavaScript is evaluated via Nashorn ScriptEngine.eval() without sandboxing or class filtering, and the advisory states that non-superusers with the write:rules role can create JavaScript rulesets.
• Groovy defense-in-depth failure: a Groovy “deny all” security filter exists but is not registered (commented-out registration), leaving Groovy execution without an effective sandbox even though Groovy rules are restricted to superusers.

Why this matters: “rules engine” script evaluation is a recurring high-risk pattern—once a low-privilege user can deploy code-like rules without a real sandbox, it becomes a straight path to RCE and multi-tenant boundary collapse.

Who is impacted

• Deployments using maven package io.openremote/openremote-manager with versions:
  • Affected: <= 1.21.0
  • Patched: 1.22.0
• Environments where any non-superuser accounts can obtain write:rules (including via role misconfiguration or over-broad RBAC defaults).
• Multi-tenant OpenRemote deployments are specifically high impact because the advisory demonstrates cross-realm data access once code execution is achieved.

What to do now

• Follow vendor remediation guidance and apply a release that includes the fix.

  "Affected versions <= 1.21.0" "Patched versions 1.22.0"

• Inventory where io.openremote/openremote-manager is deployed (containers, Helm charts, Maven dependency trees, embedded distributions) and prioritize internet-facing or multi-tenant instances.
• Until you can update, reduce exposure by tightening RBAC around rules management:
  • Ensure write:rules is not granted to untrusted or broad user groups.
  • Review who can create/modify rulesets (especially JavaScript rules) and add monitoring/alerting for new ruleset deployments.
• If compromise is suspected, assume rules execution implies broad secret exposure (e.g., DB credentials, Keycloak/admin secrets) and rotate credentials accessible to the OpenRemote runtime after incident triage.