Tailworm

-- Erica Windisch, Cyberdione Labs Corporation Security Assessment Report — Tailscale v1.104.2 and headscale v0.29.5 Testing window: 2026-10-22 to 2026-10-24. All findings were verified by reproduction in a lab environment on unmodified, released software (tailscale v1.104.2, headscale v0.29.5). Lab and organizational identifiers are redacted. Finding identifiers: T1–T3, C1–C4, and F-1–F-5 are internal audit labels, retained so the reproduction kits can be cross-referenced. High-level summary What was audited. Tailscale client agent v1.104.2 (tailscaled, its embedded Tailscale SSH server, its serve/funnel feature, and its DERP relay client), the headscale v0.29.5 self-hosted control server, the gliderssh library both build on, and the experimental conn25 app-connector feature. Findings fall into five classes; each names the component it affects. # Component / feature Mechanism (what breaks) Attacker requirement Principal outcome 1 Tailscale SSH (tailscaled's embedded SSH server, running as root) Unix-socket forwarding (ssh -R/-L) performs path checks and file operations as root; races and missing privilege drop let an ordinary session replace, dial, or delete privileged resources One approved device + one SSH policy rule (forwarding granted automatically on headscale; per-rule on SaaS) Root execution on target servers; capture of enrollment keys; arbitrary root-file deletion 2 Tailscale app connectors (conn25, experimental) Connector translates traffic to attacker-chosen destinations with no validation; network ACLs are never consulted for the true destination A device granted the connector capability Reach cloud metadata (credential theft), internal LANs, and — in Kubernetes — every cluster service 3 headscale control server (self-hosted deployments) Unauthenticated resource exhaustion (memory growth, cache eviction) Internet reachability; no account Control-server crash loop; blocking of new-device onboarding org-wide 4 Tailscale DERP client (relay connection in every agent) Unbounded read of a malicious relay's response Ability to position/point a client at a hostile relay Client-agent memory exhaustion 5 tailscale serve (local service exposure) TCP-forward to a unix socket lacks a guard present on the HTTP path; plus a race in per-mount authorization Operator configures the forward (or a peer races the mount check) Remote administrative-API access to the node; minority of requests bypass app authz How initial intrusion plausibly occurs. Class 1 assumes the attacker already holds a foothold on one device — which happens the ordinary ways: an exploited web application (a vulnerable PHP page or CMS plugin), a malicious build dependency (npm/PyPI package, Docker base image, GitHub Action), a phishing implant, a supply-chain compromise, or stolen identity credentials. Tailscale does not create the foothold; the finding is that the mesh converts one ordinary foothold into fleet-wide privileged access at machine speed, because inter-device paths are granted by policy that assumes trusted endpoints while the agent's privileged operations are reachable from unprivileged sessions. Practical risk in default deployments. With Tailscale SSH enabled (opt-in per node, often fleet-wide): one compromised account reaches root on other servers (class 1) and, in default (Tailnet-Lock-disabled) configurations, joins an attacker machine as a legitimate tagged server with routes auto-approved. With app connectors configured: policy-invisible reach into cloud credentials and Kubernetes services (class 2). With a self-hosted, internet-reachable headscale: unauthenticated crash loop and onboarding lockout (class 3). Any client pointed at a hostile relay: agent exhaustion (class 4). Any node with the serve forward configured: remote admin-API exposure (class 5).

Wormability.

Measured in a lab: policy-granted Tailscale SSH plus class-1 findings allow automated spread to every device the policy permits — no passwords, no stolen keys, no user interaction, under a second per hop. Two structural limits held: per-pair access grants bound the spread (the single control that stopped it), and hardware-bound device credentials (TPM/Secure Enclave) prevent the identity theft that makes compromise persist. All other controls changed visibility speed, not spread. Mitigations, in order of effect. (1) Per-pair SSH grants — never identity-wide or tag-wide accept rules. (2) Disable SSH forwarding: on SaaS, set the per-rule forwarding fields to false; on headscale v0.29.5 forwarding cannot be disabled — it is granted unconditionally on every accepted session, so until fixed, treat every headscale SSH grant as root-equivalent. Restricting SSH to non-privileged accounts is defense-in-depth only — it does not mitigate these findings, which operate from fully unprivileged accounts. (3) Node-key expiry on server fleets; TPM/Secure-Enclave-bound agent state. (4) Keep security telemetry on infrastructure a compromised server cannot reach — self-tested, with coverage reporting. (5) Restrict connector entitlements; destination allowlists or Kubernetes default-deny egress on the connector namespace. (6) Incident response built on device deletion at the control plane: a node's keys live in a file an attacker with root can copy, and reimaging the host does not revoke an already-stolen copy — only control-plane deletion (or key expiry) does. (7) Self-hosted control planes: memory limits, restart supervision, registration-rate throttling. Vendor fixes are small and precedented (OpenSSH, Dropbear); the above protects you before and after they ship. Executive summary for business readers Race conditions in Tailscale SSH socket handling (findings 1–3, 7). A person with ordinary approved access to a server over the corporate mesh can — without passwords, administrative rights, or special software — take over the internal communication channels that the most privileged services on that server use, including the container platform and the init system. Demonstrations yielded full administrator control and, separately, capture of the credentials that enroll new devices. Exposure exists wherever Tailscale SSH is enabled; the fix is small and already proven in two competing products. Forwarding features run with full system privilege (findings 1, 3–5). The same approved user can redirect traffic in ways security policy never sees: reaching admin tools "protected" only by listening on the machine's internal interface, opening listener ports on the machine's public address, and reading files only the OS should read. Device-enrollment credential theft closes the loop (full impact chain). With the socket takeover, an attacker captures the keys that add machines to the network and joins their own machine — appearing as a legitimate tagged server with routes auto-approved. In default configurations this converts one compromised account into persistent, official-looking network presence. The app-connector feature bypasses network policy (finding 4). A validation gap lets approved users route traffic to destinations the security team never authorized — including the cloud metadata service that hands out server credentials, and in Kubernetes every internal service. Denial-of-service and lockout (findings 5–6). An unauthenticated internet user can exhaust the control server's memory or evict legitimate device approvals — blocking new devices from joining. Availability attacks, not data theft, but they can take remote-access infrastructure offline. A serving feature exposes the local admin API (finding 7). A one-line configuration exposes the agent's administrative interface to remote peers — the server's management console — and a related race lets a minority of requests bypass application permission checks.

Spend terms.