Tailworm: One Hacked Box, Root On The Next One 11 Unpatched Tailscale Findings, And What To Lock Down Tonight Your private network is only private until one device on it gets owned. A new report says Tailscale SSH can turn that one device into root on the others. No patch. No CVE. Yet. ---------------------- On Oct 25, researcher Erica Windisch (Cyberdione Labs) published "Tailworm": 11 findings in 5 groups, tested on Tailscale 1.104.2 and headscale 0.29.5 between Oct 22 and 24. The core issue: Tailscale SSH runs inside tailscaled, and tailscaled runs as root. When a session forwards Unix sockets (ssh -L / -R), the path checks and file operations happen with root rights. In her lab, an ordinary session went through the Docker socket and read /etc/shadow. Another chain captured an enrollment key and joined a rogue node that looked like a trusted server. Spread took under a second per hop. No passwords, no stolen keys. 🔹What Is Confirmed, What Is Not🔹 ▫️ Every result is a lab reproduction, not a breach in the wild ▫️ Tailscale's latest bulletin is still TS-2026-013. Nothing on Tailworm, no fixed version ▫️ VP of Engineering Mike Shaver says they are reviewing it and don't recommend everyone disable Tailscale SSH. His advice: review SSH policies and forwarding, turn on auto-updates ▫️ The researcher says it was "reported but not coordinated". Critics on HN call the report unreadable ▫️ The attacker still needs a first foothold: a vulnerable web app, a poisoned package, a phishing implant, stolen creds 🔹Why It Matters Beyond IT🔹 Not the first time this year. Bulletins TS-2026-006 and TS-2026-009 described SSH paths to root, one through a username of "-i". Both fixed in 1.98.9. In July, an AI agent used one stolen reusable Tailscale key to enroll 181 nodes into Hugging Face's network. No bug needed. Plenty of builders run bots, RPC nodes, validators and AI agents on a VPS reachable only through Tailscale. The mesh is the perimeter. One owned box becomes every box's problem. 🔹Actionable NFA for Builders🔹 📝 Check if you even use it. Open your policy file and read the ssh section. Not needed on a node? tailscale set --ssh=false. Keep another way in first, or you lock yourself out. 📝 Plain OpenSSH over the tailnet still works, and it drops to the user's privileges before the session starts. 📝 Rewrite SSH rules per pair: one source, one destination. No tag-wide or all-members rules. Per-pair grants were the only control that stopped the spread in the lab. 📝 Deny forwarding in each SSH rule unless you need it. On headscale 0.29.5 you can't, so treat every SSH grant as root. 📝 Remove serve forwards that point to Unix sockets, and unused app connector permissions. 📝 Turn on node-key expiry and Tailnet Lock. Swap reusable auth keys for one-off or ephemeral ones. 📝 If a box gets compromised, delete it at the control plane. Reimaging doesn't revoke keys that were already copied. 📝 Turn on auto-updates and watch tailscale .com/security-bulletins. My thesis strengthens if the official bulletin confirms the forwarding findings and ships a privilege-drop fix. It weakens if it scopes most of this to headscale or unusual configs. Zero trust is a policy file. Not a property of the software. Do you run Tailscale SSH on anything that holds keys?
