Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HSummary
CVE-2026-39842 is a critical-severity Code Injection (CWE-94) vulnerability in Openremote Openremote. Its CVSS base score is 9.9 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Command and Scripting Interpreter (T1059); ranked in the top 43% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-39842 affects OpenRemote, an open-source IoT platform, specifically versions 1.21.0 and below. The vulnerability consists of two interrelated expression injection flaws in the rules engine that enable arbitrary code execution on the server. The JavaScript rules engine invokes user-supplied scripts through Nashorn's ScriptEngine.eval() without any sandboxing, class filtering, or access restrictions. Meanwhile, the authorization logic in RulesResourceImpl limits Groovy rules to superusers but leaves JavaScript rules accessible to any user with the write:rules role. Additionally, the Groovy rules engine defines a GroovyDenyAllFilter security measure, but its registration code is commented out, making the SandboxTransformer ineffective for superuser-created Groovy rules.
A non-superuser attacker with the write:rules role can exploit this by creating malicious JavaScript rulesets. These rulesets execute with unrestricted full JVM access, allowing remote code execution as root, arbitrary file reads, theft of environment variables including database credentials, and complete bypass of multi-tenant isolation to access data across all realms. The CVSS v3.1 base score of 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) reflects its critical severity, linked to CWE-94 (Improper Control of Generation of Code) and CWE-917 (Improper Neutralization of Special Elements).
The OpenRemote security advisory (GHSA-7mqr-33rv-p3mp) and release notes for version 1.22.0 confirm the issue has been addressed in that update, recommending immediate upgrades for affected deployments.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-22806
Vulnerability Data
OpenRemote is an open-source IoT platform. Versions 1.21.0 and below contain two interrelated expression injection vulnerabilities in the rules engine that allow arbitrary code execution on the server. The JavaScript rules engine executes user-supplied scripts via Nashorn's ScriptEngine.eval() without sandboxing,…
more
class filtering, or access restrictions, and the authorization check in RulesResourceImpl only restricts Groovy rules to superusers while leaving JavaScript rules unrestricted for any user with the write:rules role. Additionally, the Groovy rules engine has a GroovyDenyAllFilter security filter that is defined but never registered, as the registration code is commented out, rendering the SandboxTransformer ineffective for superuser-created Groovy rules. A non-superuser attacker with the write:rules role can create JavaScript rulesets that execute with full JVM access, enabling remote code execution as root, arbitrary file read, environment variable theft including database credentials, and complete multi-tenant isolation bypass to access data across all realms. This issue has been fixed in version 1.22.0.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.1.2V1.3.2V1.3.5V4.3.1
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation finds code paths that accept and execute externally influenced strings.
Input validation directly stops untrusted data from being used to construct executable code without neutralization.
Least privilege limits the damage an injected code fragment can perform once executed.
Requiring documented secure development standards and tools enforces use of safe code-generation APIs and escaping.
Security engineering principles include requirements for safe construction and sanitization of dynamic statements, structurally preventing expression-language injection at design time.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
PR.PS-06's SDLC practices directly target injection flaws via secure coding and testing (mostly), yet as a single broad outcome it leaves many code-generation specifics unaddressed (partial).
PR.DS-10 protects runtime data confidentiality/integrity but has no bearing on neutralizing externally influenced input during code generation, so neither direction shows any preventive effect.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development and acceptance can detect EL injection but does not itself implement the fix.
Secure SDLC mandates input validation and output encoding that directly prevent expression-language injection.
Application security requirements explicitly call for controls against injection flaws including EL injection.
Secure architecture principles reduce the attack surface but do not prescribe the specific neutralization techniques needed.
Banning unapproved code samples and unauthenticated web services, combined with secure-coding standards and SAST, prevents the dynamic generation or inclusion of attacker-supplied code.
Controls that restrict unauthorized or malicious code from being introduced via external networks or removable media limit opportunities for an attacker to inject and execute arbitrary code.