Executive brief
Arc Enterprise's clustering feature fails to authenticate join requests when the shared secret is not configured, allowing an unauthenticated network attacker to register a malicious node that will receive forwarded database queries and write operations along with credentials (bearer tokens, API keys). An attacker can then observe or intercept sensitive data, forge responses, or disrupt cluster operations. The vulnerability only affects deployments with clustering explicitly enabled; the default standalone configuration is unaffected.
Technical details
The vulnerability is an authentication bypass in the cluster join mechanism. The coordinator validates HMAC-based authentication only when cluster.shared_secret is non-empty; if empty (the default when clustering is enabled), join requests proceed with only a cluster-name check. An attacker on the network can send a crafted JoinRequest message specifying attacker-controlled node_id, role, api_addr, and raft_addr fields. The coordinator accepts this, creates a healthy node entry in its registry, and routes subsequent operations to the attacker's advertised addresses, forwarding all original request headers including Authorization and x-api-key. Heartbeat messages are similarly unauthenticated. The code conditionally enforces shared-secret validation only for file replication; this inconsistency allows clustering to proceed without authentication despite clustering being a trust boundary. Network reachability to the coordinator port (default 9100) is required; the attacker must know or guess the cluster name (default "arc-cluster").
Affected products
- Basekick Labs Arc < 0.0.0-20260615160325-38402ad2ebdd
Timeline
- 2026-06-25: disclosed
- 2026-08-28: advisory: GitHub advisory published
- 2026-06-15: patched: Patch version 0.0.0-20260615160325-38402ad2ebdd