CVE-2026-114059 in ArcadeDB
Summary
by MITRE • 10/22/2026
ArcadeDB before 26.10.1 contains a remote code execution vulnerability that allows authenticated users, including read-only reader role holders, to execute Groovy code because GremlinQueryEngine.command() lacks scripting authorization checks. Attackers can submit Gremlin commands to the POST /api/v1/command/{database} endpoint when the Groovy engine is enabled to run OS commands as the server process user.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in ArcadeDB versions prior to 26.10.1 represents a critical remote code execution flaw rooted in insufficient authorization controls within the Gremlin query processing subsystem. Specifically, the GremlinQueryEngine.command() method fails to enforce proper scripting language restrictions when handling incoming requests. This architectural oversight allows any authenticated user, including those assigned only read-only or reader roles, to bypass intended access limitations and execute arbitrary Groovy scripts on the underlying server infrastructure. The core technical failure lies in the absence of a validation mechanism that checks whether the requested script engine is permitted for the specific user role making the request, thereby treating all authenticated sessions with equal privilege regarding scripting capabilities regardless of their actual permissions level.
Operationally, this vulnerability enables attackers to leverage the POST /api/v1/command/{database} endpoint by submitting carefully crafted Gremlin commands that invoke Groovy's runtime execution features. When the Groovy engine is enabled within the ArcadeDB configuration, these malicious inputs are processed directly by the server process without adequate sandboxing or permission verification. Consequently, an attacker can execute operating system commands with the same privileges as the user account running the ArcadeDB service. This typically results in full compromise of the host machine, allowing for data exfiltration, lateral movement within the network, and potential denial of service through resource exhaustion or destructive file operations. The severity is exacerbated by the fact that authentication alone is sufficient to trigger this chain of events, meaning even low-privilege accounts can lead to complete system takeover if scripting capabilities are not strictly isolated from general database access roles.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code or Script Injection, specifically where the injection vector is through an API endpoint and the execution context involves server-side script engines. It also maps to MITRE ATT&CK technique T1059 Command and Scripting Interpreter, as well as T1068 Exploitation for Privilege Escalation if the database service runs with elevated privileges. The lack of role-based access control over scripting features violates fundamental security principles regarding least privilege and defense in depth, highlighting a gap in how application-level permissions are enforced against backend execution engines.
To mitigate this risk, organizations running affected versions must immediately upgrade to ArcadeDB version 26.10.1 or later where the authorization checks for script engines have been implemented. In environments where upgrading is not immediately feasible, administrators should disable the Groovy scripting engine entirely if it is not required for legitimate database operations. Additionally, implementing strict network segmentation to restrict access to the /api/v1/command/{database} endpoint only from trusted internal sources can reduce the attack surface. It is also recommended to review and harden role definitions within ArcadeDB to ensure that read-only roles do not inherit unintended execution capabilities in future configurations or patches. Regular auditing of API usage logs for anomalous Gremlin command patterns involving script invocation keywords such as eval, execute, or Groovy-specific syntax can aid in early detection of exploitation attempts before full compromise occurs.