GHSA-48QW-824M-86PR
Vulnerability from github – Published: 2026-07-16 20:13 – Updated: 2026-07-16 20:13Impact
A user holding only reader (read-only) privileges on a single database could execute arbitrary JVM code by sending a "language": "js" command to the POST /api/v1/command/{database} HTTP endpoint, and use it to read arbitrary files on the host filesystem (e.g. /etc/passwd, configuration files), outside the scope of the database itself.
Two cooperating defects made this possible:
- Missing authorization on the scripting path (CWE-863 / CWE-269). Polyglot script execution (
jsand other GraalVM languages) never went through the database authorization checks applied to SQL/Cypher, so any authenticated principal - regardless of database role - could run scripts. - Sandbox whitelist bypass. The GraalVM sandbox restricts direct class lookups to a configured
allowedPackageslist, but a script could reach arbitrary classes by reflecting off the bounddatabaseobject:database.getClass().getClassLoader().loadClass("java.io.File").
Process creation was already blocked (allowCreateProcess(false)), so the confirmed impact is host file read, not OS command execution. Confidentiality: High. Integrity/Availability: None.
This is a distinct entry point and root cause from CVE-2026-44221, CVE-2026-54076 and CVE-2026-54077, and is reproducible on builds that already contain those fixes.
Patches
The fix is applied in the engine so it covers every entry point (HTTP command, HA-forwarded commands, MCP analyze), not only the HTTP handler:
- Polyglot script execution now requires the
updateSecuritydatabase-administrator permission oncommand,analyzeandregisterFunctions. The check runs on the request thread that carries the authenticated user and is a no-op in embedded mode and internal/system contexts (schema load, HA replication apply). - The GraalVM host-access policy now denies access to
java.lang.Class,java.lang.ClassLoaderandjava.lang.reflectmembers, closing the reflection escape that bypassedallowedPackages- even for authorized administrators - while leaving normal method calls on bound objects and explicitJava.type(...)lookups (governed byallowedPackages) working.
Workarounds
Until upgraded, do not grant command/query access on the HTTP API to untrusted users, and treat any account that can reach /api/v1/command as capable of code execution. Note that after the fix, non-administrator accounts can no longer run js/polyglot scripts over HTTP.
Credit
Reported by @kyojune76.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.arcadedb:arcadedb-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "26.7.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-16T20:13:20Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\nA user holding only `reader` (read-only) privileges on a single database could execute arbitrary JVM code by sending a `\"language\": \"js\"` command to the `POST /api/v1/command/{database}` HTTP endpoint, and use it to read arbitrary files on the host filesystem (e.g. `/etc/passwd`, configuration files), outside the scope of the database itself.\n\nTwo cooperating defects made this possible:\n\n1. **Missing authorization on the scripting path (CWE-863 / CWE-269).** Polyglot script execution (`js` and other GraalVM languages) never went through the database authorization checks applied to SQL/Cypher, so any authenticated principal - regardless of database role - could run scripts.\n2. **Sandbox whitelist bypass.** The GraalVM sandbox restricts direct class lookups to a configured `allowedPackages` list, but a script could reach arbitrary classes by reflecting off the bound `database` object: `database.getClass().getClassLoader().loadClass(\"java.io.File\")`.\n\nProcess creation was already blocked (`allowCreateProcess(false)`), so the confirmed impact is host **file read**, not OS command execution. Confidentiality: High. Integrity/Availability: None.\n\nThis is a distinct entry point and root cause from CVE-2026-44221, CVE-2026-54076 and CVE-2026-54077, and is reproducible on builds that already contain those fixes.\n\n### Patches\n\nThe fix is applied in the engine so it covers every entry point (HTTP command, HA-forwarded commands, MCP `analyze`), not only the HTTP handler:\n\n- Polyglot script execution now requires the `updateSecurity` database-administrator permission on `command`, `analyze` and `registerFunctions`. The check runs on the request thread that carries the authenticated user and is a no-op in embedded mode and internal/system contexts (schema load, HA replication apply).\n- The GraalVM host-access policy now denies access to `java.lang.Class`, `java.lang.ClassLoader` and `java.lang.reflect` members, closing the reflection escape that bypassed `allowedPackages` - even for authorized administrators - while leaving normal method calls on bound objects and explicit `Java.type(...)` lookups (governed by `allowedPackages`) working.\n\n### Workarounds\n\nUntil upgraded, do not grant command/query access on the HTTP API to untrusted users, and treat any account that can reach `/api/v1/command` as capable of code execution. Note that after the fix, non-administrator accounts can no longer run `js`/polyglot scripts over HTTP.\n\n### Credit\n\nReported by @kyojune76.",
"id": "GHSA-48qw-824m-86pr",
"modified": "2026-07-16T20:13:20Z",
"published": "2026-07-16T20:13:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ArcadeData/arcadedb/security/advisories/GHSA-48qw-824m-86pr"
},
{
"type": "PACKAGE",
"url": "https://github.com/ArcadeData/arcadedb"
},
{
"type": "WEB",
"url": "https://github.com/ArcadeData/arcadedb/releases/tag/26.7.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "ArcadeDB: Privilege escalation via reader role in /api/v1/command JS scripting language \u2014 arbitrary host file read"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.