Basekick Arc up to 26.06.1 Cluster Join messages.go JoinRequest node_id/role/raft_addr/api_addr/coord_addr improper authentication

Summaryinfo

A vulnerability classified as critical has been found in Basekick Arc up to 26.06.1. This impacts the function JoinRequest of the file internal/cluster/protocol/messages.go of the component Cluster Join. This manipulation of the argument node_id/role/raft_addr/api_addr/coord_addr causes improper authentication. This vulnerability is registered as CVE-2026-55678. Remote exploitation of the attack is possible. No exploit is available.

Detailsinfo

A vulnerability classified as critical was found in Basekick Arc up to 26.06.1. Affected by this vulnerability is the function JoinRequest of the file internal/cluster/protocol/messages.go of the component Cluster Join. The manipulation of the argument node_id/role/raft_addr/api_addr/coord_addr with an unknown input leads to a improper authentication vulnerability. The CWE definition for the vulnerability is CWE-287. When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. As an impact it is known to affect confidentiality, integrity, and availability. The summary by CVE is:

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.

It is possible to read the advisory at github.com. This vulnerability is known as CVE-2026-55678 since 06/17/2026. The exploitation appears to be easy. The attack can be launched remotely. The exploitation doesn't need any form of authentication. Technical details of the vulnerability are known, but there is no available exploit.

Upgrading to version 26.06.2 eliminates this vulnerability.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Vendor

• Basekick

Name

• Arc

Version

• 26.06.0
• 26.06.1

CPE 2.3info

• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion