Critical ArangoDB Flaws Allow Auth Bypass, RCE as Root

Key Takeaways

• Two critical vulnerabilities in ArangoDB, rated 9.8 and 9.9 CVSS, enable authentication bypass and remote code execution as root.
• Affected versions include ArangoDB installations up to and including 3.12.10.1.
• The flaws can be chained to gain complete control over affected database instances and their underlying hosts.
• The issues stem from inconsistent URL parsing and insufficient validation of client-supplied execution context.
• Patches were released on August 31 in version 3.12.11, and immediate upgrades are strongly recommended.

Two severe vulnerabilities have been discovered in ArangoDB, a popular multi-model database system, that could allow an unauthenticated attacker to bypass login controls, manipulate database content, and achieve root-level remote code execution on the host machine. These critical flaws affect all ArangoDB installations through version 3.12.10.1, posing a significant risk, particularly for internet-exposed databases and containerized deployments.

The exploitation of these vulnerabilities does not require stolen credentials, user interaction, or a complex attack chain. Instead, a specially crafted request can exploit a discrepancy in how different server components interpret API paths, effectively tricking the system into granting unauthorized access. This type of authentication bypass has been observed in other enterprise incidents, highlighting its potential to compromise critical infrastructure. Remedio analysts uncovered these issues during a review of ArangoDB’s HTTP attack surface. Remedio said in a report that both bugs originate from the server’s undue trust in client-supplied information when determining access permissions.

Critical ArangoDB Flaws Allow Authentication Bypass

The first vulnerability, identified as GHSA-rrgq-978q-36mq, carries a CVSS 3.1 score of 9.8, categorizing it as critical. In ArangoDB’s default system-only authentication mode, paths beginning with /_ are intended to require authentication, while other paths are treated as public application routes.

Researchers discovered that the authentication check processes the raw URL, but the subsequent routing logic interprets a URL-decoded version. By replacing the underscore in a protected path like /_api with its URL-encoded equivalent, %5f, an attacker can bypass the initial authentication barrier. The authentication component sees a seemingly public path, while the router correctly identifies and accesses the restricted API endpoint. This subtle parsing inconsistency is sufficient to circumvent the login mechanism.

This authentication bypass allows unauthenticated requests to access protected database actions, granting administrative privileges across all collections and databases without valid credentials. As a proof of concept, researchers successfully demonstrated the retrieval of the root account password hash, which is secured using a single SHA-256 round and a 32-bit salt.

Task Setting Enables Root Execution

The second critical vulnerability, GHSA-rvhw-4hpw-9vrx, affects ArangoDB’s HTTP interface for scheduling JavaScript background tasks and boasts an even higher CVSS 3.1 score of 9.9. This flaw permits a user with existing database write permissions to elevate their privileges to the server’s highly privileged internal execution context by setting the isSystem request field to true.

Normally, this system context is strictly reserved for internal server operations. While the internal JavaScript API includes checks to verify if a caller is truly internal before allowing system tasks, the HTTP handler for task scheduling failed to implement this crucial protection. Consequently, a client-controlled Boolean value effectively dictates the boundary between a sandboxed environment and host-level privileges. Once a task executes within this elevated context, it gains the ability to read and write files on the host system and initiate outbound web requests.

On the official ArangoDB container image, the arangod process typically runs with root privileges. This means file access could expose sensitive information such as /etc/shadow, TLS private keys, cluster signing materials, or environment variables containing root passwords. Furthermore, the ability to write files provides a practical avenue for achieving remote code execution as root. An attacker could, for example, inject an SSH authorized key, modify a scheduled task, or alter a service configuration file that would be executed later. The capability for outbound requests could also be leveraged to compromise internal services or cloud metadata endpoints, extending the attack beyond the immediate database host.

These two vulnerabilities can be chained together: the authentication bypass (GHSA-rrgq-978q-36mq) can be used to obtain the root password hash, and subsequently, with authenticated database write access, the privilege escalation (GHSA-rvhw-4hpw-9vrx) can be exploited to escape into the privileged task environment. This potent combination makes these findings particularly critical for organizations managing sensitive data with ArangoDB.

ArangoDB received the vulnerability reports on August 23, 2026, and swiftly released patches on August 31 in version 3.12.11. Advisories were published on September 6, with CVE identifiers pending at the time. Organizations utilizing ArangoDB versions 3.12.10.1 or earlier must upgrade immediately to mitigate these severe risks.

What You Should Do

• Upgrade Immediately: Update all ArangoDB installations to version 3.12.11 or newer without delay.
• Restrict Network Exposure: Limit direct database exposure to only trusted internal networks. Avoid exposing ArangoDB instances directly to the internet unless absolutely necessary, and then only through robust access controls.
• Rotate Credentials: Assume that credentials, particularly the root password hash, may have been exposed. Rotate all database credentials, especially for the root account, immediately after patching.
• Monitor for Suspicious Activity: Investigate any unexpected task creation, modifications to scheduled tasks, or unusual API activity within your ArangoDB instances.
• Implement Principle of Least Privilege: Ensure that the ArangoDB process runs with the lowest possible privileges on the host system, especially in containerized environments, to minimize the impact of potential escapes.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.