CVE-2026-55678: Unauthenticated Node Registration and Credential Leakage in Arc Enterprise Clustering

Arc is an open-source, SQL-native time-series database designed for telemetry ingestion and high-performance querying. In enterprise deployments, Arc supports multi-node clustering controlled by a centralized coordinator component. The coordinator listens on TCP port 9100 by default and manages member registrations, cluster state distribution, and peer routing.

Between versions 26.02.1 and 26.06.2, Arc suffers from an authentication bypass vulnerability within its cluster-coordinator join protocol. The vulnerability surfaces when clustering is enabled but the optional shared secret (cluster.shared_secret) is left unconfigured. In this configuration, the coordinator fails to validate the identity of joining nodes or enforce signature verification, allowing any network-adjacent entity to manipulate the topology.

While standalone or unlicensed open-source single-node deployments are unaffected due to clustering being disabled by default, Enterprise environments that activate clustering without explicitly defining a secure shared secret are fully vulnerable. This issue exposes clusters to arbitrary node registration, metadata tampering, and active man-in-the-middle operations.

The root cause of CVE-2026-55678 resides within the conditional verification logic implemented in internal/cluster/coordinator.go. During the initial execution of a cluster join handshake, the coordinator performs cryptographic signature validation of incoming requests only if a shared secret is explicitly specified in the database configuration.

// Logical flaw in legacy join validation path:
if c.cfg.SharedSecret != "" {
    // Perform HMAC validation of the join request
    if err := security.ValidateHMAC(...); err != nil {
        return err // Rejected
    }
}
// If SharedSecret was empty, the validation block was silently skipped,
// immediately falling through to accept the JoinRequest!

If cluster.shared_secret is left blank, the validation block is skipped entirely. The coordinator falls back to matching only the static, non-random, and highly predictable cluster name string (defaulting to arc-cluster). This design allows arbitrary JoinRequest messages containing the correct cluster name to succeed without cryptographic proof of identity.

Furthermore, the legacy heartbeat protocol implemented in internal/cluster/protocol/messages.go lacked any authentication field or transaction verification. This omission meant that even if a cluster configured a shared secret for initial joins, subsequent node state changes and liveness check heartbeats occurred completely unauthenticated. Attackers could spoof heartbeats for arbitrary node IDs, altering the coordinator's status registry without possessing the cluster secret.

Finally, the query router (internal/cluster/router.go) performs request forwarding to specific nodes based on target partition keys. When the query router forwards a request, it clones and transmits the exact administrative headers—including the user's Authorization bearer tokens and x-api-key values—directly to the target node. By registering as a valid cluster member, a rogue node becomes an active recipient of these forwarded HTTP requests and their corresponding authentication tokens.

A detailed review of the patch in commit 38402ad2ebddd32c15bf4a0fc9c22c920e5685df reveals how the validation gaps were closed. The developers replaced the fail-open logic with a strict startup guard inside cmd/arc/main.go, making a shared secret mandatory whenever clustering is enabled:

// cmd/arc/main.go
+ // Clustering requires shared-secret auth on the coordinator
+ // protocol. Without it, the coordinator validates no HMAC on
+ // join/heartbeat/leave messages (the checks are gated on a
+ // non-empty secret), so any host that can reach the coordinator
+ // port could join as a trusted node. Fail closed rather than
+ // run an unauthenticated cluster (GHSA-p378-jp5r-gpgw).
+ if cfg.Cluster.SharedSecret == "" {
+     log.Error().Msg("cluster.enabled requires ARC_CLUSTER_SHARED_SECRET to be set")
+     os.Exit(1)
+ }

In addition, cryptographic validation variables were appended directly to the base Heartbeat schema within internal/cluster/protocol/messages.go. This guarantees that liveness state updates are bound to signature validation mechanisms:

// internal/cluster/protocol/messages.go
type Heartbeat struct {
 	State     string    `json:"state"`
 	IsLeader  bool      `json:"is_leader"`
 	Timestamp time.Time `json:"timestamp"`
+ 	AuthNonce     string `json:"auth_nonce,omitempty"`
+ 	AuthTimestamp int64  `json:"auth_timestamp,omitempty"`
+ 	AuthHMAC      string `json:"auth_hmac,omitempty"`
 }

Lastly, the coordinator handles the validation inside internal/cluster/coordinator.go by verifying the calculated HMAC against the inbound heartbeat parameters, ensuring unauthenticated heartbeats are dropped:

// internal/cluster/coordinator.go
+ if c.cfg.SharedSecret != "" {
+     if hb.AuthHMAC == "" {
+         c.logger.Warn().Str("node_id", hb.NodeID).Msg("Heartbeat rejected: shared secret required")
+         return
+     }
+     if err := security.ValidateHMAC(
+         c.cfg.SharedSecret, hb.AuthNonce, hb.NodeID, c.cfg.ClusterName,
+         hb.AuthTimestamp, hb.AuthHMAC, security.HMACTimestampTolerance,
+     ); err != nil {
+         c.logger.Warn().Err(err).Str("node_id", hb.NodeID).Msg("Heartbeat rejected: auth failed")
+         return
+     }
+ }

Exploiting CVE-2026-55678 requires the attacker to have direct network visibility of the coordinator port (default :9100) and knowledge of the non-random cluster name. The execution sequence involves crafting a malicious JoinRequest and monitoring incoming connections to harvest forwarded user query details.

Initially, the attacker constructs a structured payload simulating a legitimate database host. The payload maps its local interface as the registration endpoint for routing:

{
  "node_id": "rogue-node-01",
  "role": "writer",
  "raft_addr": "attacker_ip:9101",
  "api_addr": "attacker_ip:8080",
  "coord_addr": "attacker_ip:9100"
}

Upon transmitting this packet directly to the coordinator, the target environment validates the request parameters. Since no cluster secret is present, the signature validation phase is bypassed. The registry database appends rogue-node-01 into its topological routing table.

As clients submit write requests or query telemetry, the database routing engine evaluates the partitioning hashes. When a query is directed to a partition mapped to rogue-node-01, the query router replicates the HTTP payload to attacker_ip:8080. The attacker extracts the inbound HTTP header Authorization or x-api-key values, yielding administrative credentials.

While the implemented patch mitigates the default authentication bypass, a complete security assessment highlights specific operational characteristics that require defense-in-depth controls.

The current patch relies on a timestamp-based tolerance window (security.HMACTimestampTolerance) to evaluate incoming heartbeats and join messages. Because the implementation lacks a stateful cache to record and invalidate consumed AuthNonce values within the tolerance timeframe, a network adversary capable of sniffing local coordinator traffic can capture a valid heartbeat and successfully replay it until the expiration threshold is exceeded.

Additionally, if TLS transport security (cluster.tls_enabled) is disabled, cluster coordination packets and client queries pass across the local network in plaintext. While the control plane payload is cryptographically signed, transit encryption is necessary to block passive interception of the data payloads and authorization structures themselves. Implementation teams must ensure that both authentication and encryption parameters are strictly configured.