CVE-2026-63406: AnyCable Information Disclosure Vulnerability

CVE-2026-63406 Overview

AnyCable is a realtime server that supports two-way communication with any backend. Versions prior to 1.6.15 contain a flaw in the telemetry subsystem that generates a cluster fingerprint from configuration data containing secrets. The clusterFingerprint function in telemetry/telemetry.go reads the full configuration file and raw os.Args, including values supplied through --secret, --jwt_secret, and --http_rpc_secret. These inputs are passed to generateDigest, where sha256.New produces a hexadecimal fingerprint transmitted with a hardcoded public authToken defined in telemetry/config.go. The issue is categorized as [CWE-312] Cleartext Storage of Sensitive Information.

Critical Impact
Stable SHA-256 fingerprints derived from secret-bearing configuration are transmitted to a telemetry endpoint authenticated with publicly known credentials, exposing hashes suitable for offline correlation and brute-force attempts against known secret formats.

Affected Products

AnyCable realtime server versions prior to 1.6.15
Deployments using the default telemetry subsystem configuration
AnyCable instances started with --secret, --jwt_secret, or --http_rpc_secret CLI flags

Discovery Timeline

2026-09-18 - CVE-2026-63406 published to NVD
2026-09-24 - Last updated in NVD database

Technical Details for CVE-2026-63406

Vulnerability Analysis

The AnyCable telemetry subsystem is enabled by default and reports operational metadata to a central endpoint. The clusterFingerprint routine constructs a digest input from the process configuration file and the raw command-line arguments returned by anycableCLIArgs. When operators supply secrets through CLI flags, those secret values become part of the digest source material.

The fingerprint is generated by passing the concatenated input to sha256.New and encoding the digest as hexadecimal. This fingerprint is then transmitted using a hardcoded authToken that is publicly visible in the source of telemetry/config.go. While raw credentials are not directly serialized on the wire, the resulting fingerprint is deterministic and derived from secret-bearing content.

Root Cause

The root cause is a design flaw combining two weaknesses. First, the telemetry client authenticates with a hardcoded public token, meaning any third party can read submissions. Second, the fingerprint generator ingests secret-bearing configuration inputs without stripping or masking them before hashing. This produces stable, secret-derived hashes accessible to anyone with the public authentication material.

Attack Vector

An attacker with access to telemetry submissions authenticated by the public authToken can collect fingerprints tied to individual AnyCable deployments. Because the fingerprint is stable across restarts and derived from known input structures, the attacker can attempt offline dictionary or brute-force attacks against guessable or leaked secret candidates to recover the original --secret, --jwt_secret, or --http_rpc_secret values.

// Patch excerpt from cli/cli.go - telemetry: refactor auth config
	if r.telemetryEnabled {
		tracker := telemetry.NewTracker(metrics, r.config, r.telemetryConfig)

-		r.log.With("context", "telemetry").Info(tracker.Announce())
-		go tracker.Collect()
+		if tracker.Enabled() {
+			r.log.With("context", "telemetry").Info(tracker.Announce())
+			go tracker.Collect()

-		r.shutdownables = append(r.shutdownables, tracker)
+			r.shutdownables = append(r.shutdownables, tracker)
+		}
	}

Source: GitHub Commit 201c67e. The fix gates telemetry collection behind an explicit tracker.Enabled() check, preventing collection when authentication configuration is not valid.

Detection Methods for CVE-2026-63406

Indicators of Compromise

Outbound network connections from AnyCable processes to the default telemetry endpoint on vulnerable versions
Presence of AnyCable binaries reporting versions earlier than 1.6.15 in production inventory
Process arguments containing --secret, --jwt_secret, or --http_rpc_secret on hosts running the affected telemetry subsystem

Detection Strategies

Inventory all AnyCable deployments and compare running versions against the fixed release v1.6.15
Inspect service manager unit files, container manifests, and orchestration configs for secret values passed as CLI flags rather than environment variables or secret stores
Audit egress firewall logs for connections from AnyCable hosts to third-party telemetry endpoints

Monitoring Recommendations

Alert on new outbound HTTPS connections from realtime server hosts to non-approved destinations
Track AnyCable binary versions during deployment pipelines and flag any release older than 1.6.15
Monitor configuration changes that introduce or rotate secret, jwt_secret, or http_rpc_secret values, which may require rotation after upgrade

How to Mitigate CVE-2026-63406

Immediate Actions Required

Upgrade AnyCable to version 1.6.15 or later across all environments
Rotate any values previously supplied via --secret, --jwt_secret, and --http_rpc_secret on vulnerable hosts
Disable the telemetry subsystem on any instance that cannot be upgraded immediately

Patch Information

The vulnerability is fixed in AnyCable release v1.6.15. The patch is available in GitHub Commit 201c67e and released with GitHub Release v1.6.15. Full advisory details are published in GitHub Security Advisory GHSA-w72w-9qmj-c9qm.

Workarounds

Disable telemetry collection by setting the appropriate configuration flag before restarting AnyCable
Supply secrets through environment variables or a secrets manager instead of CLI arguments to reduce exposure surface
Restrict egress from AnyCable hosts to prevent telemetry submissions until patching completes

bash

# Disable AnyCable telemetry as a temporary workaround
export ANYCABLE_DISABLE_TELEMETRY=true

# Upgrade to the fixed release
go install github.com/anycable/anycable-go/cmd/anycable-go@v1.6.15

# Verify the running version
anycable-go -v