CVE-2026-65831

ArcadeDB is a Multi-Model DBMS. Prior to 26.7.1, a reader-role user can submit POST /api/v1/command/{database} with language: js because PolyglotQueryEngine.command, PolyglotQueryEngine.analyze, and PolyglotQueryEngine.registerFunctions do not enforce database-administrator authorization. GraalPolyglotEngine also permits scripts to bypass the allowedPackages whitelist by reflecting from the bound database object through database.getClass().getClassLoader().loadClass to arbitrary host classes. These cooperating defects allow a read-only database user to read arbitrary host files outside the database scope. Process creation is already blocked, so OS command execution is not confirmed. The issue is distinct from CVE-2026-44221, CVE-2026-54076, and CVE-2026-54077. This issue is fixed in version 26.7.1.

ArcadeDB is a Multi-Model DBMS. Prior to 26.7.1, a reader-role user can submit POST /api/v1/command/{database} with language: js because PolyglotQueryEngine.command, PolyglotQueryEngine.analyze, and PolyglotQueryEngine.registerFunctions do not enforce database-administrator authorization. GraalPolyglotEngine also permits scripts to bypass the allowedPackages whitelist by reflecting from the bound database object through database.getClass().getClassLoader().loadClass to arbitrary host classes. These cooperating defects allow a read-only database user to read arbitrary host files outside the database scope. Process creation is already blocked, so OS command execution is not confirmed. The issue is distinct from CVE-2026-44221, CVE-2026-54076, and CVE-2026-54077. This issue is fixed in version 26.7.1.

Impact

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:

1. 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.
2. 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").

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 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).
• 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.

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.

ArcadeDB is a Multi-Model DBMS. Prior to 26.7.1, a reader-role user can submit POST /api/v1/command/{database} with language: js because PolyglotQueryEngine.command, PolyglotQueryEngine.analyze, and PolyglotQueryEngine.registerFunctions do not enforce database-administrator authorization. GraalPolyglotEngine also permits scripts to bypass the allowedPackages whitelist by reflecting from the bound database object through database.getClass().getClassLoader().loadClass to arbitrary host classes. These cooperating defects allow a read-only database user to read arbitrary host files outside the database scope. Process creation is already blocked, so OS command execution is not confirmed. The issue is distinct from CVE-2026-44221, CVE-2026-54076, and CVE-2026-54077. This issue is fixed in version 26.7.1.

ArcadeDB is a Multi-Model DBMS. Prior to 26.7.1, a reader-role user can submit POST /api/v1/command/{database} with language: js because PolyglotQueryEngine.command, PolyglotQueryEngine.analyze, and PolyglotQueryEngine.registerFunctions do not enforce database-administrator authorization. GraalPolyglotEngine also permits scripts to bypass the allowedPackages whitelist by reflecting from the bound database object through database.getClass().getClassLoader().loadClass to arbitrary host classes. These cooperating defects allow a read-only database user to read arbitrary host files outside the database scope. Process creation is already blocked, so OS command execution is not confirmed. The issue is distinct from CVE-2026-44221, CVE-2026-54076, and CVE-2026-54077. This issue is fixed in version 26.7.1.

Impact

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:

1. 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.
2. 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").

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 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).
• 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.

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.