Horizon Alert
Summary of the vulnerability and why it matters
ArcadeDB server versions prior to 26.8.1 contain a vulnerability where an authenticated user with read-only access can execute asynchronous commands to bypass authorization controls, escalate privileges, and gain full administrative control over the server. This issue stems from how the server handles authenticated user context in asynchronous operations, effectively making the authorization check a no-op for specific command types.
- Unauthenticated administrators can be created by users.
- This bypasses security and allows full control.
- Confirm relevance and exposure for your deployments.
Attack Path
How an attacker could exploit the issue
An attacker with read-only access to a single database can exploit a flaw in how ArcadeDB handles asynchronous commands. By sending a specially crafted JavaScript command to the `/api/v1/command` endpoint with `awaitResponse:false`, the attacker can bypass authorization checks. This allows them to execute arbitrary code on the server, effectively gaining administrative control and creating new administrator accounts.
- Attacker needs read-only access.
- Trigger is an asynchronous command.
- Risk is full administrative control.
Live Threat
Current exploitation, exposure, and threat context
When an HTTP command is submitted with `awaitResponse:false`, an unauthenticated principal could be propagated to an asynchronous worker thread. This bypasses the scripting authorization gate, allowing a user with read access to a single database to execute unrestricted code, such as creating a server-wide administrator.
- Database user accounts and administrative privileges.
- Asynchronous commands can bypass authorization checks.
- Full administrative control over the database server.
Operational Fix
Recommended remediation, mitigation, and detection steps
This critical vulnerability in ArcadeDB allows a low-privileged user to escalate to full administrative control by exploiting the failure to propagate authenticated principals to asynchronous command worker threads. The first practical step involves identifying all instances of the affected ArcadeDB server, determining their network reachability and business criticality, and locating the accountable application or platform owner. This information will then inform a risk-based remediation plan, which may include coordinating with the vendor for a fix or implementing compensating controls.
- Ownership: Platform or Database Administration teams.
- Verify first: Affected instances and their exposure.
- Action: Plan and execute vendor-approved update.
