{"id":"CVE-2026-55678","aliases":["EUVD-2026-67945","GHSA-p378-jp5r-gpgw","GO-2026-6322","SUSE-SU-2026:23692-1","SUSE-SU-2026:23712-1","openSUSE-SU-2026:21812-1"],"status":"published","title":"Arc: Unauthenticated cluster node admission when `cluster.shared_secret` is unset","description":"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.","severity":{"version":"4.0","score":6.9,"vector":"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","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00665,"percentile":0.5222,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-284","CWE-287","CWE-306"],"published":"2026-08-28T20:32:23Z","modified":"2026-10-28T02:31:03Z","fixes":[{"ecosystem":"Go","package":"github.com/basekick-labs/arc","fixed_in":["0.0.0-20260615160325-38402ad2ebdd"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/basekick-labs/arc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.0-20260615160325-38402ad2ebdd"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/basekick-labs/arc","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.0.0-20260615160325-38402ad2ebdd"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/basekick-labs/arc","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.0.0-20260615160325-38402ad2ebdd"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20260902T191204-160000.1.1"}]}],"bundled":39}],"products":[{"vendor":"basekick-labs","product":"arc"},{"vendor":"nozomi networks","product":"arc"}],"references":[{"url":"https://github.com/Basekick-Labs/arc/security/advisories/GHSA-p378-jp5r-gpgw","tags":["x_refsource_CONFIRM","exploit","advisory","web"]},{"url":"https://github.com/Basekick-Labs/arc/pull/505","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/Basekick-Labs/arc/commit/38402ad2ebddd32c15bf4a0fc9c22c920e5685df","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/Basekick-Labs/arc/releases/tag/v26.06.2","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/advisories/GHSA-p378-jp5r-gpgw"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/55xxx/CVE-2026-55678.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-55678","tags":["advisory"]},{"url":"https://github.com/Basekick-Labs/arc","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623692-1/","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-20909","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-22547","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-24690","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25712","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25718","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26232","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26247","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-26307","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-27657","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-27878","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-28705","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54746","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54754","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54755","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-54766","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55064","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55065","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55066","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55067","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55068","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55108","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55245","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55484","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55569","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55588","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55621","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55622","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55678","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55761","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55763","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55764","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55784","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55785","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55834","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55873","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-55874","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56854","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-56855","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-78662","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202623712-1/","tags":["advisory"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2026-55678","title":"Arc: Unauthenticated cluster node admission when `cluster.shared_secret` is unset","description":"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.","status":"published","published":"2026-08-28T20:32:23.103Z","modified":"2026-09-01T01:57:42.991Z","cvss":[{"version":"4.0","score":6.9,"vector":"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","level":"medium","assessor":"cna"}],"cwes":["CWE-284","CWE-287","CWE-306"],"updated_at":"2026-11-02T14:20:11.925815Z"}],"euvd":[{"id":"EUVD-2026-67945","description":"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.","status":"published","published":"2026-08-28T20:32:23Z","modified":"2026-09-01T01:57:42Z","cvss":[{"version":"4.0","score":6.9,"vector":"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","level":"medium"}],"updated_at":"2026-11-02T18:01:19.285273Z"}],"ghsa":[{"id":"GHSA-p378-jp5r-gpgw","title":"arc has unauthenticated cluster node admission when `cluster.shared_secret` is unset","description":"## Summary\n\nArc Enterprise clustering accepts cluster join requests without authentication when `cluster.enabled=true` but `cluster.shared_secret` is not configured. The coordinator validates HMAC authentication only if a shared secret is non-empty; otherwise, a network attacker who can reach the coordinator port can send a join request with attacker-controlled node addresses and role. Accepted nodes are marked healthy, registered locally or added as Raft voters, and can be selected by the \ncluster router for forwarded authenticated requests.\n\n## Details\n\nCluster defaults include an empty shared secret and TLS disabled:\n\n- `internal/config/config.go:943-950` defaults `cluster.enabled=false`, `cluster.cluster_name=\"arc-cluster\"`, and `cluster.coordinator_addr=\":9100\"`.\n- `internal/config/config.go:1001-1005` defaults `cluster.shared_secret=\"\"` and `cluster.tls_enabled=false`.\n\nStartup requires a shared secret only for file replication, not for all clustering/join/routing use:\n\n- `cmd/arc/main.go:1258-1265` hard-fails without `cluster.shared_secret` only when `cluster.replication_enabled` is true.\n\nThe join request contains attacker-supplied node identity, role, and addresses:\n\n- `internal/cluster/protocol/messages.go:127-142` defines `JoinRequest` fields including `node_id`, `role`, `raft_addr`, `api_addr`, `coord_addr`, plus optional auth fields.\n\nThe coordinator validates HMAC only when the configured shared secret is non-empty:\n\n- `internal/cluster/coordinator.go:1066-1081` wraps all HMAC checks in `if c.cfg.SharedSecret != \"\" { ... }`.\n- If the secret is empty, the join request proceeds after only the cluster-name check.\n\nAn accepted join creates a healthy node from attacker-controlled fields and adds it to cluster trust state:\n\n- `internal/cluster/coordinator.go:1101-1107` creates a node from request fields, sets attacker-provided coordinator/API addresses, and marks it healthy.\n- `internal/cluster/coordinator.go:1108-1129` adds the attacker-provided `raft_addr` as a Raft voter and stores node info when Raft is configured.\n- `internal/cluster/coordinator.go:1133-1138` registers the node locally when Raft is not configured.\n\nThe router uses healthy nodes from this registry and forwards authenticated requests to their advertised API addresses:\n\n- `internal/cluster/registry.go:263-270` returns healthy writers/readers.\n- `internal/cluster/router.go:154-177` routes writes to healthy writer nodes.\n- `internal/cluster/router.go:203-227` routes queries to healthy readers, or writers if no readers exist.\n- `internal/cluster/router.go:327-357` builds the forwarding target from `node.APIAddress` and copies all original request headers to the peer, including `Authorization` and `x-api-key`.\n- `cmd/arc/main.go:1887-1897` wires the cluster router into MessagePack, line protocol, TLE, and query handlers when the cluster coordinator exists.\n\nA related lower-severity issue is that heartbeat messages are also unauthenticated:\n\n- `internal/cluster/protocol/messages.go:175-180` defines `Heartbeat` without HMAC fields.\n- `internal/cluster/coordinator.go:1220-1232` records heartbeats and updates node state based only on supplied `node_id` and `state`.\n\n## Proof of concept\n\nSafe local lab reproduction only; do not target external infrastructure.\n\nPrerequisites:\n\n- Enterprise clustering enabled in a lab deployment.\n- `cluster.shared_secret` intentionally left empty.\n- Network access to the coordinator TCP port, default `9100`.\n- The attacker knows or guesses the cluster name; default is `arc-cluster`.\n\nSteps:\n\n1. Start an Arc cluster node with:\n\n```toml\n[cluster]\nenabled = true\ncluster_name = \"arc-cluster\"\ncoordinator_addr = \":9100\"\nshared_secret = \"\"\ntls_enabled = false\n```\n\n2. Start an attacker-controlled HTTP listener that records request method, path, and headers, for example on `127.0.0.1:18080`.\n\n3. Send a framed cluster join request to the victim coordinator. The protocol uses a 4-byte big-endian length prefix, followed by a 1-byte message type (`MsgJoinRequest == 1`), followed by JSON. The payload should include attacker-controlled node fields and omit `auth_nonce`, `auth_timestamp`, and `auth_hmac`:\n\n```json\n{\n  \"node_id\": \"evil-reader-1\",\n  \"node_name\": \"evil-reader\",\n  \"role\": \"reader\",\n  \"cluster_name\": \"arc-cluster\",\n  \"raft_addr\": \"127.0.0.1:19020\",\n  \"api_addr\": \"127.0.0.1:18080\",\n  \"coord_addr\": \"127.0.0.1:19010\",\n  \"version\": \"lab\",\n  \"core_count\": 1\n}\n```\n\nExpected vulnerable result: the coordinator accepts the join instead of rejecting it for missing authentication.\n\n4. Trigger a forwarded operation from a node that cannot handle the operation locally. Examples depend on cluster roles:\n\n- Join as `reader` and trigger a query through a node that routes queries to readers.\n- Join as `writer` and trigger ingestion through a non-writer node that routes writes to writers.\n\nExpected vulnerable result: the attacker-controlled HTTP listener receives forwarded requests. Because `forwardRequest` copies all original headers, the listener can observe authentication headers such as bearer tokens or API keys along with request paths and bodies.\n\n5. In a Raft-enabled lab, observe that the attacker-provided `raft_addr` is submitted to `AddVoter`, demonstrating unauthorized membership mutation.\n\n## Impact\n\nIn affected cluster deployments, an unauthenticated network attacker can become a trusted cluster node. Practical impacts include:\n\n- Interception of forwarded authenticated HTTP requests, including `Authorization` and `x-api-key` headers.\n- Exposure of query bodies, ingestion data, database/measurement names, and operational metadata.\n- Unauthorized cluster membership mutation, including attempted Raft voter addition when Raft is configured.\n- Potential data integrity impact if the rogue node returns forged query/write responses or accepts/diverts writes.\n- Potential availability impact by blackholing or delaying forwarded operations.\n\nThis is not reachable in the default standalone configuration because `cluster.enabled=false`, but it is a critical trust-boundary issue for Enterprise cluster deployments where clustering is enabled without a shared secret. The code already treats `cluster.shared_secret` as mandatory for replication, which suggests unauthenticated cluster membership should also fail closed.\n\n\n## Suggested fix\n\n- Fail startup when `cluster.enabled=true` and `cluster.shared_secret` is empty, not only when `cluster.replication_enabled=true`.\n- Reject all trust-mutating coordinator messages when no cluster authentication is configured, including join, heartbeat/state update, forward apply, and file replication messages.\n- Require HMAC or mutual TLS before processing any join/heartbeat message.\n- Bind authentication to node identity and advertised addresses to reduce replay and address-substitution risks.\n- Do not forward end-user `Authorization`/`x-api-key` headers to a peer unless the peer identity has been authenticated and authorized.\n- Add tests proving unauthenticated join and heartbeat requests fail when clustering is enabled.\n\n## References / evidence\n\n- `internal/config/config.go:943-950`\n- `internal/config/config.go:1001-1005`\n- `cmd/arc/main.go:1258-1265`\n- `internal/cluster/protocol/messages.go:127-142`\n- `internal/cluster/coordinator.go:1066-1081`\n- `internal/cluster/coordinator.go:1101-1138`\n- `internal/cluster/router.go:154-177`\n- `internal/cluster/router.go:203-227`\n- `internal/cluster/router.go:327-357`\n- `cmd/arc/main.go:1887-1897`","status":"published","published":"2026-08-28T20:32:57Z","modified":"2026-08-28T20:33:00Z","cvss":[{"version":"4.0","score":6.9,"vector":"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","level":"medium"}],"cwes":["CWE-284","CWE-287","CWE-306"],"updated_at":"2026-11-02T14:41:08.084849Z"}],"nvd":[{"id":"CVE-2026-55678","description":"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.","status":"published","published":"2026-08-28T22:16:51.4Z","modified":"2026-09-09T21:09:13.08Z","cvss":[{"version":"4.0","score":6.9,"vector":"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","level":"medium","assessor":"secondary"}],"cwes":["CWE-284","CWE-287","CWE-306"],"updated_at":"2026-11-02T14:12:42.366888Z"}],"osv":[{"id":"CVE-2026-55678","title":"Arc: Unauthenticated cluster node admission when `cluster.shared_secret` is unset","description":"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.","status":"published","published":"2026-08-28T20:32:23.103Z","modified":"2026-10-28T02:31:03.101189907Z","cvss":[{"version":"4.0","score":6.9,"vector":"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","level":"medium"}],"cwes":["CWE-284","CWE-287","CWE-306"],"updated_at":"2026-11-02T15:45:11.22012Z"},{"id":"GHSA-p378-jp5r-gpgw","title":"arc has unauthenticated cluster node admission when `cluster.shared_secret` is unset","description":"## Summary\n\nArc Enterprise clustering accepts cluster join requests without authentication when `cluster.enabled=true` but `cluster.shared_secret` is not configured. The coordinator validates HMAC authentication only if a shared secret is non-empty; otherwise, a network attacker who can reach the coordinator port can send a join request with attacker-controlled node addresses and role. Accepted nodes are marked healthy, registered locally or added as Raft voters, and can be selected by the \ncluster router for forwarded authenticated requests.\n\n## Details\n\nCluster defaults include an empty shared secret and TLS disabled:\n\n- `internal/config/config.go:943-950` defaults `cluster.enabled=false`, `cluster.cluster_name=\"arc-cluster\"`, and `cluster.coordinator_addr=\":9100\"`.\n- `internal/config/config.go:1001-1005` defaults `cluster.shared_secret=\"\"` and `cluster.tls_enabled=false`.\n\nStartup requires a shared secret only for file replication, not for all clustering/join/routing use:\n\n- `cmd/arc/main.go:1258-1265` hard-fails without `cluster.shared_secret` only when `cluster.replication_enabled` is true.\n\nThe join request contains attacker-supplied node identity, role, and addresses:\n\n- `internal/cluster/protocol/messages.go:127-142` defines `JoinRequest` fields including `node_id`, `role`, `raft_addr`, `api_addr`, `coord_addr`, plus optional auth fields.\n\nThe coordinator validates HMAC only when the configured shared secret is non-empty:\n\n- `internal/cluster/coordinator.go:1066-1081` wraps all HMAC checks in `if c.cfg.SharedSecret != \"\" { ... }`.\n- If the secret is empty, the join request proceeds after only the cluster-name check.\n\nAn accepted join creates a healthy node from attacker-controlled fields and adds it to cluster trust state:\n\n- `internal/cluster/coordinator.go:1101-1107` creates a node from request fields, sets attacker-provided coordinator/API addresses, and marks it healthy.\n- `internal/cluster/coordinator.go:1108-1129` adds the attacker-provided `raft_addr` as a Raft voter and stores node info when Raft is configured.\n- `internal/cluster/coordinator.go:1133-1138` registers the node locally when Raft is not configured.\n\nThe router uses healthy nodes from this registry and forwards authenticated requests to their advertised API addresses:\n\n- `internal/cluster/registry.go:263-270` returns healthy writers/readers.\n- `internal/cluster/router.go:154-177` routes writes to healthy writer nodes.\n- `internal/cluster/router.go:203-227` routes queries to healthy readers, or writers if no readers exist.\n- `internal/cluster/router.go:327-357` builds the forwarding target from `node.APIAddress` and copies all original request headers to the peer, including `Authorization` and `x-api-key`.\n- `cmd/arc/main.go:1887-1897` wires the cluster router into MessagePack, line protocol, TLE, and query handlers when the cluster coordinator exists.\n\nA related lower-severity issue is that heartbeat messages are also unauthenticated:\n\n- `internal/cluster/protocol/messages.go:175-180` defines `Heartbeat` without HMAC fields.\n- `internal/cluster/coordinator.go:1220-1232` records heartbeats and updates node state based only on supplied `node_id` and `state`.\n\n## Proof of concept\n\nSafe local lab reproduction only; do not target external infrastructure.\n\nPrerequisites:\n\n- Enterprise clustering enabled in a lab deployment.\n- `cluster.shared_secret` intentionally left empty.\n- Network access to the coordinator TCP port, default `9100`.\n- The attacker knows or guesses the cluster name; default is `arc-cluster`.\n\nSteps:\n\n1. Start an Arc cluster node with:\n\n```toml\n[cluster]\nenabled = true\ncluster_name = \"arc-cluster\"\ncoordinator_addr = \":9100\"\nshared_secret = \"\"\ntls_enabled = false\n```\n\n2. Start an attacker-controlled HTTP listener that records request method, path, and headers, for example on `127.0.0.1:18080`.\n\n3. Send a framed cluster join request to the victim coordinator. The protocol uses a 4-byte big-endian length prefix, followed by a 1-byte message type (`MsgJoinRequest == 1`), followed by JSON. The payload should include attacker-controlled node fields and omit `auth_nonce`, `auth_timestamp`, and `auth_hmac`:\n\n```json\n{\n  \"node_id\": \"evil-reader-1\",\n  \"node_name\": \"evil-reader\",\n  \"role\": \"reader\",\n  \"cluster_name\": \"arc-cluster\",\n  \"raft_addr\": \"127.0.0.1:19020\",\n  \"api_addr\": \"127.0.0.1:18080\",\n  \"coord_addr\": \"127.0.0.1:19010\",\n  \"version\": \"lab\",\n  \"core_count\": 1\n}\n```\n\nExpected vulnerable result: the coordinator accepts the join instead of rejecting it for missing authentication.\n\n4. Trigger a forwarded operation from a node that cannot handle the operation locally. Examples depend on cluster roles:\n\n- Join as `reader` and trigger a query through a node that routes queries to readers.\n- Join as `writer` and trigger ingestion through a non-writer node that routes writes to writers.\n\nExpected vulnerable result: the attacker-controlled HTTP listener receives forwarded requests. Because `forwardRequest` copies all original headers, the listener can observe authentication headers such as bearer tokens or API keys along with request paths and bodies.\n\n5. In a Raft-enabled lab, observe that the attacker-provided `raft_addr` is submitted to `AddVoter`, demonstrating unauthorized membership mutation.\n\n## Impact\n\nIn affected cluster deployments, an unauthenticated network attacker can become a trusted cluster node. Practical impacts include:\n\n- Interception of forwarded authenticated HTTP requests, including `Authorization` and `x-api-key` headers.\n- Exposure of query bodies, ingestion data, database/measurement names, and operational metadata.\n- Unauthorized cluster membership mutation, including attempted Raft voter addition when Raft is configured.\n- Potential data integrity impact if the rogue node returns forged query/write responses or accepts/diverts writes.\n- Potential availability impact by blackholing or delaying forwarded operations.\n\nThis is not reachable in the default standalone configuration because `cluster.enabled=false`, but it is a critical trust-boundary issue for Enterprise cluster deployments where clustering is enabled without a shared secret. The code already treats `cluster.shared_secret` as mandatory for replication, which suggests unauthenticated cluster membership should also fail closed.\n\n\n## Suggested fix\n\n- Fail startup when `cluster.enabled=true` and `cluster.shared_secret` is empty, not only when `cluster.replication_enabled=true`.\n- Reject all trust-mutating coordinator messages when no cluster authentication is configured, including join, heartbeat/state update, forward apply, and file replication messages.\n- Require HMAC or mutual TLS before processing any join/heartbeat message.\n- Bind authentication to node identity and advertised addresses to reduce replay and address-substitution risks.\n- Do not forward end-user `Authorization`/`x-api-key` headers to a peer unless the peer identity has been authenticated and authorized.\n- Add tests proving unauthenticated join and heartbeat requests fail when clustering is enabled.\n\n## References / evidence\n\n- `internal/config/config.go:943-950`\n- `internal/config/config.go:1001-1005`\n- `cmd/arc/main.go:1258-1265`\n- `internal/cluster/protocol/messages.go:127-142`\n- `internal/cluster/coordinator.go:1066-1081`\n- `internal/cluster/coordinator.go:1101-1138`\n- `internal/cluster/router.go:154-177`\n- `internal/cluster/router.go:203-227`\n- `internal/cluster/router.go:327-357`\n- `cmd/arc/main.go:1887-1897`","status":"published","published":"2026-08-28T20:32:57Z","modified":"2026-09-02T19:55:38.727770329Z","cvss":[{"version":"4.0","score":6.9,"vector":"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","level":"medium"}],"cwes":["CWE-284","CWE-287","CWE-306"],"updated_at":"2026-11-02T15:46:52.534897Z"},{"id":"GO-2026-6322","title":"arc has unauthenticated cluster node admission when `cluster.shared_secret` is unset in github.com/basekick-labs/arc","description":"arc has unauthenticated cluster node admission when `cluster.shared_secret` is unset in github.com/basekick-labs/arc","status":"published","published":"2026-09-02T18:37:27Z","modified":"2026-09-02T19:45:13.186036441Z","updated_at":"2026-11-02T15:47:03.11707Z"},{"id":"openSUSE-SU-2026:21812-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:52:09Z","modified":"2026-09-10T18:23:18.964541257Z","updated_at":"2026-11-02T16:58:42.426393Z"},{"id":"SUSE-SU-2026:23692-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:28:52Z","modified":"2026-09-29T18:23:12.31116925Z","updated_at":"2026-11-02T15:54:03.991985Z"},{"id":"SUSE-SU-2026:23712-1","title":"Security update for govulncheck-vulndb","description":"This update for govulncheck-vulndb fixes the following issues:\n\n- Update to version 0.0.20260902T191204 2026-09-02T19:12:04Z (jsc#PED-11136).\n\n Go CVE Numbering Authority IDs added or updated with aliases:\n * GO-2026-6305 CVE-2026-55834 GHSA-2wvm-8mvp-22qv\n * GO-2026-6306 CVE-2026-55064 GHSA-44v6-7fxq-vgf4\n * GO-2026-6307 CVE-2026-55067 GHSA-569v-q83c-3j3g\n * GO-2026-6308 CVE-2026-55066 GHSA-5pg6-m483-7vrg\n * GO-2026-6309 CVE-2026-54746 GHSA-8x7x-83cf-c3pg\n * GO-2026-6310 CVE-2026-54755 GHSA-cgc5-v3f2-8m2v\n * GO-2026-6311 CVE-2026-54766 GHSA-f27p-pw2p-9pr4\n * GO-2026-6312 CVE-2026-55108 GHSA-fmgp-q6jx-gg3x\n * GO-2026-6313 CVE-2026-55065 GHSA-gg93-x632-9ccv\n * GO-2026-6314 CVE-2026-55569 GHSA-mf5c-hw34-4hpp\n * GO-2026-6315 CVE-2026-54754 GHSA-p7gw-2pcp-5pf8\n * GO-2026-6316 CVE-2026-55068 GHSA-x8mj-6p3q-g5pp\n * GO-2026-6317 CVE-2026-55588 GHSA-298f-872v-2rcx\n * GO-2026-6318 CVE-2026-55621 GHSA-64f3-v33m-w89f\n * GO-2026-6319 CVE-2026-55622 GHSA-c9f5-j9c3-mhrg\n * GO-2026-6320 CVE-2026-55245 GHSA-w98g-5w9p-p3rc\n * GO-2026-6321 CVE-2026-55484 GHSA-hr6j-w4mw-g9mj\n * GO-2026-6322 CVE-2026-55678 GHSA-p378-jp5r-gpgw\n * GO-2026-6323 CVE-2026-55763 GHSA-v358-wf77-39xv\n * GO-2026-6324 CVE-2026-55761 GHSA-x626-fcwx-f5pc\n * GO-2026-6325 CVE-2026-27878 GHSA-6xff-cpcq-vpw2\n * GO-2026-6326 CVE-2026-55784 GHSA-334q-h5g3-fpxv\n * GO-2026-6327 CVE-2026-55874 GHSA-56wq-x3wv-3ff4\n * GO-2026-6328 CVE-2026-55785 GHSA-fp46-6vfw-gc9c\n * GO-2026-6329 CVE-2026-55873 GHSA-hgpf-8634-g44c\n * GO-2026-6330 CVE-2026-55764 GHSA-mrpp-v6pg-p54x\n * GO-2026-6333 CVE-2026-25712 GHSA-37w2-86g3-h4qh\n * GO-2026-6334 CVE-2026-24690 GHSA-47rq-xp99-92mx\n * GO-2026-6335 CVE-2026-27657 GHSA-4c8f-3m6h-m56r\n * GO-2026-6336 CVE-2026-26232 GHSA-5v69-g2m3-3hq3\n * GO-2026-6337 CVE-2026-28705 GHSA-7jvx-g65v-r899\n * GO-2026-6338 CVE-2026-22547 GHSA-922f-hfwp-p56f\n * GO-2026-6339 CVE-2026-20909 GHSA-fhq3-p242-2qpf\n * GO-2026-6340 CVE-2026-25718 GHSA-h697-89cp-24q8\n * GO-2026-6341 CVE-2026-26307 GHSA-h9c5-x7g8-4q7f\n * GO-2026-6342 CVE-2026-26247 GHSA-m5ch-ppfx-xv3v\n * GO-2026-6354 CVE-2026-78662\n * GO-2026-6355 CVE-2026-56855\n\n- Update to version 0.0.20260828T144745 2026-08-28T14:47:45Z.\n\n * GO-2026-6303 CVE-2026-56854\n","status":"published","published":"2026-09-08T16:28:52Z","modified":"2026-09-29T18:23:12.805639295Z","updated_at":"2026-11-02T15:54:03.991985Z"}]}}