Summary
ArcadeDB contains an authorization flaw in its Gremlin query engine that allows authenticated users, including read-only users, to execute Groovy code when the Groovy engine is enabled. An attacker who can access the command API may run operating-system commands with the permissions of the ArcadeDB server process.
ArcadeDB contains an authorization flaw in its Gremlin query engine that allows authenticated users, including read-only users, to execute Groovy code when the Groovy engine is enabled. An attacker who can access the command API may run operating-system commands with the permissions of the ArcadeDB server process.
Affected context
The vulnerability occurs in ArcadeDB deployments where the Gremlin query engine and its Groovy scripting functionality are enabled. The affected command API does not consistently enforce scripting authorization, so users with authenticated access to the database command endpoint may reach scripting functionality beyond their intended database privileges.
The vulnerability occurs in ArcadeDB deployments where the Gremlin query engine and its Groovy scripting functionality are enabled. The affected command API does not consistently enforce scripting authorization, so users with authenticated access to the database command endpoint may reach scripting functionality beyond their intended database privileges.
Exploit preconditions
- Attack surface: The authenticated
POST /api/v1/command/{database}API endpoint - Required access: Valid ArcadeDB credentials, potentially including a read-only reader role
- Trigger point: Submission of a Gremlin command handled by the Gremlin query engine
- Deployment condition: The Groovy engine must be enabled
- Why exploitation is possible: The scripting execution path lacks an effective authorization check before processing commands
- Attack surface: The authenticated
POST /api/v1/command/{database}API endpoint - Required access: Valid ArcadeDB credentials, potentially including a read-only reader role
- Trigger point: Submission of a Gremlin command handled by the Gremlin query engine
- Deployment condition: The Groovy engine must be enabled
- Why exploitation is possible: The scripting execution path lacks an effective authorization check before processing commands
Why this happens
The underlying flaw is an authorization enforcement gap in GremlinQueryEngine.command(). The application permits a user to reach Groovy-backed scripting behavior without verifying that the user's role is authorized to execute scripts. This maps to CWE-863, Improper Authorization, because access-control decisions do not adequately restrict a sensitive operation according to the caller's privileges.
The underlying flaw is an authorization enforcement gap in GremlinQueryEngine.command(). The application permits a user to reach Groovy-backed scripting behavior without verifying that the user's role is authorized to execute scripts. This maps to CWE-863, Improper Authorization, because access-control decisions do not adequately restrict a sensitive operation according to the caller's privileges.
Potential impact
- An attacker could execute operating-system commands as the ArcadeDB server process
- The database service could be compromised
- Confidential database contents could be accessed or modified
- The host or surrounding environment could be affected, depending on service privileges
- The vulnerability could support lateral movement or disruption of dependent systems
- An attacker could execute operating-system commands as the ArcadeDB server process
- The database service could be compromised
- Confidential database contents could be accessed or modified
- The host or surrounding environment could be affected, depending on service privileges
- The vulnerability could support lateral movement or disruption of dependent systems
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every scripting
execution boundary and reducing exposure of dynamic code execution features.
Common defensive patterns include:
- Require an explicit, role-based scripting permission before invoking Groovy or other script engines
- Disable scripting engines when they are not required by the deployment
- Apply deny-by-default authorization to command and query endpoints
- Separate read-only data access from administrative and code-execution capabilities
- Run the database service with least-privilege operating-system permissions
- Restrict network access to management and command APIs
- Use strong authentication, short-lived credentials, and centralized authorization policies
Mitigation generally focuses on enforcing authorization at every scripting
execution boundary and reducing exposure of dynamic code execution features.
Common defensive patterns include:
- Require an explicit, role-based scripting permission before invoking Groovy or other script engines
- Disable scripting engines when they are not required by the deployment
- Apply deny-by-default authorization to command and query endpoints
- Separate read-only data access from administrative and code-execution capabilities
- Run the database service with least-privilege operating-system permissions
- Restrict network access to management and command APIs
- Use strong authentication, short-lived credentials, and centralized authorization policies
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis rules that identify script-engine calls lacking nearby authorization checks
- Code review of query dispatchers, command endpoints, and role-to-capability mappings
- Tests that verify read-only and lower-privilege roles cannot invoke scripting functionality
- API monitoring for unusual Gremlin commands or command requests from unexpected principals
- Policy checks confirming that dynamic scripting is disabled unless explicitly required
- Automated security review tools that trace user-controlled commands to code-execution APIs
Organizations can look for this class of issue through:
- Static analysis rules that identify script-engine calls lacking nearby authorization checks
- Code review of query dispatchers, command endpoints, and role-to-capability mappings
- Tests that verify read-only and lower-privilege roles cannot invoke scripting functionality
- API monitoring for unusual Gremlin commands or command requests from unexpected principals
- Policy checks confirming that dynamic scripting is disabled unless explicitly required
- Automated security review tools that trace user-controlled commands to code-execution APIs
