Two critical vulnerabilities in ArangoDB can allow an unauthenticated attacker to reach protected database functions and ultimately execute code with root-level privileges on the host. The issues affect releases through 3.12.10.1 and are particularly dangerous for internet-facing databases and container deployments using the vendor’s default image.

Remedio researchers found both weaknesses while examining ArangoDB’s HTTP attack surface. Each results from trusting information supplied in a request at a security boundary: one creates disagreement over whether a URL is protected, while the other lets a client claim that a scheduled task belongs in the server’s privileged system context.

Encoded URL slips past authentication

The first issue, GHSA-rrgq-978q-36mq, carries a CVSS 3.1 score of 9.8. Under ArangoDB’s default system-only authentication mode, paths beginning with /_ require a login, while other paths may be treated as public application routes. The problem is that the authentication component evaluates the raw URL, but the routing component later works with its decoded form.

An attacker can replace the underscore in the protected API route with its URL-encoded equivalent. The initial security check sees a public-looking path and allows the request, yet the router decodes it and sends it to the protected API. This inconsistency is enough to cross the authentication boundary without credentials or user interaction.

Once inside the API, an outsider may read or modify collections and databases. Researchers demonstrated access to the root account’s password hash, which is protected using a single SHA-256 round and a 32-bit salt. Disclosure of that material creates an opportunity for offline password recovery and follow-on authenticated access.

Client-controlled flag unlocks system tasks

The second flaw, GHSA-rvhw-4hpw-9vrx, has a CVSS score of 9.9 and affects the HTTP interface for scheduling JavaScript background tasks. A user with database write permissions can set the request field isSystem to true, causing the task to run in an internal execution context intended only for ArangoDB itself.

Although the internal JavaScript API verifies that a caller is truly privileged before creating a system task, the HTTP handler did not impose the same restriction. A Boolean supplied by the client therefore becomes the difference between sandboxed database work and access to host-level capabilities.

In that system context, JavaScript can read or write local files and make outbound network requests. The official ArangoDB container runs the database process as root, meaning an attacker could potentially read operating-system password data, TLS keys, environment variables and cluster secrets. File writes could establish persistent code execution by changing authentication or service configuration. Outbound requests also create a path to internal services and cloud metadata endpoints.

Chaining the bugs raises the impact

The authentication bypass can expose sensitive database data and the root password hash. With database write access, the task vulnerability can then escape the expected execution boundary and compromise the operating system. The sequence requires no phishing and no stolen password, making public exposure the most important immediate risk factor.

ArangoDB received the reports on August 23, 2026 and issued fixes in version 3.12.11 on August 31. Advisories followed on September 6, while CVE identifiers had not yet been assigned at the time of reporting.

Upgrade and assess potential exposure

Administrators should update to ArangoDB 3.12.11 or later without delay. Systems that were internet-accessible while vulnerable warrant investigation rather than patching alone.

• Restrict database interfaces to trusted networks and authenticated administrative paths.
• Review API logs for unusual path encoding, database access and unexpected task creation.
• Rotate database passwords, TLS keys and other secrets stored on exposed hosts.
• Inspect containers and servers for modified files, new login credentials and suspicious outbound requests.
• Run the database as a dedicated non-root identity wherever operationally possible.

The flaws underline a broader engineering lesson: authorization should occur after canonicalizing a request, and every handler must apply the same decision. No value supplied by an external client should be able to assert an internal system identity.