ArcadeDB CVE-2026-67343

Exploitation requires a valid ArcadeDB user account at any privilege level - the GET /api/v1/server endpoint is accessible to all authenticated users, not just administrators. Network access to the ArcadeDB REST management API port is also required. The key limiting condition is initial credential possession: unauthenticated exploitation is not possible. Deployments where the /api/v1/server endpoint is restricted to administrator accounts only via network policy or access controls are not exploitable via this vector. The vulnerability is most dangerous in environments with multiple users of differing trust levels, or where ArcadeDB credentials have been shared, leaked, or obtained through phishing. The arcadedb.ha.clusterToken must be set in the server configuration for the token to be exposed - deployments that have never configured HA clustering may not have this value populated, which would limit the second stage of the attack.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) accurately reflects the high real-world severity for deployments where any authenticated user exists who should not have root access. Attack complexity is genuinely low - the token is retrieved in a single API call, and its reuse requires only standard HTTP header injection. The sole limiting factor is PR:L: an attacker must hold valid ArcadeDB credentials before exploiting this path, which meaningfully reduces risk for deployments with tightly controlled user provisioning. No EPSS score was provided in the input data, so exploitation probability cannot be quantitatively assessed. The CVE is not listed in CISA KEV, and no public proof-of-concept code has been identified, meaning opportunistic mass exploitation is not confirmed. Despite the absence of active exploitation signals, the triviality of the attack chain and the severity of the resulting access (root impersonation, server shutdown capability) make this a high-priority patch for any ArcadeDB deployment in shared or multi-tenant environments. HA-enabled deployments are at elevated risk because the cluster token has an active operational purpose and is more likely to be present.

An attacker with a low-privileged ArcadeDB account issues a GET request to /api/v1/server and parses the JSON response to extract the arcadedb.ha.clusterToken value in cleartext. The attacker then crafts subsequent HTTP requests to administrative API endpoints, setting the X-ArcadeDB-Cluster-Token header to the stolen token and the X-ArcadeDB-Forwarded-User header to the root username, bypassing all authorization checks. From this root-impersonation position, the attacker creates a persistent backdoor account, exfiltrates database contents, or issues a server shutdown command.