/

CVE-2026-67357

Severity:

HIGH RISK

(7.5)

Cleartext Cluster Token Leak (CWE-200) in ArcadeDB MCP

CVE-2026-67357

Deferred

Vulnerability type

Category:

Information Disclosure

CWE:

CWE-200

Impact:

Authentication Bypass and Full Server Compromise

Severity:

HIGH RISK

(7.5)

CVSS version:

3.1

Catch this CVE while code is being written

Detect vulnerable code directly in pull requests, so CVEs are fixed before merge.

Summary

ArcadeDB exposes a cleartext high-availability cluster token via the MCP get_server_settings tool, allowing information disclosure of sensitive authentication material.

An attacker with MCP access can retrieve this token and reuse it in special headers to impersonate the root user, potentially leading to full server compromise.

Affected context

This vulnerability occurs in ArcadeDB deployments that:

  • Enable the MCP get_server_settings tool for operational or diagnostic purposes
  • Store the arcadedb.ha.clusterToken as a shared secret for cluster or administrative authentication
  • Do not restrict or compartmentalize MCP access from general users or automated systems

Under these conditions, the cluster token becomes accessible in cleartext to any principal that can invoke the MCP tool, expanding the effective authentication boundary.

Exploit preconditions

  • Attack surface: MCP get_server_settings interface within ArcadeDB
  • Required access: Ability to invoke MCP operations (logical MCP access, not necessarily OS-level access)
  • Trigger point: Calling the get_server_settings tool and reading its output, which includes arcadedb.ha.clusterToken
  • Why exploitation is possible: The cluster token is treated as non-sensitive configuration and returned verbatim, enabling its reuse in X-ArcadeDB-Cluster-Token and X-ArcadeDB-Forwarded-User headers to impersonate privileged users such as root.

Why this happens

The underlying issue is a failure to treat authentication secrets as confidential data within management and configuration tooling.

The MCP get_server_settings tool returns sensitive values, including the cluster token, without redaction, masking, or access-tier separation.

This aligns with CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, where internal security credentials are exposed through diagnostic or configuration interfaces, allowing them to be repurposed for unauthorized access.

Potential impact

  • Attackers may impersonate the root user and gain administrative privileges.
  • Adversaries could fully compromise the ArcadeDB server, including data read, modification, and deletion.
  • Cluster operations and configuration may be altered, potentially disrupting availability or integrity.
  • Existing authentication and authorization controls can be bypassed by replaying the leaked token.

General mitigation guidance

Effective mitigation typically focuses on reducing exposure of sensitive configuration data and narrowing trust boundaries around management tooling.

Patterns that help include:

  • Treating cluster tokens, API keys, and shared secrets as confidential and never returning them in plaintext from diagnostic or configuration interfaces.
  • Introducing role-based separation between operational tooling and regular user-facing access, so only tightly controlled identities can query sensitive server settings.
  • Redacting or masking secret values in configuration outputs, logging, and monitoring channels.
  • Designing token-based authentication to minimize reuse and consider binding secrets to specific contexts or scopes, reducing the impact if a token is exposed.
  • Applying least-privilege principles to management protocols, ensuring that high-impact headers (e.g., impersonation headers) cannot be abused by generic tokens.

How teams detect issues like this

Organizations can detect and monitor this class of exposure using:

  • Configuration and code reviews focused on management and diagnostic endpoints, checking for direct exposure of secrets such as tokens, passwords, or keys.
  • Static analysis rules that flag returning sensitive configuration fields in API responses or tooling outputs.
  • Security policies that mandate redaction of secret-bearing fields before they leave the server, enforced via middleware or response filters.
  • Runtime monitoring and audit logs to detect suspicious use of X-ArcadeDB-Cluster-Token and impersonation headers, correlating them with MCP access to get_server_settings.
  • Periodic secret discovery scans on logs, config dumps, and tool outputs to identify inadvertently exposed authentication material.

Sources

SourceLink
github.comgithub.com/ArcadeData/arcadedb/security/advisories/GHSA-p9wc-4fhr-78wm
vulncheck.comvulncheck.com/advisories/arcadedb-information-disclosure-via-get-server-settings

Frequently asked

questions

Yes, if MCP access is exposed over the network and reachable by an attacker, they can remotely query the get_server_settings tool, retrieve the cluster token, and use it in headers to impersonate root.

The attacker must have the ability to invoke MCP operations, which may be tied to a specific role or service. They do not need prior knowledge of the token itself; the tool discloses it in cleartext once accessed.

Ensure that management and diagnostic endpoints never return secrets directly. Redact or mask sensitive fields, and separate highly privileged administration capabilities from routine operational interfaces through strict access control.

Adopt a secure-by-design approach for configuration and monitoring tools: classify sensitive fields, enforce redaction in all outputs, implement role-based access for management APIs, and include checks for secret exposure in code review and automated security testing pipelines.

Find out what's already
exploitable in your codebase.