Tailscale SSH Vulnerability: Root Risk, Fixes and What to Do

Last updated: 26 October 2026. Sources are listed at the end.

On 25 October 2026, The Hacker News reported a new Tailscale SSH vulnerability set that could let one hacked device reach root on other servers in the same tailnet. The research, called “Tailworm”, comes from Erica Windisch of Cyberdione Labs. At the time of writing there is no patch, no CVE and no Tailscale security bulletin for it.

However, this is not the only Tailscale SSH vulnerability of 2026. Tailscale already fixed two separate root-access bugs in July, TS-2026-006 and TS-2026-009. Many news posts mix these up, so this guide separates what is fixed from what is still open.

If your team uses Tailscale SSH to reach Linux servers, read on. We cover what each issue does, how to check your version, how to tighten your policy file, and what to do while the new findings remain unpatched.

The short answer

• Update every Tailscale node to the latest release (1.104.2 on 26 October 2026). This closes the July bugs but not the new Tailworm findings.
• Audit the "ssh" section of your tailnet policy file. Remove root from users, replace broad tag-wide or member-wide rules with one-source-to-one-destination rules, and use "action": "check" for humans.
• On servers that do not need Tailscale SSH, turn it off with tailscale set --ssh=false and use OpenSSH over the tailnet instead. Confirm you have another way in first.
• Turn on Tailnet Lock and key expiry, and remove any device you do not recognise from the admin console.
• Check servers for unexpected usernames, unexpected root-owned sockets and odd SSH sessions.

What happened: two different sets of issues

The July 2026 bugs (fixed)

First, the older Tailscale SSH vulnerability pair. Both needed an attacker who was already allowed to use Tailscale SSH on a Linux host as a normal user. In other words, the policy said “non-root users only”, typically via autogroup:nonroot, and the bug got around that rule.

• TS-2026-006 (published 11 June 2026): Tailscale SSH accepted numeric user IDs. The policy check only looked for the name root, so logging in as user 0 gave a root session. Tailscale credits Tim Hoffman (GM).
• TS-2026-009 (published 13 July 2026): Tailscale SSH accepted usernames that start with a dash. The name was handed to the getent tool, which read it as a command-line option. As a result, a username of -i made getent print the password database, and the session opened as root. Tailscale credits Anthropic and Ada Logics.

In addition, TS-2026-004 (3 June 2026) let SSH Unix-socket forwarding follow a symlink to a privileged socket, such as the Docker socket. Tailscale credits Tim Sageser (dtrsecurity).

The bulletins say all three are fixed in Tailscale 1.98.9 or newer, released 14 July 2026. However, the Tailscale changelog shows that 1.98.10 (28 July 2026) added further checks for TS-2026-006 and TS-2026-004. Meanwhile, FreeBSD’s VuXML entry marks every version below 1.98.10 as affected. Therefore, treat 1.98.10 as the safe floor. No CVE IDs were assigned, and none of these bulletins report exploitation in the wild.

One correction for anyone tracking advisories: GHSA-vfgq-g5x8-g595 is not TS-2026-009. That GitHub advisory is CVE-2023-28436, a 2023 FreeBSD group-ID bug fixed in 1.38.2.

The Tailworm findings (unpatched)

The new report lists 11 findings. Only some of them are a Tailscale SSH vulnerability. Windisch tested Tailscale 1.104.2 and headscale 0.29.5 in a lab between 22 and 24 October 2026. Several findings cover features other than SSH, such as app connectors, tailscale serve and the DERP relay client. Here we focus on SSH.

The SSH problem is Unix-socket port forwarding. According to the report, the forwarding runs with root rights. Because of that, a user with one approved device and one SSH rule could do the following:

1. Use ssh -L so the root Tailscale process connects to a root-only socket.
2. Use ssh -R to replace a root-owned socket with their own.
3. Win a timing race that defeats the path safety check, then capture an enrollment key so a rogue machine can join the tailnet.

The researcher says forwarding is on by default and calls the chain “wormable”. Some researchers dispute that label, as The Hacker News notes. Also, the last step did not complete in tailnets with Tailnet Lock enabled.

What is confirmed and what is reported

So far, Tailscale has not confirmed the specific technical claims. Shaver said the company had received the report, was already looking at the same areas with outside specialists, and was working on fixes. He also wrote that Tailscale is “not recommending that everyone disable Tailscale SSH”. Meanwhile, the researcher describes the release as “reported but not coordinated”, which drew criticism online.

Am I affected by the Tailscale SSH vulnerability?

Your exposure depends on which issue you look at. Use this table as a quick guide.

Tailscale SSH servers run on Linux, and on macOS only with the open-source tailscaled build. Windows and phones can be SSH clients but not Tailscale SSH servers. Even so, a hacked laptop is exactly the “one approved device” the Tailworm chain needs.

Check the version on each node. The --daemon flag also prints the running daemon version.

tailscale version --daemon
tailscale version --upstream

For a fleet, this small script flags any node below the current release. We tested it with shellcheck and with fake version strings.

#!/usr/bin/env bash
min="1.104.2"
cur="$(tailscale version 2>/dev/null | head -n1)"
if [ -z "$cur" ]; then echo "tailscale not found"; exit 1; fi
if [ "$(printf '%s\n%s\n' "$min" "$cur" | sort -V | head -n1)" = "$min" ]; then
  echo "OK: $cur (>= $min)"
else
  echo "UPDATE: $cur is older than $min"
fi

Next, list which servers actually run the Tailscale SSH server. Each one was switched on with tailscale set --ssh, so check your provisioning scripts and the admin console Machines page.

Fixing the Tailscale SSH vulnerability step by step

Step 1: Update Tailscale everywhere

These commands come from Tailscale’s update documentation. We could not install Tailscale in our sandbox, so we have not run them.

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

# RHEL 8+, CentOS Stream, Fedora
sudo dnf update tailscale

# CentOS 7, Amazon Linux 2
sudo yum update tailscale

# Many Linux installs (v1.36+), and Windows
sudo tailscale update

# Turn on automatic updates
sudo tailscale set --auto-update

On macOS, App Store builds update themselves, and the standalone app has an auto-update switch in its settings. On Windows, run the latest installer or tailscale update. For Docker, pull tailscale/tailscale:stable and recreate the container. Note that the auto-update setting does not persist across container restarts.

Step 2: Audit the ssh section of your policy file

Open Access controls in the admin console. Then review every entry under "ssh" with these questions:

• Does any rule list root in users? Remove it unless a named admin truly needs it.
• Does any rule use autogroup:nonroot? That was the very control the July bugs bypassed, so update first. After that, prefer named accounts like deploy.
• Is src a broad group or tag, and dst a whole tag? Instead, the researcher suggests one source and one destination per rule.
• Is the action accept? For people, use "action": "check" so Tailscale asks them to re-authenticate. Note that check mode adds a barrier but does not fix the forwarding flaw.

A tighter rule looks like this:

{
  "ssh": [
    {
      "action": "check",
      "src": ["group:ops"],
      "dst": ["tag:prod-db"],
      "users": ["deploy"],
      "checkPeriod": "1h"
    }
  ]
}

To scan a large policy, copy it into policy.json, remove comments and trailing commas, and run this jq filter. We tested it on a sample file.

jq -r '.ssh[] | select(.action=="accept") | select((.users|index("root")) or (.users|index("autogroup:nonroot"))) | "REVIEW: \(.src|join(",")) -> \(.dst|join(",")) as \(.users|join(","))"' policy.json

Also, the report says forwarding can be set to denied per rule on the hosted service. Tailscale’s public policy docs do not name that field yet, so check your editor’s autocomplete or ask Tailscale support. On headscale 0.29.5, forwarding cannot be turned off. Consequently, treat every headscale SSH grant as root access.

Step 3: Turn off Tailscale SSH where you can

Until a fix ships, the safest choice for sensitive servers is plain OpenSSH over the tailnet IP. First make sure OpenSSH works with key-only login. Then run:

sudo tailscale set --ssh=false

Tailscale’s docs warn that you may lock yourself out if this was your only way in, so keep a console session open.

Step 4: Shrink who can reach your servers

• Enable Tailnet Lock (tailscale lock status shows its state). It stopped the rogue-node step in the lab.
• Keep node key expiry on for servers, and use device approval so new machines cannot join silently.
• Add srcPosture conditions to SSH rules so only managed, up-to-date devices qualify.
• Remove app connector rights and tailscale serve forwards to Unix sockets that you do not need.
• If a device is compromised, delete it in the admin console. Reimaging alone does not revoke copied keys.

Was I already compromised?

No public indicators of compromise exist for any Tailscale SSH vulnerability covered here. Therefore, look for signs of the techniques instead. These commands are read-only.

# Usernames that start with a dash, are all digits, or have UID 0 but are not root
sudo awk -F: '$1 ~ /^-/ || $1 ~ /^[0-9]+$/ || ($3 == 0 && $1 != "root")' /etc/passwd

# Root-owned sockets in user-writable places
sudo find /tmp /run/user /home -xdev -type s -user root -ls 2>/dev/null

# Recent Tailscale SSH activity
sudo journalctl -u tailscaled --since "2026-06-01" --no-pager | grep -i "ssh" | tail -n 50
last -n 30

Then compare the Machines list in the admin console with your inventory. Look for unknown devices, new tags and unexpected auth keys. If you use SSH session recording, replay root sessions with asciinema play. Tailscale has marked that recorder deprecated, with support ending in August 2027.

The researcher also suggests auditd rules that watch socket unlink, bind and chmod calls in /tmp, home directories and /run/user.

India angle

We found no CERT-In advisory on these issues yet. However, if you confirm an intrusion, entities covered by CERT-In’s April 2022 Directions must report it within six hours. Also, from May 2027 DPDP Rule 7 will require a detailed report to the Data Protection Board within 72 hours when personal data is exposed.

Quick checklist

• ☐ Every node runs Tailscale 1.104.2 or later (at least 1.98.10)
• ☐ Auto-update enabled where possible
• ☐ No root in SSH users without a clear reason
• ☐ autogroup:nonroot rules replaced by named accounts where practical
• ☐ SSH rules narrowed to one source and one destination
• ☐ Humans use "action": "check"
• ☐ Tailscale SSH disabled on servers that can use OpenSSH
• ☐ Tailnet Lock, key expiry and device approval on
• ☐ Unused app connectors and socket serve forwards removed
• ☐ /etc/passwd, sockets and SSH logs reviewed
• ☐ Watching Tailscale’s bulletins page for a Tailworm fix

If you want a second pair of eyes on your servers, our Linux server hardening audit covers SSH access paths, including mesh VPNs like Tailscale. You can also work through our free Linux server hardening checklist. For another SSH trust issue this week, see our guide on Tor relays and SSH host key warnings.

Sources

• Tailscale security bulletins (TS-2026-004, TS-2026-006, TS-2026-009)
• Tailscale changelog (1.98.9, 1.98.10, 1.104.2)
• The Hacker News: Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers
• Tailworm report by Erica Windisch, Cyberdione Labs
• FreeBSD VuXML 272a2772-8367-11f1-82b9-901b0e9408dc
• Vincent Schmalbach: Tailscale SSH leading-dash root bug
• Tailscale SSH documentation
• GitHub advisory GHSA-vfgq-g5x8-g595 (CVE-2023-28436)

Running Linux servers in production? Our Linux server hardening & security audit checks configuration, patching, SSH and logging. You can also use our free Linux server hardening checklist, or contact us.