GHSA-48QW-824M-86PR: Privilege Escalation and Sandbox Escape in ArcadeDB Server

ArcadeDB Server before version 26.7.1 contains an improper privilege management vulnerability that permits authenticated database users with minimal permissions to escape the execution sandbox. The vulnerability resides within the polyglot scripting endpoint, which provides support for multi-language query execution including JavaScript via GraalVM. Under default configurations, the API endpoint fails to validate whether the executing security context possesses administrative authority.

By leveraging this lack of access control, an authenticated attacker with a read-only role can submit arbitrary JavaScript commands. The script execution environment utilizes a sandboxed GraalVM context designed to restrict access to underlying JVM features and host files. However, because a Java database reference is exposed directly to the guest context, the guest environment can traverse reflective boundaries to escape these restrictions.

This security bypass permits the attacker to load non-whitelisted Java classes, bypass filesystem access restrictions, and read arbitrary files from the host operating system. The flaw does not require administrative privileges or complex configurations, making exploitation highly reliable once an attacker gains basic database access.

The vulnerability stems from two distinct logical flaws in the application design. The first flaw is the complete absence of authorization checks within the PolyglotQueryEngine command processing pathway. In ArcadeDB, standard SQL and Cypher operations are strictly restricted according to role-based access control policies. However, the system did not enforce equivalent permission checks when processing scripting commands through the /api/v1/command/{database} endpoint.

The second flaw is an insufficient host-access configuration in the GraalVM guest engine. To facilitate query operations, the application binds a live Java database instance into the JavaScript context. The sandbox implementation restricts standard class lookups by enforcing an allowedPackages whitelist, which prevents scripts from directly importing packages like java.io.

Despite this restriction, the default GraalVM host-access policy (HostAccess.ALL) allowed the guest environment to perform reflection on any public methods of the bound database object. By invoking database.getClass().getClassLoader(), a script could obtain the JVM's ClassLoader object. Since the ClassLoader itself is outside the scope of the package whitelist filters, the script could use it to load arbitrary Java classes such as java.io.File and java.util.Scanner, effectively escaping the sandbox.

To resolve the privilege escalation, the maintainers implemented authorization enforcement on the scripting engine and restricted GraalVM host access. The patch gates the scripting operations under PolyglotQueryEngine behind the UPDATE_SECURITY role requirement. The check executes synchronously within the calling thread, blocking low-privileged database readers from accessing the scripting engine.

// Patched PolyglotQueryEngine.java
private void checkScriptingPermissions() {
  // Restricts execution to users with UPDATE_SECURITY permissions
  database.checkPermissionsOnDatabase(SecurityDatabaseUser.DATABASE_ACCESS.UPDATE_SECURITY);
}

Additionally, the patch replaces the permissive HostAccess.ALL configuration with a customized sandbox policy. The new policy, defined as SANDBOXED_HOST_ACCESS, explicitly denies guest scripts from accessing the reflection API, the Class representation, and ClassLoader objects.

// Patched GraalPolyglotEngine.java
private static final HostAccess SANDBOXED_HOST_ACCESS = HostAccess.newBuilder(HostAccess.ALL)
    .denyAccess(Class.class)
    .denyAccess(ClassLoader.class)
    .denyAccess(java.lang.reflect.AccessibleObject.class)
    .denyAccess(java.lang.reflect.Member.class)
    .build();

By denying access to these critical Java classes, the reflection chain is severed at the source. Any attempt by a script to call .getClass() or retrieve a ClassLoader on a bound host object now results in an immediate security exception, preventing the guest context from loading arbitrary external classes.

Exploitation of this vulnerability requires network access to the ArcadeDB HTTP API and valid credentials for a database reader. An attacker submits a POST request to the /api/v1/command/{database} endpoint, specifying js as the query language. The command string contains the payload designed to escape the package whitelist using reflective access on the bound database instance.

The exploit sequence starts by obtaining the class loader via the bound database instance. The attacker uses the class loader to dynamically resolve the java.io.File and java.util.Scanner classes. These classes are then instantiated reflectively to bypass the standard import restrictions.

{
  "language": "js",
  "command": "var cl = database.getClass().getClassLoader(); var FileClass = cl.loadClass('java.io.File'); var ScannerClass = cl.loadClass('java.util.Scanner'); var fileObj = FileClass.getConstructor(cl.loadClass('java.lang.String')).newInstance('/etc/passwd'); var scannerObj = ScannerClass.getConstructor(cl.loadClass('java.io.File')).newInstance(fileObj); scannerObj.useDelimiter('\\\\A'); var content = scannerObj.hasNext() ? scannerObj.next() : ''; content;"
}

The scanner instance reads the entire contents of the target file, which are returned in the HTTP response body. Because the execution runs within the security context of the ArcadeDB server process, the attacker can read any file that the application process has permissions to access.

The vulnerability represents a breakdown of security boundaries, transitioning an attacker from a restricted database reader to an entity capable of reading host files. This is reflected in the CVSS v3.1 score of 7.7, specifically highlighted by the Scope change metric (S:C). The escape from the GraalVM guest environment directly compromises the security of the underlying host operating system.

An attacker can exploit this access to read sensitive configuration files, database credentials, environment variables, or system files such as /etc/passwd. In cloud environments, this may expose metadata service tokens, potentially allowing broader lateral movement.

Although the default GraalVM configuration denies process creation, preventing direct remote code execution (RCE) via system commands, the ability to read arbitrary files remains a severe threat. Exfiltrated credentials can lead to full database compromise or host takeovers.

The primary remediation path is upgrading the ArcadeDB Server installation to version 26.7.1 or later. This release incorporates the administrative privilege validation and the hardened SANDBOXED_HOST_ACCESS configuration, which successfully prevents both the unauthorized command access and the reflection bypass.

If upgrading is not immediately feasible, organizations must restrict network access to the database HTTP port (default 2480) and the HA clustering port (default 2481). Implement firewall rules or security groups to ensure only trusted application servers can interact with these interfaces.

Additionally, review all database user roles and revoke command privileges for any non-essential accounts. Treat all users with query permissions as potentially fully trusted until the upgrade is completed, as the application cannot enforce effective database isolation boundaries under the vulnerable versions.