Tailscale has released version 1.104.4 to fix the flaws in its SSH server known as Tailworm, which let a compromised device gain root on other servers in the network. It affects anyone running Tailscale SSH on Linux or the open-source macOS build. Update those nodes today, or disable forwarding in the meantime.
Key facts
- Cyberdione Labs published 11 findings, dubbed Tailworm, affecting Tailscale client 1.104.2 and headscale 0.29.5, the self-hosted control server (SecurityWeek).
- Tailscale received the report on the morning of Saturday 24 October, about 2 hours before it went public.
- Version 1.104.4 covers 4 security bulletins, including TS-2026-014 (SSH socket forwarding). They carry no CVE identifiers or severity scores (BleepingComputer).
- In the researcher's tests, forwarding to the Docker control socket gave a root shell and allowed reading /etc/shadow without admin rights (The Hacker News).
- According to The Hacker News, the related headscale issues remain unpatched.
Does this affect me if my company uses Tailscale?
The forwarding flaws fixed in 1.104.4 sit in the Tailscale SSH server, the feature that lets Tailscale manage SSH access to your machines. That server only runs on Linux and the open-source macOS build. If you have Tailscale SSH enabled on servers, you are in the affected group.
It's a common setup in startups and technical SMEs: Tailscale as the team VPN and, at the same time, as the front door to servers. Even if you don't use Tailscale SSH, update your clients anyway: the report lists 11 findings, not one.
What can an attacker actually do?
First they need to have compromised a device on your Tailscale network: a laptop, a server. From there they could exploit the flaw against any server that device can reach over Tailscale SSH, as long as the access rule allows forwarding. The server performed that forwarding as root, so pointing it at the Docker socket was enough to get a root shell.
Version 1.104.4 changes that: forwarding now runs as the connected user and relies on operating system permissions.
On the label: the researchers called it wormable. Tailscale rejects the worm framing and describes lateral movement limited to connections your policy already allows (SecurityWeek). Neither the company nor the report mentions in-the-wild exploitation.
Is updating enough?
If the server is clean, yes. If it may have been compromised, no. A stolen device key stays valid until you remove the device in the control plane. Reinstalling the machine does not invalidate that key.
And if you use headscale, the fixed client doesn't solve everything that affects you.
What to do today
- Inventory the Linux (and open-source macOS) nodes that have Tailscale SSH enabled.
- Update them to 1.104.4 or later. Update the rest of your clients while you're at it.
- If a server can't be updated yet, set
TS_SSH_DISABLE_FORWARDING=1in the tailscaled service environment and restart it. This disables forwarding without turning off Tailscale SSH. - Review the SSH rules in your policy so only the users and devices that need access have it. Write them as device-to-device pairs: in testing, that stopped propagation.
- If you suspect any laptop or server, remove it in the admin console to invalidate its key. Then reinstall it.
- If you self-host headscale, follow its advisory channel and apply the fix when it ships.
What it means for an SME
The worrying part is less the flaw itself than where it lives. In many small companies, Tailscale is the only layer between a laptop and production. When that layer forwards as root, any compromised device becomes a master key to every server it can reach.
The immediate risk is moderate: it takes an attacker who already has a foot in the door, and nobody has reported exploitation. But the details have been public since the weekend of 24 October and the patch came afterwards, so the clock is running against you. Updating takes minutes.
The deeper lesson goes beyond this patch. Many SMEs leave their Tailscale policy as "everyone to everything" because it's convenient. This case shows the cost. What limited the damage in testing were narrow, device-to-device rules and device keys bound to hardware such as a TPM, which prevented reuse of a stolen identity. If you've never reviewed your access policy with that lens, do it this week. If you want support with that review, see our cybersecurity service.
And don't switch off Tailscale SSH by reflex. Tailscale doesn't recommend it, and the environment variable gives you a middle ground while you update.
Frequently asked questions
Is there a CVE or CVSS score?
No. The 4 bulletins covered by 1.104.4, including TS-2026-014, carry no CVE identifiers or severity scores.
Is it being exploited?
Neither Tailscale nor the Cyberdione Labs report mentions in-the-wild exploitation.
Should I disable Tailscale SSH?
No. Tailscale doesn't recommend it. If you can't update yet, disable only forwarding with TS_SSH_DISABLE_FORWARDING=1.
Sources
- BleepingComputer – Tailscale warns of SSH flaws allowing root privilege escalation
- SecurityWeek – Tailscale Rushes Patches After Uncoordinated Disclosure of 'Tailworm' Flaws
- The Hacker News – Tailscale Patches SSH Flaws That Could Let Hacked Devices Gain Root Access on Other Servers
- The Hacker News – Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers
