Active threat · 27 Oct 2026

Tailworm: are your Tailscale SSH servers exposed, and what to do before the fix

Mihai Marangoci, Gociux · October 2026 · 6 min read

If any Linux host in your tailnet runs Tailscale SSH, treat every device your policy allows to SSH into it as a possible path to root on that host until Tailscale ships a fix. Tailscale says most of the issues it has confirmed are privilege escalation: a user already authorised to connect "may be able to perform actions beyond the permissions of their configured local user, including potentially gaining elevated privileges". The quickest reduction in risk is to switch Tailscale SSH off where you don't need it and to disable SSH forwarding where you do.

What happened

On 25 October 2026 Erica Windisch of Cyberdione Labs published Tailworm, a security assessment of Tailscale 1.104.2 and headscale 0.29.5 tested in a lab between 22 and 24 October. It lists 11 findings across Tailscale SSH, tailscale serve, the DERP relay client, the experimental conn25 app connector, and headscale. The researcher described the disclosure as "reported but not coordinated": Tailscale received the report and proof-of-concept code shortly before publication, and the proof of concept is not public (The Hacker News).

The three findings that matter most for most teams are in Tailscale SSH forwarding, all rated high by the researcher:

• Local Unix-socket forwarding runs as root. An ordinary ssh -L forward made the root tailscaled process connect to a root-only socket on the target. In the lab this gave root command execution and read /etc/shadow.
• Remote forwarding can replace root-owned sockets with one the attacker controls, so local services talk to the attacker instead.
• A race condition defeats the path check meant to stop the above. The researcher chained it to capture an enrollment key and add an attacker machine to the tailnet as a trusted server. That last step only worked on tailnets without Tailnet Lock, and the race succeeded only intermittently (0 to 4% per attempt in the lab).

The report calls the chain "wormable", because a compromised server can repeat it against the next server it is allowed to reach. Other researchers have disputed that label, and nobody has publicly reproduced the findings yet. The precondition is not disputed: the attacker must already control a device your policy allows to SSH to the target, for example through a vulnerable web app, a poisoned package, phishing or stolen credentials.

Tailscale's VP of engineering said the company was already reviewing the same areas with outside specialists and had found issues it is fixing. On 26 October Tailscale published an investigation and remediation update confirming that most of what it found is privilege escalation, calling the issues serious, and saying it is "not recommending that everyone disable Tailscale SSH". Public commits in the Tailscale repository from 24 October move forwarding into a separate process that runs as the logged-in user, which addresses the root cause, but as of the latest public reports that change was not yet in a release (Fleet).

Who is exposed

• Exposed: Linux hosts with Tailscale SSH enabled (tailscale set --ssh or tailscale up --ssh), and Macs running the open-source tailscaled from Homebrew with SSH enabled, where your tailnet policy has an ssh rule that lets other devices in. According to Fleet's analysis, the socket-forwarding issue affects versions 1.98.0 to 1.104.2. Earlier versions miss the previous SSH fixes from bulletin TS-2026-004 (fixed in 1.98.9), so they are not a safe place to be either.
• Not a Tailscale SSH server: Windows clients and the macOS Tailscale app from the App Store or the standalone download.
• headscale 0.29.5: every SSH rule allows local, remote and agent forwarding and the policy can't turn it off, so treat every SSH grant there as root on the target.
• Lower risk, not zero: tailnets where each SSH rule allows exactly one source to one destination. The report found that this alone stopped the spread from host to host, though it does not stop root on the one target.

What does not help

• Mapping users to autogroup:nonroot. The forwarding ran as root regardless of the local user you log in as.
• SSH check mode. It adds a re-authentication step, but after that the session forwards normally.
• Host firewalls. They don't see Unix-socket operations on the host.

Step 1: find the hosts that run Tailscale SSH

On each Linux host, check the local setting:

tailscale debug prefs | grep -i '"RunSSH"'

Then list the ssh rules in your tailnet policy file and note which sources can reach each of those hosts, and as which users.

Step 2: turn Tailscale SSH off where nobody needs it

Make sure you have another way into the host (OpenSSH, a console, a cloud serial console) before you do this.

sudo tailscale set --ssh=false

Step 3: disable forwarding on the hosts that keep it

tailscaled reads the environment variable TS_SSH_DISABLE_FORWARDING=1 at startup. It blocks TCP, Unix-socket and agent forwarding in both directions, while ordinary interactive Tailscale SSH sessions keep working. Tailscale did not document this variable before the incident, so treat it as a stopgap until the fixed release. On a systemd host:

sudo mkdir -p /etc/systemd/system/tailscaled.service.d
printf '[Service]\nEnvironment=TS_SSH_DISABLE_FORWARDING=1\n' | \
  sudo tee /etc/systemd/system/tailscaled.service.d/50-disable-ssh-forwarding.conf
sudo systemctl daemon-reload && sudo systemctl restart tailscaled

Restarting tailscaled drops Tailscale connections for a few seconds, so don't run it over the only Tailscale session you have. If /etc/default/tailscaled sets TS_SSH_DISABLE_FORWARDING=0, remove that line, because it overrides the drop-in. Confirm the running daemon has the setting:

tr '\0' '\n' < "/proc/$(systemctl show -p MainPID --value tailscaled)/environ" | grep TS_SSH_DISABLE_FORWARDING

From an allowed device, a forward should now fail with administratively prohibited:

ssh -N -L 127.0.0.1:9000:/tmp/test.sock <user>@<host>

On a Mac with Homebrew tailscaled, the same variable goes in /etc/tailscale/tailscaled-env.txt, followed by a restart of the daemon. For containers, set it in the environment that starts tailscaled.

Step 4: tighten the tailnet

• Rewrite ssh rules so each one allows one source to one destination, instead of a group or tag to a whole tag. Never allow root as a target user unless you truly need it.
• Turn on Tailnet Lock. In the report, the final step of the chain (adding a rogue node) failed on tailnets with Tailnet Lock enabled.
• Keep node key expiry on for servers where you can, so keys copied from a compromised host stop working.
• Remove tailscale serve forwards that point at Unix sockets, especially privileged ones.
• Remove app connector permissions from devices that don't need them.

Step 5: update as soon as the fix ships

Tailscale has said it is preparing fixes. Watch the Tailscale security bulletins and install the first version listed as fixing these issues on every host running Tailscale SSH. Automatic updates help here. Keep forwarding disabled until the update is on every host, then decide whether you need it at all.

If you think a host was used

• Delete the device in the Tailscale admin console. Reimaging the machine doesn't revoke a node key that was copied off it.
• Check the admin console for devices you don't recognise, especially ones tagged as servers, and review recent auth key use.
• On the targets, check journalctl -u tailscaled for SSH sessions and forwarding requests you can't explain, and look for new Unix sockets outside their usual directories.
• Under NIS2 or GDPR, root access to a production server can be a notifiable incident. Our incident reporting clock puts the deadlines on one timeline from the moment you became aware.

The broader lesson is about blast radius. Overlay networks make it easy to let everything reach everything, and SSH rules written as "group to tag" turn one compromised laptop into a path to every server. Reviewing who can reach what, as one source to one destination, is a good use of this week whatever the final patch looks like. Our NIS2 pre-assessment covers access control and supply-chain areas if you need to show that review to an auditor.

Questions

Should I disable Tailscale SSH completely?

Not necessarily. Tailscale is not recommending that everyone disable it. Turn it off where nobody uses it, disable forwarding with TS_SSH_DISABLE_FORWARDING=1 where you keep it, and narrow the SSH rules until a fixed version is installed.

Is there a CVE or a patched Tailscale version for Tailworm?

Not at the time of writing (27 October 2026). Tailscale confirmed the privilege-escalation issues on 26 October and is preparing fixes; check its security bulletins for the fixed version.

Can someone exploit Tailworm from the internet?

Not directly. The attacker first needs control of a device that your tailnet policy allows to connect to the target over Tailscale SSH. From there, the flaws can turn that access into root on the target.

Sources

• Tailworm: security assessment of Tailscale v1.104.2 and headscale v0.29.5 (findings, preconditions, lab results, mitigations)
• Tailscale: Tailscale SSH investigation and remediation update (26 October 2026)
• The Hacker News: unpatched Tailscale SSH flaws (Tailscale statements, disclosure timeline, patch status)
• Fleet: what to do about Tailscale SSH before the fix ships and guide to disabling forwarding (affected versions, TS_SSH_DISABLE_FORWARDING, verification)
• Tailscale security bulletins (TS-2026-004, fixed versions)
• Tailscale SSH documentation

This is a developing story. Check Tailscale's security bulletins for the fixed version before you re-enable forwarding.