Skip to content

Raft cluster-info endpoints leak cross-database metadata to any authenticated user (IDOR)

Moderate
robfrank published GHSA-79wq-w74x-74ch Aug 4, 2026

Package

maven com.arcadedb:arcadedb-server (Maven)

Affected versions

<= 26.7.3

Patched versions

26.8.1

Description

Summary

On an ArcadeDB HA cluster, the Raft cluster-info endpoints authenticate but do not authorize: they enumerate the full server database registry and return per-database metadata (names, bootstrap fingerprints, last transaction ids) plus peer/leader topology to ANY authenticated user, including one granted access to only one database or none. This is a cross-database information-disclosure IDOR.

Root Cause

GetClusterHandler.execute and PostBootstrapStateHandler.execute perform authentication but contain no checkRootUser, canAccessToDatabase, or getAuthorizedDatabases call (grep = 0), unlike every mutating Raft sibling (PostAddPeer, PostTransferLeader, PostStepDown, PostLeave, DeletePeer, PostResyncDatabase, PostVerifyDatabase) which call checkRootUser. Both read handlers loop httpServer.getServer().getDatabaseNames() (the full registry) and emit per-database metadata (GetClusterHandler.java:131; PostBootstrapStateHandler emits fingerprints). The canonical GetDatabasesHandler proves the intended design: it does installedDatabases.retainAll(allowedDatabases) — the cluster handlers omit that filter. GetServerHandler?mode=cluster similarly leaks db names + quorum + peer/leader addresses on any HA server.

Impact

Authenticated cross-database reconnaissance: a tenant scoped to one database learns the names, transaction ids, and (on the ha-raft path) directory fingerprints of all other tenants' databases plus cluster topology. Metadata-only confidentiality impact.

Proof of Concept

# alice granted only db 'foo' (or zero dbs)
GET /api/v1/cluster            -> databases[] with finance/hr names, txids, peer/leader addrs
POST /api/v1/cluster/bootstrap-state {}   -> per-db SHA-256 fingerprints across peers

Attack Chain

  1. Entry: authenticate as low-priv alice; GET /api/v1/cluster. Guard: AbstractServerHttpHandler.handleRequest requires a valid user (:176-183). Bypass proof: alice's valid creds pass; execute() calls no authz gate (GetClusterHandler.java:65-161, grep = 0 authz calls).
  2. Read databases[]. Guard: none — loop over getDatabaseNames() (:131) with no retainAll(getAuthorizedDatabases()). Bypass proof: foo-only alice receives finance/hr names + txids + peer addresses.

Bypass Evidence

GetClusterHandler.java:131 and :208 iterate getDatabaseNames(); no canAccessToDatabase/getAuthorizedDatabases/checkRootUser in the handler (verified on 26.7.3). Not covered by GHSA-x8mg (guards named-db-in-path handlers) nor GHSA-46hj (redacted clusterToken via isHidden in exportSettings).

Affected Versions

<= 26.7.3. Reachable only when HA is enabled (arcadedb.ha.enabled, default false) and the ha-raft module is loaded; GetServerHandler?mode=cluster leaks names/quorum/addresses on any HA server.

Suggested Fix

Apply the GetDatabasesHandler pattern — retainAll(user.getAuthorizedDatabases()) — to the cluster handlers, or restrict the cluster-info endpoints to root (matching the mutating Raft siblings).


Reported by zx (Jace) — GitHub: @manus-use

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
Low
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

CVE ID

No known CVE

Weaknesses

Exposure of Sensitive Information to an Unauthorized Actor

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information. Learn more on MITRE.

Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. Learn more on MITRE.

Credits