Tailscale SSH Exposed: 11 Vulnerabilities—One Host Compromised, root Spreads to the Next

On October 25, 2026, security researcher Erica Windisch published a report at Cyberdione Labs called Tailworm: Tailscale SSH has 11 issues, divided into 5 groups, with testing on Tailscale 1.104.2 and headscale 0.29.5. There is no CVE and no patch.

First, some background. Tailscale is a private networking tool based on WireGuard that connects different machines into a virtual LAN called a tailnet. Tailscale SSH is a built-in feature: once enabled, devices in the tailnet can SSH into one another according to ACL policies, without having to manage keys and passwords yourself. It is convenient, and that is why many people use it.

The problem lies in the implementation. The Tailscale SSH server runs inside the tailscaled background process, and tailscaled runs with root privileges. When an SSH session performs port forwarding (ssh -L or ssh -R), the Unix socket path checks and file operations involved are all executed as root.

The lab demonstration in the report: an ordinary, authorized SSH session connected to the Docker socket through forwarding and read /etc/shadow on the host. In another chain, the attacker captured a device registration key and added a node of their own to the tailnet, making it look like a normal, tagged server. Propagation per hop took less than a second.

A bucket of cold water: this attack requires an initial foothold. The attacker must first compromise a device in the tailnet, for example through a vulnerable web app, a malicious dependency package, or stolen credentials. Tailscale itself did not create this hole; its problem is that it turns this hole into an entry point to the entire network.

Tailscale VP of Engineering Mike Shaver responded on Reddit. He said the team is already investigating independently and has brought in external security experts, and has confirmed that some issues are being fixed. His judgment is: at present, not recommending everyone disable Tailscale SSH. Most issues occur 'after a connection has already been authorized' and involve Unix permissions and how SSH forwarding is handled; in some cases a session can do more than it should be able to.

He gave several recommendations: review SSH access policies and grant access only to the people and devices that need it; review forwarding permissions and turn them off if not needed; enable check mode to add an authentication layer; enable automatic updates to keep up with patches.

On the researcher's side, they believe the report was 'reported but not coordinated.' Some people on Hacker News complained that the report is hard to read. The two sides are still sizing each other up.

Community reaction is somewhat split. Some think there is no need to panic: a device must first be compromised; it is serious but not something to get out of bed in the middle of the night for. Others say outright that treating VPN access as blanket trust is the root problem. Some also brought up old cases.

This year Tailscale has already issued two security advisories, TS-2026-006 and TS-2026-009, both involving paths from SSH to root; one was triggered by the username '-i', and both were fixed in 1.98.9. In July this year, an AI agent used a stolen reusable Tailscale key to register 181 nodes into Hugging Face's network, without exploiting any vulnerability.

The core issue may not be any specific bug, but a default assumption: devices in the tailnet are trusted, and once connected they can access one another. This assumption holds when there are few devices and they are all your own machines. Once someone else's device gets into the tailnet, or one of your own machines is compromised, the entire mesh becomes a flat network for the attacker.

One line in the report is quite accurate: zero trust is a policy file, not a property of software.

What to do specifically:

• On nodes that do not use Tailscale SSH, run tailscale set --ssh=false.
• Use regular OpenSSH over the tailnet; it drops to user privileges before the session starts, avoiding the most serious class of issues.
• Write SSH rules pairwise, one source to one target; do not use tag-level allow-all. The report says pairwise authorization was the only control in the lab that stopped propagation.
• Deny forwarding if it is not needed. headscale 0.29.5 currently cannot disable forwarding separately; all SSH authorizations must be treated as root privileges.
• Remove serve forwarding that points to Unix sockets.
• Enable node-key expiration and Tailnet Lock, and replace reusable auth keys with one-time keys.
• If a device is compromised, delete it in the console. Reinstalling the system will not revoke keys that have already been copied out.

One netizen's comment is worth recording: this requires a device to be compromised first; it is serious, but there is no need to be in a panic. Another put it more directly: it is not a Tailscale problem; it is the problem of treating VPN access as blanket trust.