CVE-2026-55678 Overview
CVE-2026-55678 is an access control weakness [CWE-284] in Arc, an open, SQL-native time-series database for telemetry developed by Basekick Labs. Arc Enterprise clustering accepts cluster join requests without authentication when cluster.enabled is true but cluster.shared_secret is left empty. An unauthenticated network attacker who can reach the coordinator port and knows the cluster name can join as a trusted node, mutate cluster membership, become a Raft voter, and intercept forwarded requests that carry Authorization and x-api-key headers. The issue affects Arc Enterprise versions 26.02.1 through 26.06.1 and is fixed in 26.06.2.
Critical Impact
A rogue node can join the cluster without credentials, receive forwarded queries and writes with their authentication headers, and forge or blackhole database operations.
Affected Products
- Arc Enterprise 26.02.1 through 26.06.1 (clustering enabled, no shared secret)
- Basekick Labs Arc time-series database (Enterprise cluster deployments)
- Standalone Arc configurations are not affected because cluster.enabled defaults to false
Discovery Timeline
- 2026-08-28 - CVE-2026-55678 published to NVD
- 2026-09-01 - Last updated in NVD database
Technical Details for CVE-2026-55678
Vulnerability Analysis
The flaw lives in Arc's cluster coordinator protocol. In internal/config/config.go, defaults set cluster.enabled to false, cluster.cluster_name to arc-cluster, cluster.coordinator_addr to :9100, cluster.shared_secret to empty, and cluster.tls_enabled to false. The startup logic in cmd/arc/main.go required a shared secret only when cluster.replication_enabled was set, so operators could enable clustering without any HMAC key configured.
The JoinRequest structure in internal/cluster/protocol/messages.go accepts attacker-controlled node_id, role, raft_addr, api_addr, and coord_addr fields plus optional auth_nonce, auth_timestamp, and auth_hmac. The coordinator join path in internal/cluster/coordinator.go validates HMAC only when the configured secret is non-empty. With an empty secret, the code proceeds after nothing more than a cluster-name match. Heartbeat messages lack HMAC fields entirely, and the coordinator updates node state from supplied node_id and state values without authentication.
Root Cause
The root cause is a conditional authentication check. HMAC verification is gated on SharedSecret != "" rather than being mandatory whenever clustering is on. Combined with a default empty shared_secret and a startup guard that only fired under replication_enabled, the deployment silently ran an unauthenticated cluster protocol.
Attack Vector
An attacker with network reach to the coordinator port (:9100 by default) and knowledge of the cluster name sends a crafted JoinRequest with chosen node_id and api_addr values. Once accepted, the node is marked healthy, added as a Raft voter or registered locally, and exposed to the routing logic in internal/cluster/router.go. The forwardRequest path builds its target from node.APIAddress and copies Authorization and x-api-key headers, so a rogue node selected for a forwarded query receives credentials, request bodies, and database and measurement names. The attacker can also forge or delay operations and blackhole traffic.
// Security patch in cmd/arc/main.go — fail closed when clustering is
// enabled without a shared secret (GHSA-p378-jp5r-gpgw).
if cfg.Cluster.SharedSecret == "" {
log.Error().Msg("cluster.enabled requires ARC_CLUSTER_SHARED_SECRET to be set (cluster join and heartbeat messages must be authenticated)")
log.Error().Msg("Set ARC_CLUSTER_SHARED_SECRET to a value shared by all cluster nodes (generate with: openssl rand -hex 32), or disable cluster.enabled to continue")
os.Exit(1)
}
Source: GitHub Commit 38402ad
Detection Methods for CVE-2026-55678
Indicators of Compromise
- Unexpected node identifiers appearing in Arc cluster membership or Raft voter lists that do not correspond to inventoried hosts.
- Inbound TCP connections to the coordinator port (:9100) from addresses outside the documented cluster subnet.
- Forwarded request logs showing target APIAddress values pointing to unrecognized hosts.
- Heartbeat or join messages processed with empty auth_hmac, auth_nonce, or auth_timestamp fields.
Detection Strategies
- Audit the running configuration for cluster.enabled=true combined with an empty cluster.shared_secret; any match is a vulnerable deployment.
- Alert on membership changes emitted by internal/cluster/registry.go that were not initiated by an operator or automation workflow.
- Correlate query and write forwarding events against the known good node roster to spot diversions to attacker infrastructure.
Monitoring Recommendations
- Ingest Arc coordinator logs into a centralized analytics platform and flag join, leave, and heartbeat events lacking HMAC validation.
- Monitor network flows to coordinator port :9100 and restrict them at the firewall to known cluster members.
- Track Raft leader elections and voter set changes; treat unexpected voter additions as high-severity events.
How to Mitigate CVE-2026-55678
Immediate Actions Required
- Upgrade Arc Enterprise to version 26.06.2 or later, which fails closed when cluster.enabled is set without a shared secret.
- Configure ARC_CLUSTER_SHARED_SECRET on every cluster node using a strong random value, for example openssl rand -hex 32.
- Restrict access to coordinator port :9100 to trusted cluster members using host and network firewalls.
- Review cluster membership and Raft voter lists and remove any nodes that were not provisioned by operators.
Patch Information
Basekick Labs released the fix in Arc v26.06.2. The change is tracked in Pull Request #505 and commit 38402ad. Details are documented in GitHub Security Advisory GHSA-p378-jp5r-gpgw. The patch makes shared-secret authentication mandatory whenever clustering is enabled and authenticates heartbeat and leave messages.
Workarounds
- If patching is not immediately possible, disable clustering by setting cluster.enabled=false and run Arc in standalone mode.
- Isolate coordinator port :9100 behind a private network segment or VPN and block all external reachability.
- Enable cluster.tls_enabled and mutual TLS between nodes to add transport-layer authentication.
- Rotate any API keys and bearer tokens that may have been forwarded through the cluster while it was unauthenticated.
# Configuration example — enforce shared-secret auth on all Arc cluster nodes
export ARC_CLUSTER_SHARED_SECRET="$(openssl rand -hex 32)"
# arc.yaml
# cluster:
# enabled: true
# cluster_name: arc-cluster
# coordinator_addr: ":9100"
# shared_secret: "${ARC_CLUSTER_SHARED_SECRET}"
# tls_enabled: true
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

