- A researcher's lab tests found that one compromised device on a Tailscale network can gain root on servers it may reach, if Tailscale SSH allows port forwarding.
- Tailscale had issued no bulletin, CVE or fixed version at publication, and says it is working on fixes. The tests were in a lab, not on real networks.
- Check SSH rules now: use per-pair grants, turn off forwarding where possible, and plan to remove compromised devices at the control plane.
The network trusts machines, not people
Tailscale SSH does not check a password or a key when someone connects. According to the Tailworm report by Erica Windisch of Cyberdione Labs, the login step finishes with no user check at all. The network has already identified the device. One policy rule, from a source device to a target device, decides whether the session opens.
That is the idea worth holding onto. The network authorizes machines. So malware on a permitted machine speaks with that machine's full authority. In the report's words, "the mesh converts one ordinary foothold into fleet-wide privileged access at machine speed." Think of a building whose doors check which office a visitor came from, not who the visitor is.
What the researcher showed
Windisch tested Tailscale v1.104.2 and headscale v0.29.5 from October 22 to 24. Headscale is the self-hosted server some teams run instead of Tailscale's hosted service. She says all findings were reproduced in a lab on unmodified, released software.
The attack has a precondition. The attacker must first control one device on the network. The report names common ways in: an exploited web application, a malicious software dependency, a phishing implant or stolen login details. Tailscale does not create that foothold. The attacker also needs an SSH rule that lets the compromised device connect to the target, with port forwarding allowed.
How the flaw works
Port forwarding lets an SSH session ask the server to connect to a local channel on its behalf. On Tailscale SSH, the process doing this is tailscaled, and it runs as root. In the lab, an ordinary session could steer that root process toward a system socket meant only for root. The result was a root identity (uid=0) and the contents of /etc/shadow, the system's password-hash file.
A second method swapped a root-owned socket for one the attacker controlled. For Docker, the report says this captured registry credentials in cleartext. For some other services, it allowed direct root command execution.
The third method defeated a safety check on file paths. The server checks a path, and the connection happens a moment later. The researcher ran a loop that swapped the path about 170,000 times a second to win that gap. The report says this let a stock Docker daemon start a container with the host's root filesystem mounted. On the SELinux test system, reads of host files were blocked.
The report says all three findings share one root cause. It points to a fix used for Dropbear's CVE-2025-14282, where the server switches to the session user's privileges before handling channel requests. It says OpenSSH already does this.
What is not established
The tests were run in a lab, not against real networks. According to The Hacker News, as of publication Tailscale had not released a security bulletin, a CVE identifier or a fixed version.
Tailscale has responded in public. The Hacker News says Mike Shaver, its vice president of engineering, posted on Reddit that the company has the report and had already been studying these areas with outside security specialists. Per that account, Tailscale has found issues it plans to fix and has not yet settled which setups are affected. He added that Tailscale is "not recommending that everyone disable Tailscale SSH."
Windisch calls the result wormable. In her lab measurements, an infection moved to each permitted device in under a second per hop. The Hacker News says some researchers have publicly questioned that description. She also chose to publish quickly, arguing that awareness will speed remediation. She says she is not employed or paid by Tailscale.
What to ask your team
Start with scope. Which servers have Tailscale SSH turned on, and do any rules allow forwarding? The report says per-pair grants, one source to one destination, were the single control that stopped spread in the lab. It advises against rules that cover a whole identity or tag.
Then check the setup. Administrators of Tailscale's hosted service can turn forwarding off in each rule. On headscale v0.29.5, the report says forwarding cannot be disabled, so every SSH grant there should be treated as root on the target.
Ask about recovery as well. The report says a copied node key survives a reimage of the host. Only deleting the device at the control plane, or letting its key expire, revokes it. It also recommends keeping security logs on systems a compromised server cannot reach. Ask whether your incident plan includes those steps.
A private network does not remove the first compromise. It decides how far that compromise can travel.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cyberdione Labs (Erica Windisch).
