Guide · Network security

Tailworm: the unpatched Tailscale SSH flaws, explained

Tailscale is the private network many small teams use to reach office servers, home labs and cloud machines without opening ports. On 25 October a researcher published eleven flaws in it, with no fixed release to install. The serious ones only matter if you use one particular feature. This guide shows how to tell, and what to change today.

By Elliot · Published 26 October 2026 · 8 min read

The two-minute version

The worst flaws are in Tailscale SSH, a feature you switch on per machine. Many users never have.
An attacker first needs control of a device already inside your Tailscale network.
A fixed release was due on 27 October but was not out when we last checked. Nobody has reported real attacks.
Check for Tailscale SSH in the admin console, switch it off where OpenSSH will do, and tighten the rest.

What happened

A root-level SSH server, and a lab-built chain

Tailscale SSH lets people log in to a server using their Tailscale identity instead of SSH keys. Unlike the standard OpenSSH server, it is not a separate program: it lives inside the main Tailscale service, which runs with full root privileges. OpenSSH deliberately drops to the logged-in user's permissions before it does anything on their behalf. The report found places where Tailscale SSH did not.

The headline case is socket forwarding. SSH can forward a Unix socket, a local connection point that services such as Docker use for their controls. Tailscale SSH opened those sockets as root, so an ordinary user could reach things only root should, and a timing race beat the list meant to restrict them. In the lab, root on one machine then gave up stored enrolment keys, which let the researcher add a rogue device under the victim's identity.

Tailscale acknowledged the report and its engineers began merging fixes within hours. Code that makes forwarded sockets open with the user's own permissions was merged on 26 October. The same day Tailscale published an update calling the reports serious security issues, saying fixes for most were in testing and that it was aiming for a patched release by the end of 27 October. That evening the fixes were copied to its 1.104 release line and tagged as version 1.104.4, but when we last checked the stable download was still 1.104.2, the one tested.

Tailworm at a glance, as of 27 October 2026
Name	Tailworm, a report of 11 findings by Erica Windisch of Cyberdione Labs
Published	25 October 2026, without a coordinated release of fixes
Products	Tailscale 1.104.2 (the stable release when tested) and headscale 0.29.5, the open-source control server
Worst finding	An ordinary Tailscale SSH login could reach files and services only the root account should, then take over the machine
What an attacker needs	Control of one device already in your tailnet, with an SSH rule that lets it log in to the target
Fixed?	Not in a release yet. Tailscale aimed to ship one by the end of 27 October, and that evening tagged version 1.104.4 with the SSH fixes in its public code, but the download servers still offered 1.104.2. No bulletin or CVE
Exploited?	No reports of real-world attacks. The chain was shown in a lab only

The findings

Eleven findings, of very different weight

Grouped from the report. Severity is the researcher's own rating. Tailscale calls the reports serious but has not rated the findings one by one.

findings in the report, across Tailscale and headscale

Source: Tailworm report

50,000

businesses use Tailscale, by the company's own figure

Source: tailscale.com

fixed releases or security bulletins for Tailworm on 27 October

Source: Tailscale bulletins

Only the first three need most readers' attention, and only if Tailscale SSH is switched on somewhere. The rest concern a newer connector type, specific Serve and Funnel configurations you would have had to set up yourself, and the self-hosted headscale server. Fifty thousand businesses is Tailscale's own count of its users; it does not tell you how many have Tailscale SSH switched on, and nobody has published that.

The Tailworm findings, in plain English
Finding	Researcher's rating	What it means
Findings 1 to 3	High	Tailscale SSH opened forwarded Unix sockets as root, so a normal user could reach root-only services such as Docker's control socket, or race the allow-list meant to stop it
Finding 4	High	A newer type of app connector let an entitled user send traffic to places it should not reach, including cloud metadata services
Finding 5	High	A logged-in SSH session could exhaust the memory of the Tailscale service, which runs as root
Finding 6	Medium to High	headscale could be pushed out of memory, and pending device approvals evicted, without logging in
Finding 7	High	A specific tailscale serve set-up, pointing at Tailscale's own control socket, hands peers admin control of the node. Tailscale merged a fix that refuses it on 27 October
Findings 8 to 11	Medium or lower	Weaknesses in Tailscale Serve and Funnel set-ups. Tailscale merged fixes for finding 11 on 25 October and finding 8 on 27 October

Am I exposed?

Who is in range, and who is not

The serious findings need Tailscale SSH on the target. Everything turns on that.

Exposed: Linux servers with Tailscale SSH on

Tailscale SSH is switched on per machine, with tailscale set --ssh. It runs on Linux, and on macOS only with the open-source build of the Tailscale service. A Linux server where someone turned it on, with an SSH rule that reaches it, is the case the report is about.

Exposed: anything on headscale with SSH rules

On headscale, the report says every SSH rule also grants forwarding and it cannot be switched off. If you run your own control server and use Tailscale SSH through it, treat every SSH rule as if it granted root.

Higher risk: broad rules and stored keys

Rules that let every member reach every server, rules that allow the root user, and reusable or non-expiring auth keys left on servers all make the step from one compromised laptop to the rest of the network shorter.

Not exposed: plain OpenSSH over the tailnet

If you use Tailscale only as the network and log in with the normal OpenSSH server, the SSH findings do not apply. The report itself describes default OpenSSH as a clean negative.

Not exposed: Windows, phones, App Store Mac

Windows, iPhone, Android and the App Store version of Tailscale for Mac cannot run the Tailscale SSH server, so they cannot be the target of the SSH findings. They can still be the first device an attacker controls.

Not exposed: plain subnet routers and Funnel

Machines used only as subnet routers, exit nodes, or for ordinary Serve and Funnel sharing are outside the SSH findings, as long as nothing is forwarded to Tailscale's own control socket (finding 7).

What to do

Lock it down while you wait for the release

Step one takes a minute in the admin console and decides how much of the rest you need. If Tailscale SSH is off on every machine, skip to step five.

Find out whether Tailscale SSH is on

In the Tailscale admin console, open Machines and filter by the Tailscale SSH property. On each Linux machine you can also run tailscale debug prefs and look for "RunSSH": true. Most small set-ups will find it off everywhere, and can stop worrying about findings 1 to 3.

Switch it off where OpenSSH will do

On any server that does not need it, set up normal OpenSSH access first so you do not lock yourself out, then run sudo tailscale set --ssh=false. This is the surest fix until a fixed release is installed, because it removes the vulnerable server entirely rather than narrowing who can reach it.

Narrow the SSH rules you keep

In the access policy, name specific people or groups as the source, specific tagged servers as the destination, and one named unprivileged account as the user. Remove root from every rule and avoid accounts with passwordless sudo. Note that autogroup:nonroot limits the damage but does not stop the forwarding bug.

Switch off forwarding, then add check mode

Where you keep Tailscale SSH, Tailscale's own interim advice is to add TS_SSH_DISABLE_FORWARDING=1 to the Tailscale service's environment (on most Linux servers, the file /etc/default/tailscaled) and restart it with sudo systemctl restart tailscaled. Tailscale says this blunts several of the more serious findings without switching Tailscale SSH off. Setting an SSH rule's action to check also makes the person re-confirm who they are in a browser before the session opens, but the report says check mode does not fix the forwarding bugs, so treat it as an extra lock, not a repair.

Control which devices can join

Switch on device approval (all plans) or Tailnet Lock, revoke reusable auth keys you no longer need, and remove any key stored on a server in an environment file. Revoking a key does not remove devices that already joined with it, so check the Machines list for anything you do not recognise.

Turn on updates and watch for the release

Run tailscale set --auto-update on machines that allow it, and keep an eye on Tailscale's security bulletins page. When the fixed release lands (version 1.104.4 had been tagged but not shipped when we last checked), update servers with Tailscale SSH first, and check tailscale version on each one afterwards. If you run headscale, keep the control server off the open internet and give it a memory limit until its own fixes ship.

Reading the report fairly

What is proven, what is claimed, and what is argued

Proven, as far as anyone can tell from outside: Tailscale treated the forwarding problem as real, merged a fix for it within a day, and called the reports serious security issues in its own update. Claimed, from the lab only: that the chain spreads automatically in under a second per hop, and that it can mint a rogue device. Nobody has reproduced those publicly, and the report's own text notes that tightly scoped rules and hardware-bound device keys slowed or stopped it.

Argued: whether “worm” is fair, and how far a compromised device can see. One Tailscale engineer said the hosted service hides machines from peers with no policy path to them, so “every node sees every node” mostly describes headscale. Others disputed that, and the discussion did not settle it. Tailscale's own update does not mention the worm or rogue-device claims, and says it is still confirming which set-ups are affected. Statements attributed to its VP of Engineering reached us second-hand, through press reports of a Reddit post we could not read directly.

The useful takeaway does not depend on who wins those arguments. A tool that runs as root and accepts logins is worth switching off wherever you are not using it, and access rules that let everyone reach everything turn one lost laptop into a network problem. Both were true before 25 October.

FAQ

Tailworm and Tailscale SSH questions

What is Tailworm?

Tailworm is the name of a security report published on 25 October 2026 by Erica Windisch of Cyberdione Labs, listing 11 vulnerabilities in Tailscale 1.104.2 and headscale 0.29.5. The most serious, in Tailscale SSH, let a normal SSH login reach root-only services on the target machine. The researcher showed in a lab how that could be chained from machine to machine.

Is there a patch for the Tailscale SSH vulnerabilities?

Not as a release yet, though one is close. On 26 October 2026 Tailscale said fixes for most issues were in testing and that it was targeting a patched release by the end of 27 October. Late on 27 October the fixes were in a version tagged 1.104.4 in its public code, but the stable download was still 1.104.2, the version tested, and there was no security bulletin or CVE. Watch tailscale.com/security-bulletins and update as soon as a fixed release appears.

Am I affected if I use Tailscale but not Tailscale SSH?

Not by the SSH findings, which are the serious ones. Tailscale SSH is a separate feature that has to be switched on per machine. If you log in with ordinary OpenSSH over your tailnet, or use Tailscale only for subnet routing, exit nodes or Funnel, the forwarding bugs do not apply. A few of the other findings concern specific Serve set-ups and headscale.

Is Tailworm really a worm?

That is disputed. The report says the chain spread automatically in a lab to every machine the SSH rules allowed. Commenters, including security researchers on Hacker News, argued it is not wormable in the usual sense, because every hop needs Tailscale SSH on and a rule permitting it. A Tailscale engineer added that the hosted service hides machines from peers with no policy path to them. Nobody has reported it spreading in the real world.

Was this a responsible disclosure?

Not a coordinated one. The researcher wrote on Hacker News that the issues were reported to Tailscale but the disclosure was not coordinated, and press reports say the report and proof of concept went to Tailscale's security contact shortly before publication. Earlier Tailscale SSH bugs in 2026 went through the normal private process and were fixed before they were announced.

Does Tailscale SSH check mode protect me?

Partly. Check mode makes a person re-authenticate in a browser before an SSH session opens, which raises the bar for an attacker using a stolen device. The report says it does not fix the forwarding bugs themselves, and on headscale a session approved through check still gets forwarding. Switching Tailscale SSH off where you do not need it is the stronger step.

Should we stop using Tailscale?

We would not, on this evidence. Every serious finding needs an attacker to already control a device inside your tailnet, and most of the risk goes away by turning off Tailscale SSH where OpenSSH will do and tightening the rules you keep. Tailscale itself says it is not recommending that everyone disable Tailscale SSH. It has fixed earlier SSH bugs this year through its normal process, and fixes for this batch are already in its code.

References

Sources & further reading

The guidance on this page is grounded in primary sources. Follow the links to read them in full.

Tailworm: Security Assessment Report

The researcher's report: the eleven findings, the versions tested and the lab chain.

Tailscale: Security bulletins

Where Tailscale will announce a fixed release. No Tailworm entry as of 27 October 2026.

Tailscale: Tailscale SSH investigation and remediation update

Tailscale's own statement of 26 October 2026: the target release date, the forwarding setting, and its advice not to disable Tailscale SSH everywhere.

Tailscale: the v1.104.4 tag

The 1.104 release line with the SSH fixes, tagged late on 27 October 2026 and not yet on the download servers when we checked.

Tailscale: Route SSH forwarding through the privileged monitor (PR #21942)

The fix for the headline forwarding bug, merged to the development branch on 26 October 2026 and copied to the 1.104 release line on 27 October.

Tailscale: Fix serve app caps leaking across mounts (PR #21931)

The fix for finding 11, merged on 25 October 2026.

Tailscale: Refuse serving TCP to the tailscaled socket (PR #21966)

The fix for finding 7, merged on 27 October 2026.

Hacker News: Tailworm discussion

The researcher's note that disclosure was not coordinated, a Tailscale engineer's reply, and the dispute over the worm claim.

headscale: Bound pending authentication (PR #3586)

headscale's first fix citing Tailworm, still an open draft on 27 October 2026.