CVE-2026-75839 in ArcadeDB
Summary
by MITRE • 08/18/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in ArcadeDB versions up to 26.7.3 represents a critical failure in access control mechanisms within the high-availability Raft clustering subsystem. Specifically, this is an insecure direct object reference (IDOR) flaw located in the GetClusterHandler and PostBootstrapStateHandler endpoints responsible for managing cluster information. While these API interfaces correctly implement authentication to verify the identity of the requesting user, they completely lack authorization checks to validate whether that authenticated user has permission to access the specific resources being requested. This architectural oversight allows any valid credential holder to bypass intended isolation boundaries between databases within a single ArcadeDB instance.
The operational impact of this vulnerability is significant for environments utilizing high-availability configurations where the ha-raft module is active and arcadedb.ha.enabled is set to true. An attacker possessing even minimal credentials, such as access to only a single database or no database at all, can exploit these endpoints to enumerate the entire server's database registry. By querying these unsecured cluster-info interfaces, an adversary can retrieve sensitive metadata for every database hosted on the server. This includes specific details such as database names, last transaction identifiers, bootstrap fingerprints used for node verification, and comprehensive peer and leader topology information regarding the cluster structure.
This cross-database information disclosure poses a severe risk to both confidentiality and integrity of the data infrastructure. The exposure of bootstrap fingerprints and cluster topology provides an attacker with critical intelligence necessary for planning more sophisticated attacks against the distributed system's consensus mechanism or specific database instances. Knowledge of transaction IDs can aid in replay attack scenarios or timeline reconstruction, while access to peer lists facilitates targeted network-level assaults on other nodes within the cluster. Consequently, this vulnerability effectively undermines the security model by allowing lateral movement and reconnaissance that should be strictly prohibited based on user privileges.
From a classification perspective, this flaw aligns with CWE-284, which describes Improper Access Control, specifically highlighting failures in authorization checks following authentication. In terms of offensive cybersecurity frameworks, it maps to MITRE ATT&CK technique T1078, Valid Accounts, as the exploitation relies on legitimate credentials being used improperly due to insufficient permissions enforcement. It also relates to T1005, Data from Local System, given the ability to enumerate and extract metadata about local database structures without proper authorization.
To mitigate this vulnerability, organizations running affected versions of ArcadeDB must immediately upgrade to version 26.8.1 or later where these access control gaps have been addressed. Until an upgrade is feasible, administrators should ensure that high-availability features are disabled if not strictly required for production workloads by setting arcadedb.ha.enabled to false and ensuring the ha-raft module is not loaded. Additionally, implementing network-level restrictions such as firewalls or reverse proxies can limit access to these internal cluster endpoints to only trusted management networks, reducing the attack surface available to potential adversaries who may have obtained valid user credentials through other means.