Anycable
Monthly
AnyCable (anycable-go) through 1.6.14 ships its telemetry subsystem enabled by default with a hardcoded public auth token ('secret' in telemetry/config.go) and derives its cluster fingerprint by hashing the full configuration file plus raw os.Args, which can include values passed via --secret, --jwt_secret, and --http_rpc_secret; an adversary who can MITM or DNS-hijack telemetry.anycable.io can intercept the outbound telemetry POST, and because the client's token is publicly known it offers no protection. The transmitted clusterFingerprint is a SHA256 digest rather than raw plaintext, so meaningful secret recovery additionally depends on low-entropy secrets, and the required network-interception position makes this a moderate-to-low real-world risk best characterized as a hardcoded-credential and telemetry-exposure design flaw rather than a directly exploitable credential leak. Exploitation status: no public exploit code identified at time of analysis and no confirmed active exploitation (CISA KEV); the GHSA advisory documents only a conceptual DNS-spoofing reproduction. Vendor-released patch: 1.6.15.
Signed-request replay in AnyCable's Pusher-compatible REST API (version 1.6.14 and earlier) lets anyone who obtains a single legitimate signed POST request resend it with a completely different body, because the handler folds the caller-supplied body_md5 into the HMAC string but never computes or compares the digest of the body actually received. The same code path omits any auth_timestamp freshness check, so a captured auth_signature remains valid indefinitely. Successful abuse causes the server to broadcast attacker-chosen event content to arbitrary channels within that signed request's application context, enabling forged server-side events, application-state corruption, or phishing messages delivered to WebSocket clients. Exploitation hinges on first capturing a signed request (for example from a TLS-terminating proxy's logs), which is why attack complexity is rated High under CVSS 5.9; no public exploit code was identified at time of analysis and there is no KEV entry.
AnyCable (anycable-go) through 1.6.14 ships its telemetry subsystem enabled by default with a hardcoded public auth token ('secret' in telemetry/config.go) and derives its cluster fingerprint by hashing the full configuration file plus raw os.Args, which can include values passed via --secret, --jwt_secret, and --http_rpc_secret; an adversary who can MITM or DNS-hijack telemetry.anycable.io can intercept the outbound telemetry POST, and because the client's token is publicly known it offers no protection. The transmitted clusterFingerprint is a SHA256 digest rather than raw plaintext, so meaningful secret recovery additionally depends on low-entropy secrets, and the required network-interception position makes this a moderate-to-low real-world risk best characterized as a hardcoded-credential and telemetry-exposure design flaw rather than a directly exploitable credential leak. Exploitation status: no public exploit code identified at time of analysis and no confirmed active exploitation (CISA KEV); the GHSA advisory documents only a conceptual DNS-spoofing reproduction. Vendor-released patch: 1.6.15.
Signed-request replay in AnyCable's Pusher-compatible REST API (version 1.6.14 and earlier) lets anyone who obtains a single legitimate signed POST request resend it with a completely different body, because the handler folds the caller-supplied body_md5 into the HMAC string but never computes or compares the digest of the body actually received. The same code path omits any auth_timestamp freshness check, so a captured auth_signature remains valid indefinitely. Successful abuse causes the server to broadcast attacker-chosen event content to arbitrary channels within that signed request's application context, enabling forged server-side events, application-state corruption, or phishing messages delivered to WebSocket clients. Exploitation hinges on first capturing a signed request (for example from a TLS-terminating proxy's logs), which is why attack complexity is rated High under CVSS 5.9; no public exploit code was identified at time of analysis and there is no KEV entry.