Critical ArangoDB Flaws Allow Authentication Bypass and Remote Code Execution as Root

Two critical flaws in ArangoDB can let an outsider bypass login controls, read or alter database data, and then gain root-level code execution on the underlying host.

The issues affect installations through version 3.12.10.1, creating serious risk for internet-facing databases and container deployments.

The attack does not rely on stolen passwords, a user click, or a complex exploit chain. A carefully encoded request can confuse two parts of the server about whether a protected application programming interface, or API, path is public.

Similar enterprise authentication bypass incidents show how this type of failure can open access to critical infrastructure. Remedio analysts identified the flaws while reviewing ArangoDB’s HTTP attack surface.

Remedio said in a report shared with Cyber Security News (CSN) that both bugs stem from the server trusting request-supplied information when deciding what a caller may do.

Critical ArangoDB Flaws Allow Authentication Bypass

The first flaw is tracked as GHSA-rrgq-978q-36mq and received a CVSS 3.1 score of 9.8. In ArangoDB’s default system-only authentication mode, paths beginning with /_ are meant to require a login, while other paths are treated as public application routes.

Researchers found that the authentication check examines the raw URL, but the routing code later interprets a decoded version.

Replacing the underscore in /_api with its URL-encoded form, %5f, causes the first component to see a public-looking path while the router reaches the restricted API endpoint. That small parsing disagreement is enough to bypass the login gate.

A request without credentials can reach protected database actions, allowing administrative access without credentials across collections and databases. The researchers demonstrated retrieval of the root account password hash, which uses one SHA-256 round and a 32-bit salt.

Task Setting Enables Root Execution

The second issue, GHSA-rvhw-4hpw-9vrx, affects ArangoDB’s HTTP interface for scheduling JavaScript background tasks.

It has a CVSS 3.1 score of 9.9 because a user with database write permission can set the request field isSystem to true and force a task into the server’s internal, highly privileged execution context.

Normally, that context is reserved for the server itself. The internal JavaScript API checks whether a caller is truly internal before allowing system tasks, but the HTTP handler did not apply the same protection.

The result is a client-controlled Boolean value acting as the boundary between sandboxed work and host-level privileges. Once a task runs in that context, it can read or write files on the host and make outbound web requests.

On the official container image, the arangod process runs as root, so file access can expose secrets such as /etc/shadow, TLS private keys, cluster signing material, or environment variables holding the root password.

File-writing permission also creates a practical path to remote code execution as root. An attacker could place an SSH authorized key, alter a scheduled task, or modify a service file that runs later.

Outbound requests could additionally reach internal services or cloud metadata endpoints, expanding compromise beyond the database host.

The flaws can be chained: the first bug can expose the root password hash, and the second can use authenticated database write access to escape into the privileged task environment.

This combination makes the report important for teams watching critical remote code execution flaws in systems that sit close to valuable data.

ArangoDB received the reports on August 23, 2026, and shipped fixes on August 31 in version 3.12.11. Advisories were published on September 6, while CVE identifiers were still pending.

Organizations using version 3.12.10.1 or earlier should upgrade immediately, restrict database exposure to trusted networks, rotate potentially exposed credentials, and investigate unexpected task creation or API activity.

The broader lesson is simple: secure components can still fail when they interpret the same request differently. Developers should normalize and authorize requests once, apply the same decision across handlers, and never allow client input to claim system-level privileges.

Lessons in patched critical vulnerability reports show why rapid updates and exposure reduction are essential when a flaw can lead directly to administrative control.

Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection.