Summary
ArcadeDB exposes the high-availability cluster token in cleartext via the /api/v1/server endpoint, allowing authenticated users to retrieve sensitive authentication material.
With this token, an attacker can impersonate the root user through crafted headers and perform administrative actions such as managing users, databases, or shutting down the server.
Affected context
The vulnerability appears in ArcadeDB deployments that:
- Expose the
/api/v1/serverHTTP endpoint to authenticated users - Use high-availability clustering with a shared
arcadedb.ha.clusterToken - Rely on headers such as
X-ArcadeDB-Cluster-TokenandX-ArcadeDB-Forwarded-Userfor administrative authentication and identity delegation
In these environments, the cluster token is returned unredacted in API responses, expanding the effective trust boundary to any account that can query server metadata.
Exploit preconditions
- Attack surface: HTTP management API at
/api/v1/server - Required access: Any authenticated user capable of calling the server information endpoint
- Trigger point: Issuing a GET request to
/api/v1/serverand inspecting the returned configuration data - Why exploitation is possible: The implementation returns
arcadedb.ha.clusterTokenin cleartext and the server subsequently treats possession of this token (plus headers likeX-ArcadeDB-Forwarded-User) as sufficient proof of administrative identity, without binding it to a stronger authentication context
Why this happens
This issue stems from mishandling of sensitive configuration values in an administrative API response.
Instead of redacting or omitting authentication-related fields, the server includes the arcadedb.ha.clusterToken verbatim, effectively disclosing a shared secret that governs cluster- and admin-level operations.
Conceptually, this aligns with CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, where internal security tokens are treated as regular informational data and leaked over interfaces accessible beyond their intended audience.
Potential impact
- Authenticated users may escalate privileges to root-equivalent access.
- Attackers can create, modify, or delete user accounts.
- Databases can be created, dropped, or altered without proper authorization.
- The server can be shut down, causing denial of service.
- Cluster control channels and administrative workflows can be hijacked or disrupted.
General mitigation guidance
Effective mitigation focuses on minimizing the exposure and reliance on shared secrets within observable interfaces.
Common defensive patterns include:
- Treating cluster tokens and similar shared secrets as highly sensitive and never returning them in API responses.
- Implementing structured redaction for configuration and diagnostic endpoints, ensuring secrets are masked or omitted by default.
- Binding administrative actions to strong, user-specific authentication and authorization checks rather than solely trusting a shared header-based token.
- Segmenting management APIs onto restricted networks or interfaces, with strict access controls and audit logging.
- Applying least privilege by narrowing which roles can invoke introspection endpoints that reveal server or cluster configuration details.
How teams detect issues like this
Organizations can detect this class of exposure by:
- Inspecting API responses for secrets: automated tests or security scanners that call management endpoints and search for tokens, keys, or passwords in returned JSON or configuration blobs.
- Using static analysis or code review checklists to flag direct inclusion of sensitive configuration values (e.g., tokens, passwords, API keys) in API DTOs or logging statements.
- Enforcing security review gates for new or modified administrative endpoints, focusing on the handling of configuration and diagnostic data.
- Applying policy-as-code (e.g., API gateway or WAF rules) to block or mask outbound fields known to contain sensitive secrets, as a compensating control.
