Critical ArangoDB Bugs Expose Entire Databases and Enable Remote Code Execution as Root

Two critical ArangoDB vulnerabilities can allow unauthenticated attackers to access protected database APIs and, after obtaining valid database access, escalate to root-level code execution on affected hosts.

Security researchers reported the vulnerabilities to ArangoDB on August 23, 2026. Patches shipped on August 31, followed by GitHub Security Advisories published on September 6: GHSA-rrgq-978q-36mq for the authentication bypass and GHSA-rvhw-4hpw-9vrx for the privileged task-execution issue.

Both have been rated Critical, with CVSS 3.1 scores of 9.8 and 9.9 respectively. CVE identifiers were pending assignment at disclosure time.

The first issue stems from a parser discrepancy between ArangoDB’s authentication gate and its HTTP request router.

ArangoDB treats paths beginning with /_api and /_admin as protected endpoints, while paths not beginning with /_ can be considered unauthenticated application routes when system-only authentication is enabled by default.

However, the authorization component evaluates the raw path received from the network, while the router later evaluates URL-decoded path components.

An encoded underscore, %5f, is not interpreted as an underscore during the initial prefix check but becomes one when the router resolves the destination.

As a result, a request targeting /%5fapi/... may pass the unauthenticated-path validation because its raw form does not begin with /_.

The routing layer then decodes %5fapi into _api and dispatches the request to a normally protected ArangoDB REST API handler.

The distinction is operationally severe. A normal request to /_api/... without credentials returns 401 Unauthorized.

Replacing only the first underscore with %5f can reach the underlying privileged endpoint without a session, password, or token.

With a valid method and request structure, an attacker could read, modify, or delete data in ArangoDB databases.

Researchers demonstrated access to sensitive system collections, including the document containing the root account’s password hash.

Remedio Researchers said that, the vulnerabilities, fixed in ArangoDB 3.12.11, demonstrate how inconsistent URL parsing and a client-controlled privilege flag can collapse authentication and execution boundaries.

ArangoDB Vulnerabilities

The vulnerability is tracked as GHSA-rrgq-978q-36mq and carries a CVSS vector of CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, reflecting network exploitation without authentication or user interaction.

HTTP Method PUT with a HTTP request body → then HTTP response is 200 OK, and the secret document comes straight back – still nobody logged in.

The second vulnerability affects ArangoDB’s HTTP interface for scheduled background tasks. Tasks execute JavaScript and support separate sandboxed and internal execution contexts.

The internal context is intended for server-controlled operations and can access capabilities unavailable to ordinary user tasks.

The vulnerable HTTP handler accepted an isSystem Boolean directly from the client request body and used it to select the task context.

A 405 Unsupported method response is an important indicator: it shows the authentication barrier was bypassed and the request reached the protected handler, even if the selected HTTP verb is invalid.

Setting isSystem: true could cause submitted JavaScript to execute in ArangoDB’s internal context, despite the caller not being an internal component.

A separate internal JavaScript API contained an explicit check that rejected non-internal attempts to create system tasks.

The HTTP route lacked that equivalent authorization check, leaving the JSON field itself as the privilege boundary.

Once an attacker has authenticated database write access potentially by exploiting the first bug to retrieve and crack weak credentials the vulnerability can provide broad host-level capabilities.

Internal-context tasks can read and write files outside the normal sandbox and make outbound HTTP requests. That creates paths to secret theft, persistence, lateral movement through SSRF, and host compromise.

The impact is especially serious in deployments where arangod runs as root, including the official container image described in the disclosure.

Under those conditions, arbitrary file write can become practical root-level remote code execution even when direct process-spawning functionality is disabled.

An attacker could potentially write to SSH authorized-key locations, scheduled-task configurations, startup scripts, or other files consumed by privileged services.

Internal file reads could also expose /etc/shadow, TLS private keys, cluster secrets, and environment variables such as ARANGO_ROOT_PASSWORD when present in container process environments.

The second issue, GHSA-rvhw-4hpw-9vrx, is rated CVSS 9.9 with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

It requires privileges, but the scope changes because code executing through the database process can affect the underlying host.

Organizations should upgrade to ArangoDB 3.12.11 or a later supported security release immediately.

ArangoDB’s 3.12 branch remains supported, and 3.12.11 is listed as the current release in public release-tracking sources.

Defenders should also review reverse-proxy, WAF, and application logs for requests containing URL-encoded underscore sequences such as %5fapi or %5Fapi, particularly when followed by API paths.

Investigators should hunt for unexpected scheduled tasks, task definitions containing isSystem: true, modifications to database system collections, and anomalous outbound traffic from ArangoDB servers.

The two bugs are a reminder that secure components do not guarantee a secure system. Authorization must be enforced after canonicalization, and privileged execution modes must be decided by trusted server-side state not a client-supplied JSON field.

★ Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.