Tailscale shipped the fix on Wednesday and spent much of the same post arguing about the name.
Version 1.104.4 closes privilege-escalation flaws in Tailscale SSH and bugs in Serve and Funnel, documented in four security bulletins, TS-2026-014 through TS-2026-017. It lands five days after Erica Windisch of Cyberdione Labs published "Tailworm", 11 findings across five classes tested against tailscale 1.104.2 and headscale 0.29.5 between 22 and 24 October. There was no coordinated disclosure: Tailscale says the report arrived on the morning of Saturday 24 October and was published two hours later.
The bug is in what happens after the login
Tailscale's own framing is the clearest one. The flaws were not in authentication or policy evaluation — the layer that decides who may connect — but in how permissions were enforced once a session had been authorised. Tailscale SSH needs elevated system privileges so it can start sessions as different Unix users, and the boundary between those elevated rights and the connected user's session was not held in every case, including through SSH forwarding.
In the researcher's lab, one compromised device was enough to reach root on other servers and to enrol a rogue node. That is where the name comes from: a single foothold turning into a key to the rest of the mesh. Most of the 11 findings were rated High or Medium-High by the researcher.
What the vendor concedes, and what it contests
Tailscale concedes that the privilege boundary was enforced incorrectly, calls the issues urgent, and says it went beyond the reported symptoms to add "architectural safeguards" against broader classes of related bugs.
It contests nearly everything about the framing. An unauthenticated attacker cannot connect to arbitrary Tailscale SSH servers: exploitation requires an existing foothold on an authorised peer, SSH access explicitly permitted in the tailnet policy file, and the conditions needed to reach the vulnerable code. Because that policy file still gated machine-to-machine access, an attacker could only reach machines the policy already allowed.
And it is not a worm. "They don't describe self-replicating malware spreading automatically between machines," the post says. "Instead, this would be better described as lateral movement limited to connections allowed by a tailnet policy file."
Of five findings in Serve and Funnel, three were bugs and are fixed; two describe intended behaviour — bypassing the Funnel attribute check requires local admin, and TS_SERVE_ALLOW_ALL_INTERFACES is an opt-in setting. The report's Conn25 finding concerns an app connector that has never shipped; the stable connectors are unaffected.
The report also covered headscale, the separate open-source control server that Tailscale does not maintain. Version 0.29.6 shipped on 24 October with release notes that did not mention the findings. Operators self-hosting that control plane are, as of publication, working from interim mitigations rather than a vendor fix.
The same subsystem, twice
The two components that failed are the two that failed in June. TS-2026-004 and TS-2026-005, both published 3 June and fixed in 1.98.9, covered SSH Unix socket forwarding ignoring symlink permissions and Serve Unix socket proxy targets not being restricted to root. Adding architectural safeguards is the right response to a repeat — but it is also an acknowledgement that the June fixes were point patches on the same seam.
What to do
Update to v1.104.4 or later. Then treat the policy file as the security boundary it has now been shown to be. Rewrite SSH rules as per-pair grants, one named source to one named destination, and drop identity-wide and tag-wide accept rules; deny forwarding in each rule action. Turn on SSH check mode for sensitive systems. Run `tailscale set --ssh=false` on devices that do not need Tailscale SSH, after confirming another way in. Remove the app-connector capability where it is unused, and audit Serve forwards that point at Unix sockets.
If a node is suspect, delete it at the control plane. Reimaging does not revoke node keys that were already copied out, and a compromised Tailnet Lock signing node means rotating Tailnet Lock.
The structural point survives the patch. A zero-trust mesh concentrates access decisions in one place, which is exactly why it is worth running — and exactly why errors there are categorically worse than errors in any single server it protects. Tailscale's product is the guarantee that a stolen laptop cannot become a skeleton key. For a few days in October, the report said it could.
