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.
CVE-2026-55678
This medium-severity CVE scores 6.9 under a secondary CVSS source (NVD's own analysis pending). EPSS exploit-prediction score not yet available (the EPSS model rescores nightly; freshly-published CVEs typically appear within 48 hours). GitHub Security Advisory data not yet ingested — confidence will rise once GHSA publishes (typical lag: hours to days for open-source ecosystem CVEs; never for infrastructure-only CVEs).
- Lower severity and no public exploit yet
No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.
- CVSS v3
- 6.9
- EG Score
- 6.9(low)
- EG Risk
- 36(Track)EG Risk 36/100SSVC: Track
EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).
How it’s computedSeverity69% × 45%Exploitation0% × 40%Automatability30% × 15%Action: Routine — remediate on your standard cadence. - EPSS PROB
- 0%
- EPSS %ILE
- 32%
- KEV
- Not listed
Published
August 28, 2026
Last Modified
August 28, 2026
Advisory Details (4)
Auto-updated Aug 28, 2026Unauthenticated cluster node admission when `cluster.shared_secret` is unset · Advisory · Basekick-Labs/arc · GitHub
https://github.com/Basekick-Labs/arc/security/advisories/GHSA-p378-jp5r-gpgwArc 26.06.2
Patch available: Basekick-Labs/arc v26.06.2
https://github.com/Basekick-Labs/arc/releases/tag/v26.06.2fix(cluster): require shared secret for clustering, authenticate heartbeats (GHSA-p378-jp5r-gpgw)
Fix merged in Basekick-Labs/arc PR #505 on 2026-06-15 — awaiting tagged release
https://github.com/Basekick-Labs/arc/pull/505commit 38402ad2ebdd (Basekick-Labs/arc)
Fix landed in Basekick-Labs/arc commit 38402ad2ebdd — awaiting tagged release
https://github.com/Basekick-Labs/arc/commit/38402ad2ebddd32c15bf4a0fc9c22c920e5685dfVendor Advisories for CVE-2026-55678(1)
These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.
Weakness Classification(3)
MITRE Common Weakness Enumeration — the root-cause categories this CVE belongs to.
Data Freshness Timeline
(refreshed 4× in last 7d / 4× in last 30d)
Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.
- 2026-08-30 01:22 UTCEPSS rescore
- 2026-08-28 22:35 UTCEG score recompute▲ 6.90
- 2026-08-28 22:34 UTCNVD updateCVSS v3 → 6.9 · CVSS v4 → 6.9
- 2026-08-28 21:11 UTCEG score recompute
Related CVEs(same CWE)
Same CWE
10 shownCWE-287 · CWE-306
Frequently asked(5)
What is CVE-2026-55678?
When was CVE-2026-55678 disclosed?
Is CVE-2026-55678 actively exploited?
What is the CVSS score of CVE-2026-55678?
How do I remediate CVE-2026-55678?
Dependency Blast Radius
Explore the affected products and dependency analysis for CVE-2026-55678
Is Your Infrastructure Affected by CVE-2026-55678?
EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.