ArcadeDB CVE-2026-67357

Exploitation requires authenticated MCP access to the ArcadeDB instance - the attacker must hold valid credentials permitting invocation of the get_server_settings MCP tool (PR:L confirmed by CVSS 4.0 vector). The full privilege-escalation chain additionally requires that the High Availability feature is enabled and arcadedb.ha.clusterToken is set in the server configuration; without a configured cluster token, the stolen credential has no replaying value. AT:P in the CVSS 4.0 vector confirms this deployment-specific prerequisite. Limiting factors include: authentication required (no anonymous exploitation path), high attack complexity (AC:H), prerequisite cluster configuration (AT:P), and the niche deployment footprint of ArcadeDB HA clusters. The information disclosure of get_server_settings occurs on any MCP-enabled deployment; the escalation to root is gated on HA being active.

The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) correctly captures the duality of this vulnerability: the impact metrics are maximal (full confidentiality, integrity, and availability compromise of the vulnerable system), but the attack complexity is high and specific prerequisites apply. PR:L confirms exploitation requires authenticated MCP access - opportunistic mass exploitation against anonymous internet-facing endpoints is not the threat model. AT:P (attack prerequisites present) reflects that the HA cluster token must be actively configured for the second-stage privilege escalation to succeed; the information disclosure occurs regardless, but the path to root requires a clustered deployment. No EPSS score was provided, preventing quantitative exploitation probability assessment - this gap should be noted when prioritizing. The vulnerability is not in the CISA KEV catalog and no POC is publicly known. Despite the lack of active exploitation signals, the chained impact (low-priv info disclosure → root impersonation) warrants urgent patching for any deployment where MCP access is granted to untrusted or semi-trusted users.

An attacker holding a low-privilege ArcadeDB MCP account calls the get_server_settings tool and parses the response to extract the arcadedb.ha.clusterToken value returned in cleartext. The attacker then issues HTTP requests to the ArcadeDB server with the X-ArcadeDB-Cluster-Token header set to the stolen token and X-ArcadeDB-Forwarded-User set to 'root,' causing the server to treat the request as originating from the root administrator. No public proof-of-concept code is known at time of analysis, but the attack requires no special tooling beyond a standard HTTP client.