Command InjectionAffected versions of this package are vulnerable to Command Injection through the ScriptTriggerExecutor in engine/src/main/java/com/arcadedb/schema/trigger/ScriptTriggerExecutor.java. An attacker can execute OS commands by creating a JavaScript trigger that uses Java.type("java.lang.Runtime").getRuntime().exec(...) or ProcessBuilder and then firing the trigger. The vulnerable trigger sandbox allowed java.lang.* host-class lookups for schema users with UPDATE_SCHEMA, so a malicious trigger script could access host methods and run system commands on the server. This breaks trigger execution isolation and lets a schema administrator obtain arbitrary command execution on the host.
Notes
DEFINE FUNCTION ... LANGUAGE js is gated by UPDATE_SECURITY, not the usual schema-level mutation permission, so the RCE path is narrower than generic schema edits.- The trigger exploit depends on GraalVM host-class lookup being enabled for
java.lang.*; native JavaScript-only triggers remain unaffected.
How to fix Command Injection? Upgrade com.arcadedb:arcadedb-engine to version 26.7.2 or higher.
| |
Improper Handling of Insufficient Permissions or PrivilegesAffected versions of this package are vulnerable to Improper Handling of Insufficient Permissions or Privileges via the DefineFunctionStatement.executeSimple path in engine/src/main/java/com/arcadedb/query/sql/parser/DefineFunctionStatement.java. An attacker can execute arbitrary JavaScript by sending DEFINE FUNCTION ... LANGUAGE js through the SQL command API and then invoking the function with SELECT, even when they are authorized for the database but lack security-admin privileges. This lets a read-only or schema-level user bypass the scripting gate intended to restrict JavaScript execution to users with UPDATE_SECURITY. The result is unauthorized host-code execution through SQL-defined JavaScript functions, which can be used to run attacker-supplied script logic inside the server process.
Notes
DEFINE FUNCTION ... LANGUAGE js was reachable through the SQL command API without the scripting gate, so the vulnerable path let a database-authorized but non-security-admin user register JavaScript and then invoke it later with SELECT. SQL and Cypher user functions were not part of that gap; the issue was specific to scripting-language libraries.- The exposed polyglot context also allowed built-in
load(path|url) usage, so deployments that relied on the default JavaScript host sandbox were additionally exposed to file reads, SSRF, or remote-script inclusion through that same route.
Workarounds
- Restrict access to
DEFINE FUNCTION ... LANGUAGE js so only users with UPDATE_SECURITY can run it, and do not allow schema-level or read-only roles to create JavaScript functions; this blocks the SQL path that could otherwise be used to execute attacker-supplied JavaScript.
- If you expose trigger-based JavaScript execution, remove
java.lang.* from the trigger script host-class allow-list so trigger scripts cannot resolve Java.type("java.lang.Runtime"), ProcessBuilder, or System.exit; this prevents OS command execution through trigger scripts.
- Limit exposure of the
/api/v1/server settings endpoint to trusted administrators, because it can disclose sensitive configuration values such as the HA cluster token; this prevents leaking secrets that could be reused for cluster-forwarded-auth impersonation.
- Require database-scoped authorization on the time-series, batch, Prometheus, and Grafana HTTP routes, and deny requests for databases the authenticated user is not explicitly allowed to access; this blocks cross-database read/write access through those endpoints.
How to fix Improper Handling of Insufficient Permissions or Privileges? Upgrade com.arcadedb:arcadedb-engine to version 26.7.2 or higher.
| |
