Gremlin Security

ArcadeDB provides two Gremlin execution engines with different security profiles.

CRITICAL SECURITY NOTICE: The Groovy Gremlin engine is NOT SECURE and should NOT be used in production environments or with untrusted users. Despite security restrictions, it remains vulnerable to remote code execution (RCE) attacks. Always use the Java engine (default) for production deployments.

Execution Engines

Java Engine (Default - Secure)

The native Java engine parses Gremlin queries using a restricted grammar and generates bytecode. This engine:

Only accepts valid Gremlin traversal syntax
Cannot execute arbitrary Java code
Blocks Runtime.getRuntime().exec() and similar attacks
Recommended for ALL deployments
Required for production and security-critical environments

Groovy Engine (Legacy - INSECURE)

SECURITY VULNERABILITY: The Groovy engine is vulnerable to Remote Code Execution (RCE) attacks. Authenticated users can execute arbitrary operating system commands. DO NOT USE IN PRODUCTION.

The Groovy engine provides dynamic scripting capabilities but has critical security limitations:

Supports Groovy-specific syntax and dynamic features
Cannot be adequately secured - SecureASTCustomizer has known bypasses
Vulnerable to: Runtime.exec(), ProcessBuilder, file system access, reflection
Only use for development/testing in fully trusted environments
Will display a security warning at startup

Who Can Evaluate Groovy

Evaluating Groovy is running arbitrary code on the server host, so its reach is the whole server, not one database. Since 26.10.1 ArcadeDB reserves it to the server administrator (root) on every entry point. A per-database grant, including a database administrator holding updateSecurity, is not enough:

HTTP command endpoint (POST /api/v1/command/{database} with "language": "gremlin"): when the database runs the groovy engine, or the auto engine falls back to Groovy, any other user gets 403 Forbidden. Under the default java engine nothing changes: every authorized user keeps running traversals.
Gremlin Server (port 8182): a string script submitted in a language other than gremlin-lang is refused for any other user. A script with no language is evaluated by TinkerPop as gremlin-groovy, so it is refused too. The same applies to a bytecode traversal carrying a lambda (e.g. Lambda.function(…)), whose body is Groovy source. Bytecode traversals without lambdas, and string scripts submitted with language gremlin-lang, stay available to every authorized user:
```
client.submit("g.V().count()", RequestOptions.build().language("gremlin-lang").create());
```

The io() step (g.io('/path/file.xml').read() / .write()) reads or writes a file at a caller-chosen path on the server host, so it is reserved to root as well, on every engine including java. The restriction cannot be lifted from the request: a withoutStrategies(…) naming the strategy that enforces it is ignored. Use EXPORT DATABASE and IMPORT DATABASE to move data in and out of a database.

In embedded mode no user is bound to the request, so none of these checks apply.

Configuration

Set the engine via database configuration:

-- Secure (default)
ALTER DATABASE `arcadedb.gremlin.engine` 'java';

-- Legacy with security restrictions (use only if needed)
ALTER DATABASE `arcadedb.gremlin.engine` 'groovy';

-- Auto-detect (not recommended for production)
ALTER DATABASE `arcadedb.gremlin.engine` 'auto';

Or via JVM startup parameters:

# Set to Java engine (secure)
java -Darcadedb.gremlin.engine=java ...

# Set to Groovy engine (use only if needed)
java -Darcadedb.gremlin.engine=groovy ...

Security Best Practices

Use Java Engine: ALWAYS use 'java' engine in production - this is non-negotiable for security
Never Use Groovy in Production: The Groovy engine is vulnerable to RCE and cannot be secured
Least Privilege: Grant Gremlin query permissions only to fully trusted administrators
Input Validation: Never accept Gremlin queries from untrusted sources
Audit Logging: Monitor all Gremlin query execution for suspicious patterns
Network Isolation: Run ArcadeDB in isolated network segments
Authentication Required: Always require authentication for Gremlin access

Security Limitations (Groovy Engine)

Despite attempts to restrict dangerous operations, the Groovy engine remains vulnerable to:

Process execution: Runtime.exec(), ProcessBuilder - NOT BLOCKED
File system access: File, FileInputStream, Files, Paths - NOT BLOCKED
Reflection: Method, Field, Constructor, Class.forName() - NOT BLOCKED
Class loading: ClassLoader, GroovyClassLoader - NOT BLOCKED
Network operations: URL, URLConnection, Socket - NOT BLOCKED
System operations: System.exit(), System.load() - NOT BLOCKED

The SecureASTCustomizer has inherent limitations that prevent effective sandboxing of Groovy scripts.

Migration from Groovy to Java Engine

If you are currently using the Groovy engine and want to migrate to the more secure Java engine:

Test your queries: Run your existing Gremlin queries with the Java engine to verify compatibility
Update configuration: Change the arcadedb.gremlin.engine setting to 'java'
Refactor if needed: If you have Groovy-specific syntax, refactor to standard Gremlin traversal syntax
Verify results: Ensure query results are consistent between engines

Most standard Gremlin queries work identically on both engines. The Java engine is faster and more secure.

Security Considerations

CRITICAL: Remote Code Execution Vulnerability

The Groovy engine has a CRITICAL SECURITY VULNERABILITY that allows Remote Code Execution (RCE):

Vulnerability: Authenticated users can execute arbitrary operating system commands
Impact: Complete server compromise - attackers can read files, execute processes, access network
Mitigation: The SecureASTCustomizer security restrictions are INSUFFICIENT and can be bypassed
Recommendation: NEVER use Groovy engine in production or with untrusted users

Example of vulnerable code that executes successfully:

Runtime.getRuntime().exec("touch /tmp/owned")
new File("/etc/passwd").text

The Java engine (default) is NOT vulnerable to these attacks.

Default Engine: the default Gremlin engine is 'java', not 'auto', for security reasons. This protects users from RCE attacks.

If you explicitly enable the Groovy engine (arcadedb.gremlin.engine=groovy), you will receive a security warning at startup, and your system will be vulnerable to RCE attacks.

Error messages in production mode: when the server runs with arcadedb.server.mode=production, the Gremlin Server (WebSocket, default channelizer) answers engine failures with the generic message "The request failed. Check the server log for the details" and no stack trace, so stored key values are not sent to the client. The real message is written to the server log. Another channelizer chosen in gremlin-server.yaml (for example HTTP) does not apply this, and the server logs a warning at startup.