ArcadeDB CVE-2026-75839

Exploitation requires two explicit prerequisites: (1) the target ArcadeDB instance must be deployed in high-availability mode with arcadedb.ha.enabled set and the ha-raft module loaded - this is a non-default configuration that must be deliberately enabled; (2) the attacker must hold at least one valid user credential on the ArcadeDB cluster, confirmed by the CVSS vector's PR:L designation - unauthenticated or anonymous access is insufficient. The cluster-info endpoints are reachable over the network (AV:N). Exploitation is limited by the HA deployment requirement (non-default, must be explicitly configured), the need for a valid account (even a minimal-permission one suffices), and the fact that only metadata is disclosed - actual database records, user credentials, or configuration secrets are not exposed through this path.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N) accurately characterizes the risk: network-accessible with low attack complexity, requiring only a low-privilege credential, with limited confidentiality impact and no integrity or availability consequences. The confidentiality impact is correctly bounded at low (VC:L) because only structural metadata - not actual database records or credentials - is disclosed. There is no CISA KEV listing and no public POC identified, which meaningfully reduces operational urgency. Real-world risk is highest in multi-tenant or shared HA deployments where database isolation is a formal security boundary; in single-tenant internal deployments the practical impact is reduced. The non-default HA deployment requirement further constrains the exposed population. The principal concern is reconnaissance enablement: the exposed cluster topology, database names, and transaction IDs could assist a low-privilege attacker in identifying high-value targets for follow-on attacks.

An attacker obtains any valid ArcadeDB user credential on a target HA cluster - for example, credentials to a low-sensitivity sandbox database in a multi-tenant deployment. They then issue authenticated HTTP requests directly to the GetClusterHandler or PostBootstrapStateHandler endpoints over the network; the server verifies their identity but skips authorization checks, returning the complete database registry including names of all hosted databases, their last transaction IDs, bootstrap fingerprints, and the full Raft peer/leader topology. No public exploit code has been identified at time of analysis, but the attack requires only standard HTTP tooling and a single valid credential.