Description

ArcadeDB (com.arcadedb:arcadedb-server) versions <= 26.7.3 contain an insecure direct object reference (IDOR) vulnerability in the Raft cluster-info endpoints (GetClusterHandler and PostBootstrapStateHandler), which authenticate but do not authorize access. On an ArcadeDB HA cluster (only reachable when arcadedb.ha.enabled is set and the ha-raft module is loaded), any authenticated user — including one granted access to only one database or none — can enumerate the full server database registry and retrieve per-database metadata such as database names, last transaction IDs, bootstrap fingerprints, and peer/leader cluster topology, resulting in cross-database information disclosure. Fixed in 26.8.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-18T12:19:34.180Z",
  "pubdate": "2026-08-18T12:19:34.180Z",
  "executiveSummary": "An Insecure Direct Object Reference (IDOR) vulnerability exists in ArcadeDB (com.arcadedb:arcadedb-server) versions <= 26.7.3 within the Raft cluster-info endpoints (GetClusterHandler and PostBootstrapStateHandler).\nThe vulnerability arises because these endpoints perform authentication checks but lack proper authorization enforcement.\nThe impact includes cross-database information disclosure, allowing unauthorized enumeration of the full server database registry and retrieval of sensitive per-database metadata such as database names, last transaction IDs, bootstrap fingerprints, and peer or leader cluster topology.\nThe affected systems are ArcadeDB High Availability (HA) clusters where arcadedb.ha.enabled is configured and the ha-raft module is loaded.\nAttacker capabilities require valid authentication to the server, but exploitability extends to users who have been granted access to only a single database or even no databases at all.\nRisk implications center on unauthorized cluster topology mapping and leakage of internal database metadata to low-privileged or restricted principals.",
  "technicalDetails": "The root cause of the vulnerability is an authorization bypass categorized as an Insecure Direct Object Reference (IDOR) within specific Raft cluster-info endpoints, specifically GetClusterHandler and PostBootstrapStateHandler.\nWhile the application successfully validates the authentication status of the incoming request, it fails to enforce fine-grained access control or role-based authorization to verify whether the authenticated principal possesses the necessary privileges to access cluster-wide state and topology data.\nThe vulnerable component is the ha-raft module running within the ArcadeDB server context.\nThe affected versions comprise all ArcadeDB server releases up to and including version 26.7.3.\nNetwork exposure is restricted to instances where high availability is active, specifically when arcadedb.ha.enabled is set to true and the ha-raft module is actively loaded.\nAuthentication requirements dictate that the attacker must possess valid credentials to authenticate against the server; however, low-privileged accounts with restricted access to a single database or accounts with zero database permissions can successfully exploit the flaw.\nThe attack flow proceeds as follows: 1) The attacker authenticates to the ArcadeDB server using any valid user account, including those with minimal or absent database privileges. 2) The attacker sends an HTTP request targeting the vulnerable Raft cluster-info endpoints, specifically interacting with GetClusterHandler or PostBootstrapStateHandler. 3) Because the endpoints validate the session or credentials but omit authorization checks, the server processes the request. 4) The server responds by returning sensitive cluster state information. 5) The attacker receives the full server database registry, database names, last transaction IDs, bootstrap fingerprints, and the peer or leader cluster topology, achieving cross-database information disclosure."
}