A Researcher Published 11 Tailscale Findings Before Tailscale Had a Patch. The Fix Landed in 1.104.4 a Day Later. Here Is What a Solo Operator Should Check.
On October 25, researcher Erica Windisch of Cyberdione Labs published a report called Tailworm, describing 11 findings in Tailscale and related software, before Tailscale had a patch. By October 27, Tailscale had confirmed the main issues are real and called them serious, and a fix tagged as version 1.104.4 followed that day. If you run a server behind a Tailnet and use Tailscale SSH, you have an update and a rules check to do, and neither is hard.
What the report claims
According to The Hacker News, Windisch tested for three days on Tailscale 1.104.2 and headscale 0.29.5, in a lab. The most serious chain starts with SSH port forwarding. Standard forwarding made the root-level Tailscale process connect to a root-only system socket, which gave root access on the target. Other findings covered replacing a root-owned socket, and a timing bug in a file-access check that, on networks without Tailnet Lock, let the chain capture an enrollment key and join an attacker's machine as a trusted server.
The prerequisites matter. The attacker needs to already control one device that your access rules allow to reach the target, and Tailscale SSH needs forwarding enabled. Nobody is breaking into your Tailnet from the outside with this. The danger is that a single compromised laptop could become root on every server it is allowed to SSH into.
What is disputed
Three things are worth keeping in your head. First, the report calls the issue "wormable," and some researchers dispute that, since the report itself says narrow source-to-destination rules stopped the spread, and hardware-bound device keys limited it. Second, the findings rest on one researcher, and the proof-of-concept code is not public. Third, the disclosure was not coordinated: Windisch says she sent the report to Tailscale's security contact the Saturday before publishing, and some commenters called that irresponsible.
Tailscale's VP of Engineering, Mike Shaver, said most of the issues are about what a user can do after they are already authorized, and that impact depends on how an organization has set its SSH access. He did not recommend turning off Tailscale SSH. I think that is the right framing, and also the least comforting one for a one-person shop, because you wrote your own access rules, probably in a hurry.
The fix and what it covers
One third-party tracker, hol.org, reports that version 1.104.4 was tagged on October 27 and addresses the SSH socket-forwarding escalation (TS-2026-014), plus three other advisories: a memory-exhaustion bug in authenticated SSH sessions, a tailscale serve --tcp path to the local API, and header leakage between HTTP/2 mounts. Its notes say the headscale memory findings and the experimental app connector bug are not fully closed, and that no CVE IDs were out yet. I could not reach Tailscale's own advisory page from here, so confirm the version against the official advisory before you rely on my summary.
What I would do in ten minutes
Update first. On each node running Tailscale SSH or tailscale serve, run sudo tailscale update, then tailscale version and check you see 1.104.4 or later.
If you cannot update yet, Tailscale's own interim mitigation is to set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment (on Linux that is typically /etc/default/tailscaled) and restart the service. It disables forwarding without turning off Tailscale SSH.
Then fix the rules, because a patch does not repair a permissive policy. Replace broad grants such as "all of my devices can SSH to all of my servers" with specific source-to-destination pairs. Stop granting root or passwordless-sudo accounts as SSH targets where you can. If you use headscale, note that the report says 0.29.5 cannot deny forwarding per rule, so the environment variable above is your control until a fix arrives.
Finally, turn on node-key expiry. If you ever decide a device is compromised, delete it from the control plane. Reimaging does not revoke keys that were already copied.
Where this could be wrong
If the findings are overstated, you have spent ten minutes tightening rules you should have tightened anyway. If they are understated, you have closed the door before the proof-of-concept goes public. The only version of this where acting costs you is the one where you break an SSH workflow that relied on forwarding, and the way to find that out is to try it on one node first.
Author
Lukas
@lukcombinator