Tailscale SSH Vulnerability (Tailworm): Update to 1.104.4 in 7 Steps

Updated 29 October 2026. Tailscale released version 1.104.4 on 28 October 2026 to fix the Tailworm vulnerabilities in Tailscale SSH and tailscale serve; this guide shows who is affected and how to update.

The Tailscale SSH vulnerability reported as Tailworm let a user who is already allowed to connect over Tailscale SSH act beyond the local account they log in as. The most serious bug, TS-2026-014, ran SSH Unix socket forwarding as root, so a permitted peer could reach root-only sockets such as the Docker socket or the tailscaled local API. Tailscale fixed it, and three related bugs, in Tailscale 1.104.4.

This is not an open door for strangers. Tailscale says the bugs do not let an unauthenticated attacker connect to arbitrary Tailscale SSH servers; an attacker first needs a foothold on a device that your tailnet policy already allows to SSH in. If you use Tailscale SSH or tailscale serve, update every node to 1.104.4 or later, and set TS_SSH_DISABLE_FORWARDING=1 on any host you cannot update yet.

Related: Discord Server Web Pages: What Admins Must Set Before November 16

Tailscale Tailworm at a glance

What is Tailworm?

Tailworm is the name Cyberdione Labs gave to its security assessment of the Tailscale 1.104.2 client and the self-hosted headscale 0.29.5 control server, tested from 22 to 24 October 2026. The report lists 11 findings. SecurityWeek reported that six were rated high severity and that four of those concern Tailscale SSH. According to the same report, the SSH flaws led in lab tests to root access on target servers and to theft of keys that could add rogue devices to the network, and the researchers showed they were wormable.

Tailscale's account is narrower. Its VP of Engineering, Mike Shaver, says the problems concern what an already authorized session can do, and describes the behavior as lateral movement within connections your policy permits, not a self-replicating worm. Both sides agree on the fix: update the client.

The disclosure was rushed. Tailscale says concerns about Tailscale SSH were circulating on social media on 23 October, that it received the report on the morning of 24 October, and that the researcher published it about two hours later, before fixes were ready. Tailscale posted an investigation update and the four bulletins on 26 October, then shipped 1.104.4 on 28 October.

What do the four Tailscale bulletins fix?

In 1.104.4, SSH socket forwarding runs as the authenticated user instead of root, session memory is capped and freed on disconnect, Serve checks backend paths again on every connection, and capabilities come from each request. Tailscale says two other Serve and Funnel findings work as designed. A finding in the next-generation app connector, conn25, affects a feature that has not been released, and today's stable app connectors are not affected.

Am I affected by the Tailscale SSH vulnerability?

• You run Tailscale SSH on any node, meaning you ran tailscale set --ssh there and your policy has ssh rules: yes, update that node.
• You use tailscale serve with Unix socket backends, or with TLS and several mounts: yes.
• You only use Tailscale as a VPN, with no SSH server and no Serve: the four bulletins do not apply, but updating is cheap and keeps you current.
• You run headscale: the fixed bugs live in the client, so headscale users need 1.104.4 on their nodes too. The headscale v0.29.6 release from 24 October does not mention Tailworm, and the Tailworm report still listed headscale's own memory issue as pending on 28 October.

An attacker still needs a starting point: a compromised laptop, server or account that your tailnet already lets SSH into the target. That is why the policy steps below matter as much as the update.

How to fix the Tailscale SSH vulnerability: 7 steps

1. Find the nodes that need the update

In the admin console, open the Machines page and look at the Version column. Tailscale shows a red arrow when a security update is available and a gray arrow for a normal update. Use the Version filter and choose Update available to list every node that is behind. Start with servers that accept Tailscale SSH and anything running tailscale serve.

2. Check the version on a node

tailscale version
tailscale version --upstream

The first command prints the installed version. The --upstream flag shows the latest release published on pkgs.tailscale.com, so you can compare. You want 1.104.4 or later.

3. Update Linux servers

On Ubuntu and Debian with Tailscale 1.36 or later, the built-in updater is the simplest route:

sudo tailscale update

Otherwise, use the package manager:

# Ubuntu or Debian
sudo apt-get update
sudo apt-get install tailscale

# RHEL 8, CentOS Stream 9 or Fedora
sudo dnf update tailscale

Run tailscale version again afterwards to confirm the new number.

4. Update desktops, containers and NAS devices

• Windows: run the installer over the existing install, or run tailscale update.
• macOS: the Mac App Store version updates through the App Store; the standalone app has an automatic update setting.
• iOS and Android: update from the App Store or Play Store.
• Docker: the tailscale/tailscale:stable tag follows stable releases, so pull it again and recreate the container. If you pin a version tag, move it to 1.104.4 or later.
• Synology: update the Tailscale package in DiskStation Manager, or schedule automatic updates there.

5. If you cannot update yet, turn off SSH forwarding

Tailscale's bulletin for TS-2026-014 gives a stopgap: set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart the service. That disables forwarding but keeps Tailscale SSH logins working, and Tailscale says it mitigates several of the more serious findings. On a Linux host with systemd, a drop-in override is a clean way to add the variable:

sudo systemctl edit tailscaled

In the editor that opens, add these lines and save:

[Service]
Environment="TS_SSH_DISABLE_FORWARDING=1"

Then restart the daemon:

sudo systemctl restart tailscaled

This stops SSH forwarding, such as ssh -L and ssh -R tunnels, through Tailscale SSH on that host. Once the node runs 1.104.4, you can remove the override if you need forwarding back.

6. Tighten your Tailscale SSH rules

Tailscale and the researchers both recommend reviewing who can SSH where. Replace broad rules that let a whole group or tag reach many machines with narrower pairs, avoid rules that log in as root, and use check mode on sensitive hosts. Check mode makes the user sign in again through your identity provider, which can trigger multi-factor authentication, before the connection opens. An illustrative rule for production servers:

"ssh": [
  {
    "action": "check",
    "src": ["group:sre"],
    "dst": ["tag:prod"],
    "users": ["autogroup:nonroot"],
    "checkPeriod": "1h"
  }
]

autogroup:nonroot allows any user on the host except root. checkPeriod sets how often the user must sign in again for this rule, from one minute to 168 hours; without it, one check lasts 12 hours.

7. Turn on auto-updates and review your devices

sudo tailscale set --auto-update

That enables automatic client updates on a Linux node. The Device management page in the admin console has an Auto-update new devices setting, but it only applies to devices added from then on, so existing nodes need the command above or their own setting. If you suspect a node was misused, remove it in the admin console: the Tailworm report warns that reimaging a machine does not revoke node keys an attacker may have copied.

Should I turn off Tailscale SSH?

Tailscale says it is not recommending that everyone disable Tailscale SSH, and with 1.104.4 installed the reported forwarding bugs are fixed. If you barely use it on a host, switching it off reduces exposure:

sudo tailscale set --ssh=false

Tailscale warns that you should have another way to reach the machine before you do this, or you may lock yourself out. To block every incoming tailnet connection to a device, including Tailscale SSH, tailscale set --shields-up is the stronger option.

A busy month for anyone who runs their own servers

Tailworm landed in the same fortnight as the PHP2Shell flaws, the Node.js October security release and the GitLab 19.5.1 critical patch. Tailscale's previous release, 1.104.2 on 21 October, had already distrusted the compromised certificates from the eMudhra CA incident under bulletin TS-2026-013, so nodes still on older versions are behind on two fixes. If patching every tool on every server is becoming a weekly job, our web application security guide and our comparison of VPS, serverless and managed hosting can help you decide what to run yourself.

If your team wants a second opinion on its Tailscale SSH rules or an update routine that does not rely on memory, get in touch with a short description of your setup.

Tailscale Tailworm FAQ

Is Tailscale still safe to use after Tailworm?

For most teams, yes, once clients run 1.104.4 or later. The bugs did not let outsiders connect to your devices; they let a user or device you had already authorized do more than intended through Tailscale SSH or Serve. Update every node, keep auto-updates on, narrow your SSH rules and use check mode for sensitive servers. Those steps also limit the damage from any future bug of this kind.

Do I need to update Tailscale if I do not use Tailscale SSH?

The four Tailworm bulletins cover Tailscale SSH and tailscale serve, so a node that runs neither is not exposed to them. Updating is still sensible. Version 1.104.2 also blocked the compromised eMudhra certificates, and staying on the current release keeps every node ready for the next fix. With auto-updates turned on, it takes no effort at all.

What does TS_SSH_DISABLE_FORWARDING do?

It is an environment variable for the tailscaled service. When set to 1, Tailscale SSH stops performing forwarding, while normal SSH logins keep working. Tailscale lists it as the mitigation for TS-2026-014 and says it covers several of the more serious findings. Set it through a systemd override on Linux, restart tailscaled, and remove it after updating if you need forwarding.

Does Tailworm affect headscale?

Yes, indirectly. The researchers tested headscale 0.29.5, but the SSH and Serve bugs live in the Tailscale client that headscale users run on every node, so those nodes need 1.104.4. Before the client fix, the report advised treating every headscale SSH grant as root-equivalent, because headscale 0.29.5 offers no way to disable SSH forwarding. The latest headscale release, v0.29.6 from 24 October, does not mention these issues.

Was the Tailscale SSH vulnerability exploited in the wild?

No exploitation had been reported as of 29 October 2026. SecurityWeek noted that neither Tailscale nor the Tailworm report mentions attacks in the wild. The details are public, though, and the report describes working attack paths, so expect attempts against nodes that stay on 1.104.2 or older. Update first, then check the Machines page for devices you do not recognize.

Why was Tailworm made public before a fix was ready?

Cyberdione Labs published its report about two hours after sending it to Tailscale, according to Tailscale's timeline, while fixes were still being built. SecurityWeek reported that the researchers argued fast public awareness would speed up remediation, and that the move drew criticism. Tailscale says it was already investigating related issues with outside specialists. The result was a few days in which details were public and no patch existed.

Sources

• Tailscale security bulletins: TS-2026-013 to TS-2026-017
• Tailscale changelog: v1.104.4 (28 October 2026) and v1.104.2
• Tailscale blog: Tailscale SSH, findings and fixes (28 October 2026)
• Tailscale: Tailscale SSH investigation and remediation update
• Tailscale docs: Update Tailscale
• Tailscale docs: Tailscale CLI
• Tailscale docs: Tailscale SSH and check mode
• Tailscale docs: tailscaled daemon
• Cyberdione Labs: Tailworm security assessment of Tailscale 1.104.2 and headscale 0.29.5
• BleepingComputer: Tailscale warns of SSH flaws allowing root privilege escalation (27 October 2026)
• SecurityWeek: Tailscale rushes patches after uncoordinated disclosure of Tailworm flaws (27 October 2026)
• headscale releases on GitHub (v0.29.6, 24 October 2026)