Skip to content
Fencer Vulns
medium 6.9

CVE-2026-55678 json

Arc: Unauthenticated cluster node admission when `cluster.shared_secret` is unset

published 2026-08-28 2 mo ago modified 2026-09-09 1 mo ago also GHSA-p378-jp5r-gpgw , GO-2026-6322 , EUVD-2026-67945

cvss
6.9
version 4.0, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.7%
EPSS 0.7% chance of exploitation in 30 days, percentile 52%
public exploits
0
none known

Summary

Arc is an open, SQL-native time-series database for telemetry. From 26.02.1 until 26.06.2, Arc Enterprise clustering accepts cluster join requests without authentication when cluster.enabled is true but cluster.shared_secret is not configured. The defaults in internal/config/config.go set cluster.enabled to false, cluster.cluster_name to arc-cluster, cluster.coordinator_addr to :9100, cluster.shared_secret to an empty value, and cluster.tls_enabled to false, while cmd/arc/main.go requires cluster.shared_secret only when cluster.replication_enabled is true. JoinRequest in internal/cluster/protocol/messages.go accepts attacker-controlled node_id, role, raft_addr, api_addr, and coord_addr values, plus optional auth_nonce, auth_timestamp, and auth_hmac fields. The join path in internal/cluster/coordinator.go validates HMAC authentication only when the configured shared secret is non-empty and otherwise proceeds after only the cluster-name check. An accepted node is marked healthy, added as a Raft voter or registered locally, and becomes available through internal/cluster/registry.go to the routing logic in internal/cluster/router.go. The forwardRequest path in internal/cluster/router.go builds its target from node.APIAddress and copies Authorization and x-api-key headers with the request, so a rogue node selected for a forwarded query or write can receive authentication headers, request bodies, database and measurement names, and operational metadata. Heartbeat in internal/cluster/protocol/messages.go also lacks HMAC fields, and internal/cluster/coordinator.go updates node state from supplied node_id and state values without authentication. An unauthenticated network attacker who can reach the coordinator port and knows the cluster name can therefore become a trusted cluster node, mutate cluster membership, be submitted as a Raft voter, intercept topology-dependent forwarded requests, divert or forge operations, and blackhole or delay traffic. The default standalone configuration is not reachable because cluster.enabled is false, but Enterprise cluster deployments with clustering enabled and no shared secret are affected. This issue is fixed in version 26.06.2.

Patch / fix

  • go github.com/basekick-labs/arc 0.0.0-20260615160325-38402ad2ebdd
  • govulncheck-vulndb SLES 16.0, SLES for SAP applications 16.0 0.0.20260902T191204-160000.1.1

suse advisories SUSE-SU-2026:23692-1SUSE-SU-2026:23712-1

  • govulncheck-vulndb openSUSE Leap 16.0 0.0.20260902T191204-160000.1.1

opensuse advisories openSUSE-SU-2026:21812-1

CISA SSVC

Exploitation
Proof of concept is public
Automatable
yes
Technical impact
partial
Assessed
2 mo ago

Exploit prediction

0.66% chance of exploitation in the next 30 days, higher than 52% of all scored CVEs (FIRST EPSS, 2026-11-08).

Exploits and checks

  • github.com https://github.com/Basekick-Labs/arc/security/advisories/GHSA-p378-jp5r-gpgw referenced PoC, tagged "exploit" by a source, unverified

CVSS scores

assigned by version score vector
CNA 4.0 6.9 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
CNA 4.0 6.9 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Affected packages

ecosystem package affected fixed in
go github.com/basekick-labs/arc
<0.0.0-20260615160325-38402ad2ebdd
0.0.0-20260615160325-38402ad2ebdd

Affected products

  • Basekick-Labs arc

Classification

Weakness
  • CWE-284 Improper Access Control
  • CWE-287 Improper Authentication
  • CWE-306 Missing Authentication for Critical Functionality

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.