Tailworm: Can One Hacked Device Get Root Across Your Tailscale Mesh?

A new Tailworm report claims Tailscale SSH can be chained to root and spread device to device. No patch yet, but there's a mitigation. Here's what to do now.

Mint green TheTechLane cover with the TL logo, the headline One hacked device. Root on the next server?, and a mesh of network nodes with a red path hopping between them, each marked uid=0

A researcher says a single compromised device on a Tailscale network can turn an ordinary SSH grant into root on the next machine, and then do it again, hop after hop. The report, branded "Tailworm," went public on October 25 with no CVE, no patched release and only limited confirmation from Tailscale so far.

Here's what you need to know:

  • The Tailworm report lists 11 findings across Tailscale SSH, experimental app connectors, tailscale serve, DERP clients and the open-source headscale control server.

  • The headline claim: a user with an SSH grant that permits forwarding can make root-run tailscaled open root-only Unix sockets, which the author says leads to uid=0.

  • Windisch calls the result "wormable": in a lab, the chain spread to every device the policy allowed, in under a second per hop.

  • Tailscale says it's investigating and points admins to one interim switch: TS_SSH_DISABLE_FORWARDING=1.

  • As of Monday morning (October 26, IST), the newest release is still v1.104.2, and Tailscale's security bulletins don't list Tailworm yet.

UML sequence diagram of the Tailworm claim: a compromised device opens a Tailscale SSH session to a server, requests Unix socket forwarding, and root tailscaled connects to a root-only socket, giving root on the server

The claimed Tailworm chain: an ordinary SSH session, a forwarded socket, root on the target

What Happened

The Tailworm report was published by Erica Windisch of Cyberdione Labs. It says testing ran from October 22 to 24 against Tailscale v1.104.2 and headscale v0.29.5, in a lab, and groups 11 findings into five classes.

The most serious one hits Tailscale SSH, the feature that lets you SSH into tailnet machines without keys or passwords. The device is authenticated, not a credential, and the tailscaled daemon runs as root. According to the report, when a policy rule allows forwarding, an ordinary SSH session can get that root daemon to connect to, replace or race Unix sockets such as docker.sock. The report says the first variant works instantly with no race, while other paths succeed only some of the time.

From there, the author says the chain can capture a device enrollment auth key and join a rogue node, which works end to end only when Tailnet Lock is off. That's the default. Two things held in the lab: per-pair access rules, and node keys bound to hardware like a TPM or Secure Enclave.

On headscale 0.29.5, the report says, SSH forwarding can't be switched off at all, so every SSH grant is effectively root. A separate finding says the experimental "conn25" app connectors let an entitled user pick arbitrary egress destinations, including cloud metadata endpoints.

The Hacker News picked the story up on October 25, describing the flaws as unpatched. The proof-of-concept code isn't public; the report says it went only to Tailscale's security contact.

Tailscale VP of Engineering Mike Shaver answered on Reddit. In his post on r/Tailscale, he said Tailscale had received the report, had already been investigating with outside specialists, and has "identified issues we're working to fix." Most concern what happens after someone is authorized to connect, he wrote, which "isn't the same as an unauthenticated attacker being able to connect to arbitrary machines." Tailscale is "not recommending that everyone disable Tailscale SSH," and promises an advisory with confirmed findings and patches.

Why It Matters

Tailscale's whole pitch is that the network is the boundary. If one laptop or CI runner gets popped, the damage should stop at what its policy allows. Tailworm's claim is that, for SSH with forwarding, "what the policy allows" quietly means root, not the user you granted.

That's why "wormable" is the scary word here. A broad rule like "engineers can SSH to all servers" is common in small teams, and the report says that's exactly the shape that lets one foothold walk across a fleet.

Treat that claim with care, though. Nobody has independently reproduced it yet, and while Tailscale admits it found real issues, it hasn't said which of the report's specific claims hold up. Commenters in the Hacker News discussion called the root-access finding serious, but also questioned the "wormable" label and criticised the uncoordinated release. Windisch herself has described the disclosure as "reported but not coordinated," according to The Hacker News.

Fixes are moving anyway. An open pull request, tailscale/tailscale#21942, routes SSH forwarding through a privileged monitor. A merged one, #21931, fixes serve app capabilities leaking across mounts. Neither is in a tagged release yet. This isn't Tailscale's first Unix-socket forwarding bug either: bulletin TS-2026-004 covered a symlink issue, fixed in 1.98.9, per the Tailscale security bulletins.

What It Means for Developers

If you run Tailscale SSH on servers, build boxes or home labs, you don't need to panic, but you shouldn't wait for the advisory either.

  • Turn off SSH forwarding where you don't need it. Shaver's interim tip is to set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment, then restart the daemon.

  • Narrow your SSH rules. Swap "everyone to everything" for named source and target pairs. The report says per-pair grants limited the spread.

  • Enable Tailnet Lock. The report says the rogue-node step only worked with it disabled.

  • Know that check mode isn't a fix. Shaver suggests it as extra friction, but notes it doesn't stop the privilege escalation.

  • Self-hosting headscale 0.29.5? Assume every SSH grant equals root on the target until a fix lands.

  • Turn on auto-updates so the patch reaches every node fast.

UML activity flow for Tailscale admins: check whether Tailscale SSH and headscale 0.29.5 are in use, disable SSH forwarding with TS_SSH_DISABLE_FORWARDING=1, then tighten per-pair rules, enable Tailnet Lock and watch for the patch

No patch yet: a quick triage and hardening flow for Tailscale SSH

Supply-chain style risks keep landing on developer infrastructure. If you missed it, our breakdown of the OpenCode console breach that exposed AI API keys is a good companion read, as is our look at how a text file in Downloads hijacked AI coding agents.

What's Next

The big thing to watch is Tailscale's promised advisory. It should say which of the 11 findings it confirms, which versions are affected and which release fixes them. Expect a new TS-2026 bulletin and a release after v1.104.2.

Open questions remain. Will any finding get a CVE? Does headscale need its own fix for the always-on forwarding flags? And will an independent researcher reproduce the root chain, or narrow it? Until then, the report is a claim, not a confirmed exploit.

FAQ

Is Tailworm being exploited in the wild?

There are no public reports of exploitation. The proof-of-concept hasn't been released, and the author says it was shared only with Tailscale.

Do I need to uninstall Tailscale or disable Tailscale SSH?

Tailscale says no. Its interim advice is to disable SSH forwarding with TS_SSH_DISABLE_FORWARDING=1, review SSH policies and keep clients updated.

Is there a CVE or a patched version yet?

Not as of Monday, October 26 (IST). The latest release is still v1.104.2, and Tailscale's bulletin page hasn't listed Tailworm.

Sources

Follow TheTechLane

Keep learning AI, development, and modern developer technologies with TheTechLane.

Learn • Build • Share

Follow @thetechlanehq for more developer guides, tutorials, and practical technology content.