"Tailworm" report alleges root escalation via Tailscale SSH forwarding

Researcher Erica Windisch of Cyberdione Labs published a report she calls "Tailworm" on October 25, describing 11 unpatched findings in Tailscale and headscale. The lead issue: a compromised device on a tailnet can abuse Tailscale SSH port forwarding to reach root on other servers it is already permitted to connect to. There is no CVE and no vendor fix as of writing, and Tailscale has not confirmed the technical claims. This post is based on the researcher's self-published report and reporting at The Hacker News and SC World — treat the specifics as unverified until Tailscale responds.

What's affected

Windisch says she tested Tailscale 1.104.2 and headscale 0.29.5 in a lab over three days. The findings have not been independently reproduced, and the proof-of-concept is not public.

The attack has two preconditions:

1. Tailscale SSH configured to allow port forwarding.
2. The attacker already controls one device that the tailnet's access rules permit to connect to the target.

No stolen keys or passwords are needed. Tailscale does not create the initial foothold — that comes from the usual sources (a vulnerable web app, a poisoned package, phishing). The report chains standard SSH forwarding into a root-owned Unix socket, then uses a time-of-check/time-of-use race to defeat the forwarding file-access check and capture an enrollment key — joining an attacker machine to the network as a trusted node.

Per the reporting, the full chain only completed on tailnets without Tailnet Lock enabled. With Tailnet Lock on, secrets were captured but the final node-enrollment step did not complete.

Exploitation status

No in-the-wild exploitation is reported. Windisch describes the behavior as "wormable"; some researchers dispute that label, and no third party has published a reproduction. Tailscale VP of engineering Mike Shaver acknowledged the report on Reddit, said the company found issues it is working to fix, and added that Tailscale is "not recommending that everyone disable Tailscale SSH." Watch Tailscale's security bulletins for the authoritative fix and any CVE assignment.

Action checklist

1. Scope SSH grants to single source-to-destination pairs. The report credits per-pair rules with stopping propagation in testing; drop broad identity- or tag-based SSH grants.
2. Disable SSH port forwarding where you don't need it. On the hosted service it's a per-rule setting. On headscale 0.29.5 it cannot be disabled — treat every SSH grant there as granting root on the target.
3. Remove tailscale serve forwards that point at a Unix socket, and strip app-connector permissions from devices that don't need them.
4. Enable Tailnet Lock and node-key expiry. Tailnet Lock blocked the final step in testing.
5. If a device is compromised, delete it at the control plane. Reimaging alone does not revoke keys an attacker already copied.

Context

This lands on an already-busy quarter for Tailscale SSH privilege escalation. Earlier 2026 advisories — ts-2026-004 (Unix socket forwarding to a privileged socket, fixed in 1.98.9), ts-2026-006 (numeric-UID ACL bypass), and ts-2026-009 (leading-dash username reaching root) — all turned SSH access into root through narrow parsing or forwarding gaps. Tailworm, if it holds up, is the same failure class at tailnet scale. The disclosure itself is contested: a commenter quoted by The Hacker News called it "reported but not coordinated," and the vendor fix is still pending. Until Tailscale confirms, the safe move is to narrow SSH grants now — that mitigation costs nothing and closes the documented spread path regardless of how the technical dispute resolves.