Tailworm: Unpatched Tailscale SSH Flaws

• You run Tailscale SSH on servers

  Linux, or macOS with the open-source tailscaled, and your policy has ssh rules

  Act now

  Treat every Tailscale SSH grant as root access to that server until a fix ships. Turn it off where you do not need it and narrow the rest. Until a fix ships

• You run headscale

  The self-hosted, open-source control server

  Act now

  SSH forwarding cannot be turned off on headscale 0.29.5, so every SSH grant is root access. Keep the server off the open internet. headscale

• You use app connectors

  Especially through the Tailscale Kubernetes operator

  Update needed

  Remove connector entitlements nobody needs, and limit where connector hosts can send traffic, for example with a default-deny egress policy in Kubernetes.

• You forward a port to a Unix socket with tailscale serve

  tailscale serve --tcp <port> unix:<path>

  Update needed

  Remove any forward to tailscaled’s own socket or another privileged socket. It can hand control of the device to other machines on your tailnet.

• You use Tailscale only as a network

  No Tailscale SSH, connectors or serve forwards

  Low risk

  Not affected by the main findings. Turn on auto-update so the fixed release arrives without anyone remembering to install it.

• You use normal OpenSSH over Tailscale

  sshd on the server, Tailscale only carrying the traffic

  Protected

  Not affected. Tailscale SSH does not change sshd or authorized_keys, and the researcher found OpenSSH clean for this class of flaw.

1. 01

   Find every server running Tailscale SSH

   Read the ssh section of your tailnet policy, then check each server. How to check
2. 02

   Turn it off where you do not need it

   Many teams switched it on fleet-wide for convenience. Every server that does not need it is one less route to root.
3. 03

   Narrow the SSH rules you keep

   One group to one set of servers, never a whole tag or everyone. Treat each rule as granting root, because limiting logins to non-root users does not stop these flaws. Example rule
4. 04

   Consider turning off SSH forwarding on servers

   The main finding needs forwarding. An undocumented server setting turns it off, at the cost of breaking tools that tunnel over SSH.
5. 05

   Turn on auto-update and watch for the fix

   The fixed release will be announced in Tailscale’s security bulletins. Auto-update gets it onto servers without anyone remembering.

The policy file

Open your tailnet policy in the admin console and read the ssh section. Each rule there lets the devices or people in src log in to the devices in dst. Rules that use a whole tag, autogroup:member or a large group as the source are the ones to narrow first.

Each server

# On each Linux server: is Tailscale SSH turned on, and which version runs?
tailscale debug prefs | grep RunSSH      # "RunSSH": true means it is on
tailscale version

Tailscale SSH can only run as a server on Linux and on macOS with the open-source tailscaled, according to Tailscale’s documentation. Other platforms cannot accept logins through it.

The admin console

The Machines page can filter for devices with an update available, and shows each device’s version. Use it to see which devices will need the fixed release, and which have auto-update turned on.

1. Turn Tailscale SSH off where you do not need it

# Turn Tailscale SSH off on a server that does not need it.
# Make sure you have another way in first, or you can lock yourself out.
sudo tailscale set --ssh=false

Tailscale’s own warning: make sure you have another way to log in before turning it off. Normal OpenSSH is not affected by these flaws.

2. Make every SSH rule one-to-one

In the researcher’s lab, rules that let one small group reach one set of servers were the only control that stopped the attack spreading. Do not use a whole tag or everyone as the source, and do not grant root or accounts with passwordless sudo. According to the researcher, check mode does not help here, because it only gates the login, not what happens inside the session.

"ssh": [
  {
    "action": "check",
    "src": ["group:db-admins"],
    "dst": ["tag:prod-db"],
    "users": ["dbadmin"]
  }
]

3. Turn off SSH forwarding on the server

The root escalation works through SSH forwarding. Tailscale’s policy file has no documented setting to turn it off. Its code does: a server environment setting that, in 1.104.2, rejects every kind of SSH forwarding. It is read when tailscaled starts, and Tailscale’s Linux service loads it from /etc/default/tailscaled.

# Undocumented setting found in Tailscale's code. Test before relying on it.
echo 'TS_SSH_DISABLE_FORWARDING=true' | sudo tee -a /etc/default/tailscaled
sudo systemctl restart tailscaled        # ends any open Tailscale SSH sessions

Tailscale does not document or endorse this setting. It also breaks anything that tunnels over SSH, such as VS Code Remote SSH or database tunnels. Test it on one server first, and confirm with ssh -L that forwarding is refused.

headscale

On headscale 0.29.5, forwarding is granted on every accepted SSH session and cannot be turned off in the policy. Treat every headscale SSH grant as root access, use the server setting above where you can, and keep the headscale server off the open internet. headscale 0.29.6 does not address these findings.

App connectors and tailscale serve

• Remove connector entitlements nobody uses, and limit where connector hosts can send traffic. In Kubernetes, a default-deny egress policy on the connector’s namespace does this.
• Remove any tailscale serve --tcp forward that points at a Unix socket, especially /run/tailscale/tailscaled.sock.

These follow the researcher’s interim mitigations, except where noted. Tailscale has not yet published its own.

Why the main finding matters

Tailscale SSH runs inside tailscaled, which runs as root, and lets a user forward Unix sockets between their machine and the server. The researcher found that tailscaled does that forwarding as root, not as the logged-in user. An ordinary user can therefore reach sockets only root should reach, such as the Docker socket, and from there take over the server.

This is the same code an earlier bulletin, TS-2026-004, fixed in 1.98.9 by checking where a socket path really leads. Tailworm’s race gets around that check by changing the path between the check and its use.

What an attacker needs first

This is not an attack from the internet. The attacker first needs a foothold on a device that your SSH rules allow to log in, for example through a compromised laptop, a vulnerable web app or a malicious dependency. The report’s point is that Tailscale SSH then turns that one foothold into root on every server the rules reach.

• Configuration audit log. Look for unexpected devices joining, auth keys created or used outside change windows, and policy edits. Tailscale keeps these for 90 days on every plan. Audit logging
• On servers. The researcher suggests auditing Unix socket creation, deletion and permission changes in /tmp, home folders and /run/user, and alerting on bursts of renames there.
• Session recordings, if you use them, show what was typed into a terminal. A session that only forwards sockets leaves nothing to watch. Session recording

If you find signs of a compromise, the researcher advises deleting the device in the admin console rather than only rebuilding it, because a rebuild does not revoke a device key an attacker has already copied. Then rotate auth keys and review recent policy changes.

An open Tailscale change says that today, revoking access in the policy does not close sessions that only forward traffic. Until it ships, restart tailscaled or delete the device to be sure an attacker is cut off. tailscale/tailscale #21944

• In progress. Tailscale has merged several Tailscale SSH hardening changes and the fix for the serve permissions race, and has opened a change that has sockets opened by a process running as the logged-in user, never as root. That is the fix the researcher recommends for the main finding. None of this is in a release yet.
• Not yet announced. Tailscale has published no bulletin, CVE or affected version range. Socket forwarding first shipped in 1.98.0, so earlier versions are unlikely to have the main finding, but Tailscale has not confirmed this.
• When it lands. Install the fixed version on every server running Tailscale SSH first. Updating restarts tailscaled, which ends open Tailscale SSH sessions.

Auto-update, set per device with tailscale set --auto-update, usually installs a release about a week after it ships, sooner for important security fixes. It does not survive restarts in containers. Tailscale update docs

No attacks have been reported, and no Tailscale flaw is in the CISA KEV catalog. The report describes the attacks in detail, but the researcher’s full reproduction kits are not published. She says the report was sent to Tailscale but not coordinated.

1. 2026-04-07

   2026-04-07

   Tailscale SSH gains Unix socket forwarding, the code behind the main finding. It first ships in 1.98.0.

   tailscale/tailscale #19006

2. 2026-10-21

   2026-10-21

   Tailscale releases 1.104.2, the version the researcher tested. It is still the newest release.

   Tailscale changelog

3. 2026-10-23

   2026-10-23 · 23:35 UTC

   The first related Tailscale SSH hardening change appears in Tailscale’s public code.

   tailscale/tailscale

4. 2026-10-25

   2026-10-25 · 00:39 UTC

   Tailscale merges a fix for the tailscale serve permissions race. It is not yet in a release.

   tailscale/tailscale #21931

5. 2026-10-25 · 00:59 UTC

   The Tailworm report is shared publicly. The researcher says it was reported to Tailscale but not coordinated.

   Hacker News

6. 2026-10-25 · 01:38 UTC

   A Tailscale engineer says the team has been working on it and more details will follow.

   Hacker News

7. 2026-10-25 · 17:24 UTC

   Tailscale opens a change that moves SSH forwarding out of the root process, the fix the researcher recommends.

   tailscale/tailscale #21942

Evidence to keep: the date you assessed it, the list of servers with Tailscale SSH and what you decided for each, the policy file before and after, any server settings you changed, and the date you installed the fixed release.

For how these controls work day to day, see our guides to ISO 27001 vulnerability management, SOC 2 vulnerability management and SOC 2 third-party risk.

• Tailworm report, Erica Windisch, Cyberdione LabsAll eleven findings, the lab results, severities and interim mitigations.
• Tailscale SSH documentationSupported platforms, how to turn it off, and how SSH rules work.
• Tailscale policy file syntaxThe fields an SSH rule accepts.
• Tailscale security bulletinsWhere the fix will be announced. Includes TS-2026-004 on the same forwarding code.
• Tailscale releasesThe newest version, to compare against the fixed release.
• tailscale/tailscale #21942The open change that moves SSH forwarding out of the root process.
• Tailscale engineer on Hacker NewsTailscale’s first public response, and the peer-list point.
• Researcher on Hacker NewsWhich findings matter most, in the researcher’s view.
• Cybersecuritynews, 25 October 2026The news report that brought this to wide attention.