Tailworm: Unpatched Tailscale SSH Flaws Let One Hacked Device Reach Root on Every Server the Mesh Allows — No CVE, No Patch, and the Researcher Calls the Chain Wormable
Tailworm: Unpatched Tailscale SSH Flaws Let One Hacked Device Reach Root on Every Server the Mesh Allows — No CVE, No Patch, and the Researcher Calls the Chain Wormable
A security researcher has published a lab-verified chain of Tailscale SSH flaws that turns one compromised device into root access on every other server the network's access rules permit — with no stolen passwords, no stolen keys, and no user action. Erica Windisch of Cyberdione Labs published the findings on October 25 in a report called Tailworm, after testing Tailscale 1.104.2 and the self-hosted headscale 0.29.5 over three days in a lab. As of publication, Tailscale had issued no security bulletin, no CVE identifier, and no fixed version.
Tailscale SSH is not a normal SSH server: instead of checking passwords or keys, it identifies the connecting device, and a single access rule decides whether that device may open a session to a target. The attack needs a foothold on one device first — a vulnerable web application, a poisoned package, phishing, or stolen credentials — and then exploits how the privileged Tailscale process handles forwarding. In the lab, standard SSH port forwarding made the root-level process dial a system socket only root should reach, and the test read the system password file almost immediately. A second method replaced a root-owned socket with the attacker's own, allowing direct root command execution. A third defeated the path allowlist with a time-of-check race, then went further: it captured the key used to enroll new devices and joined an attacker's machine to the network as a trusted server — fully, on networks where the Tailnet Lock feature was off. Windisch describes the result as "wormable": one ordinary foothold spreading to every permitted device "at machine speed," under a second per step.
The findings are contested in the way unpatched research usually is. Tailscale's vice president of engineering, Mike Shaver, responded on Reddit that the company had received the report, had already been examining the same areas with outside security specialists, and is "not recommending that everyone disable Tailscale SSH." Some researchers questioned the "wormable" framing; no one else has publicly reproduced the results, and the proof-of-concept code is not public — Windisch says she provided it to Tailscale's security contact before publishing, and calls the disclosure "reported but not coordinated." Two things held the chain back in testing: access rules written as single source-to-destination pairs stopped the spread on their own, and device keys tied to hardware (TPM, Secure Enclave) blocked the enrollment-key step. The SSH chain is one of eleven findings in the report — Windisch told The Hacker News the app-connector finding, which lets a permitted user send traffic to destinations the security team never approved, including cloud metadata services, "may be more impactful to some organizations."
One deployment detail sharpens the risk: on Tailscale's hosted service, SSH port forwarding can be switched off per rule — but on headscale 0.29.5 it cannot be turned off at all, so the report advises treating every SSH grant there as giving root on the target. Tailscale fixed a related SSH socket-forwarding flaw earlier this year in 1.98.9.
What Should You Do?
- Rewrite your Tailscale SSH access rules as single source-to-destination pairs — one device, one target, no broad identity- or tag-based grants. The report calls per-pair rules the one control that stopped the spread in testing.
- Turn off SSH port forwarding where you can — per-rule on the hosted service; impossible on headscale 0.29.5, where every SSH grant should be treated as root on the target.
- Shrink the rest of the surface — remove app-connector permissions from devices that do not need them, remove
tailscale serveforwards pointing at Unix sockets, and enable node-key expiry so a stolen device key does not live forever. - Assume keys outlive images — if a device is compromised, delete it from the control plane; reimaging the machine does not revoke keys an attacker may already have copied. Tailnet Lock and SSH check mode add further barriers (check mode does not fix the escalation, it only slows the approach).
The WAF Angle
There is no web payload in Tailworm — which is exactly why it belongs in a web defender's threat model. The report's own foothold list starts where web applications live: a vulnerable web app or a poisoned package, the same entry points behind the Bricksforge upload-to-RCE chain and this month's PHP2Shell emergency. Once that foothold exists, the mesh converts it into fleet-wide privileged access — the same "pivot from the perimeter device" story as ransomware crews living inside a patched GlobalProtect VPN and the 16-year-old Broadcom Wi-Fi flaw handing root to anyone in radio range: network adjacency plus weak access rules equals root. The WAF's job in that picture is the unglamorous one — stop the first foothold at the web tier, because everything after it runs as trusted traffic the mesh was designed to carry.
