Vulnerabilities in pkg:golang/github.com/basekick-labs/arc

PACKAGE
Advisory Identifier: GHSA-p378-jp5r-gpgw
Advisory Summary

CVE-2026-55678 is a MODERATE arc has unauthenticated cluster node vulnerability (CWE-284: Improper Access Control) affecting Github.com/basekick labs/arc libraries in the Go ecosystem. The issue involves arc has unauthenticated cluster node admission when `cluster.shared_secret` is unset. Remediation is available by upgrading affected packages to version 0.0.0-20260615160325-38402ad2ebdd.

3 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:golang/github.com/basekick-labs/arc

3 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:golang/github.com/basekick-labs/arc. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-p378-jp5r-gpgw CVE-2026-55678 MODERATE arc has unauthenticated cluster node admission when `cluster.shared_secret` is unset
GHSA-j93g-rp6m-j32m CVE-2026-48050 HIGH Arc: Unauthenticated access to Go debug pprof endpoints leaks runtime state and enables CPU-burn DoS
GHSA-p2j4-c4g6-rpf5 CVE-2026-47735 HIGH Arc has an authenticated arbitrary local-file read via DuckDB I/O functions that bypasses RBAC table-level checks

CVE-2026-55678 at a Glance

CVE Identifier CVE-2026-55678
GHSA Identifier GHSA-p378-jp5r-gpgw
Severity MODERATE
CVSS v3.1 Base Score N/A
CWE Classification CWE-284: Improper Access Control
Affected Product Github.com/basekick labs/arc
Package Ecosystem Go
Published Date
Last Updated

How to Fix CVE-2026-55678

To remediate this vulnerability, upgrade all affected Github.com/basekick labs/arc dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/basekick-labs/arc fixed: 0.0.0-20260615160325-38402ad2ebdd
Upgrade github.com/basekick-labs/arc to 0.0.0-20260615160325-38402ad2ebdd
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/basekick-labs/arc

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-55678, inspect your project dependencies for Github.com/basekick labs/arc:

inspect dependencies for github.com/basekick-labs/arc

Analyze the terminal output to locate any version of Github.com/basekick labs/arc in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.0.0-20260615160325-38402ad2ebdd), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-284: Improper Access Control, where the product does not restrict or incorrectly restricts access to a resource from an unauthorized actor. In Github.com/basekick labs/arc, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary Arc 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 cluster router for forwarded authenticated requests. ## Details Cluster defaults include an empty shared secret and TLS disabled: - `internal/config/config.go:943-950` defaults `cluster.enabled=false`, `cluster.cluster_name="arc-cluster"`, and `cluster.coordinator_addr=":9100"`. - `internal/config/config.go:1001-1005` defaults `cluster.shared_secret=""` and `cluster.tls_enabled=false`. Startup requires a shared secret only for file replication, not for all clustering/join/routing use: - `cmd/arc/main.go:1258-1265` hard-fails without `cluster.shared_secret` only when `cluster.replication_enabled` is true. The join request contains attacker-supplied node identity, role, and addresses: - `internal/cluster/protocol/messages.go:127-142` defines `JoinRequest` fields including `node_id`, `role`, `raft_addr`, `api_addr`, `coord_addr`, plus optional auth fields. The coordinator validates HMAC only when the configured shared secret is non-empty: - `internal/cluster/coordinator.go:1066-1081` wraps all HMAC checks in `if c.cfg.SharedSecret != "" { ... }`. - If the secret is empty, the join request proceeds after only the cluster-name check. An accepted join creates a healthy node from attacker-controlled fields and adds it to cluster trust state: - `internal/cluster/coordinator.go:1101-1107` creates a node from request fields, sets attacker-provided coordinator/API addresses, and marks it healthy. - `internal/cluster/coordinator.go:1108-1129` adds the attacker-provided `raft_addr` as a Raft voter and stores node info when Raft is configured. - `internal/cluster/coordinator.go:1133-1138` registers the node locally when Raft is not configured. The router uses healthy nodes from this registry and forwards authenticated requests to their advertised API addresses: - `internal/cluster/registry.go:263-270` returns healthy writers/readers. - `internal/cluster/router.go:154-177` routes writes to healthy writer nodes. - `internal/cluster/router.go:203-227` routes queries to healthy readers, or writers if no readers exist. - `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`. - `cmd/arc/main.go:1887-1897` wires the cluster router into MessagePack, line protocol, TLE, and query handlers when the cluster coordinator exists. A related lower-severity issue is that heartbeat messages are also unauthenticated: - `internal/cluster/protocol/messages.go:175-180` defines `Heartbeat` without HMAC fields. - `internal/cluster/coordinator.go:1220-1232` records heartbeats and updates node state based only on supplied `node_id` and `state`. ## Proof of concept Safe local lab reproduction only; do not target external infrastructure. Prerequisites: - Enterprise clustering enabled in a lab deployment. - `cluster.shared_secret` intentionally left empty. - Network access to the coordinator TCP port, default `9100`. - The attacker knows or guesses the cluster name; default is `arc-cluster`. Steps: 1. Start an Arc cluster node with: ```toml [cluster] enabled = true cluster_name = "arc-cluster" coordinator_addr = ":9100" shared_secret = "" tls_enabled = false ``` 2. Start an attacker-controlled HTTP listener that records request method, path, and headers, for example on `127.0.0.1:18080`. 3. 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`: ```json { "node_id": "evil-reader-1", "node_name": "evil-reader", "role": "reader", "cluster_name": "arc-cluster", "raft_addr": "127.0.0.1:19020", "api_addr": "127.0.0.1:18080", "coord_addr": "127.0.0.1:19010", "version": "lab", "core_count": 1 } ``` Expected vulnerable result: the coordinator accepts the join instead of rejecting it for missing authentication. 4. Trigger a forwarded operation from a node that cannot handle the operation locally. Examples depend on cluster roles: - Join as `reader` and trigger a query through a node that routes queries to readers. - Join as `writer` and trigger ingestion through a non-writer node that routes writes to writers. Expected 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. 5. In a Raft-enabled lab, observe that the attacker-provided `raft_addr` is submitted to `AddVoter`, demonstrating unauthorized membership mutation. ## Impact In affected cluster deployments, an unauthenticated network attacker can become a trusted cluster node. Practical impacts include: - Interception of forwarded authenticated HTTP requests, including `Authorization` and `x-api-key` headers. - Exposure of query bodies, ingestion data, database/measurement names, and operational metadata. - Unauthorized cluster membership mutation, including attempted Raft voter addition when Raft is configured. - Potential data integrity impact if the rogue node returns forged query/write responses or accepts/diverts writes. - Potential availability impact by blackholing or delaying forwarded operations. This 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. ## Suggested fix - Fail startup when `cluster.enabled=true` and `cluster.shared_secret` is empty, not only when `cluster.replication_enabled=true`. - Reject all trust-mutating coordinator messages when no cluster authentication is configured, including join, heartbeat/state update, forward apply, and file replication messages. - Require HMAC or mutual TLS before processing any join/heartbeat message. - Bind authentication to node identity and advertised addresses to reduce replay and address-substitution risks. - Do not forward end-user `Authorization`/`x-api-key` headers to a peer unless the peer identity has been authenticated and authorized. - Add tests proving unauthenticated join and heartbeat requests fail when clustering is enabled. ## References / evidence - `internal/config/config.go:943-950` - `internal/config/config.go:1001-1005` - `cmd/arc/main.go:1258-1265` - `internal/cluster/protocol/messages.go:127-142` - `internal/cluster/coordinator.go:1066-1081` - `internal/cluster/coordinator.go:1101-1138` - `internal/cluster/router.go:154-177` - `internal/cluster/router.go:203-227` - `internal/cluster/router.go:327-357` - `cmd/arc/main.go:1887-1897`

CVE-2026-55678 Affected Github.com/basekick labs/arc Versions

1 component(s)
Fixed Versions:
0.0.0-20260615160325-38402ad2ebdd
Product / Package Ecosystem Affected Versions Fixed Version
github.com/basekick-labs/arc
Go
< 0.0.0-20260615160325-38402ad2ebdd
0.0.0-20260615160325-38402ad2ebdd

References

Frequently Asked Questions

What is CVE-2026-55678?
CVE-2026-55678 is a security vulnerability in Github.com/basekick labs/arc involving arc has unauthenticated cluster node admission when `cluster.shared_secret` is unset under CWE-284: Improper Access Control.
Which Github.com/basekick labs/arc versions are affected?
Affected versions include releases prior to 0.0.0-20260615160325-38402ad2ebdd across affected packages: github.com/basekick-labs/arc.
What version fixes CVE-2026-55678?
Upgrading to 0.0.0-20260615160325-38402ad2ebdd (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/basekick-labs/arc affected?
Yes, github.com/basekick-labs/arc is affected in releases prior to 0.0.0-20260615160325-38402ad2ebdd. Upgrade your dependency to 0.0.0-20260615160325-38402ad2ebdd or later.
What CWE is associated with CVE-2026-55678?
CVE-2026-55678 is classified under CWE-284: Improper Access Control (The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.).
How can I check Go dependencies for CVE-2026-55678?
Run the dependency tree command: 'inspect dependencies for github.com/basekick-labs/arc'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-p378-jp5r-gpgw",
  "modified" : "2026-08-28T20:32:57Z",
  "published" : "2026-08-28T20:32:57Z",
  "aliases" : [ "CVE-2026-55678" ],
  "summary" : "arc has unauthenticated cluster node admission when `cluster.shared_secret` is unset",
  "details" : "## 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`",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "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"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/basekick-labs/arc"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.0.0-20260615160325-38402ad2ebdd"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/Basekick-Labs/arc/security/advisories/GHSA-p378-jp5r-gpgw"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Basekick-Labs/arc/pull/505"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Basekick-Labs/arc/commit/38402ad2ebddd32c15bf4a0fc9c22c920e5685df"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/Basekick-Labs/arc"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Basekick-Labs/arc/releases/tag/v26.06.2"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-284", "CWE-287", "CWE-306" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-08-28T20:32:57Z",
    "nvd_published_at" : null
  }
}