Tailscale Confirms Serious Tailscale SSH Privilege-Escalation Flaws, Patch Pending: What to Do Now

TL;DR: Tailscale says it has found “serious security issues” in Tailscale SSH, the feature that lets devices on a Tailscale network log in to each other without SSH keys. Most are privilege escalation: someone already allowed to connect over Tailscale SSH may be able to act beyond the permissions of the local user they log in as, “including potentially gaining elevated privileges.” The flaws were made public in a report called Tailworm, whose researchers tested Tailscale v1.104.2. There’s no fixed version and no CVE yet; Tailscale is targeting a patched client “by the end of Tuesday 27 October” (Tailscale didn’t give a time zone), subject to testing. If you use Tailscale SSH, turn off SSH forwarding now with one setting, tighten who can SSH where, and update as soon as the patch lands.

What happened

Erica Windisch of Cyberdione Labs published the Tailworm report, a security review of the open-source Tailscale client v1.104.2 and of headscale v0.29.5, the self-hosted control server some teams run instead of Tailscale’s own service. The researchers say they tested from October 22 to 24, 2026, in their own lab, and reproduced each finding on unmodified, released software. On publishing before a patch, the report says it is the researcher’s opinion that “infrastructure is vulnerable today.”

The most serious findings are in how Tailscale SSH handles forwarding of local sockets (the ssh -L and ssh -R options). The researchers say the Tailscale agent, which runs with full system rights, does that work itself, so an ordinary user session can reach or replace sockets that only system services should touch. In their lab, that led to code running as root and to capturing a key used to add devices, which they then used to join a rogue device to the network. The report also covers app connectors, a denial-of-service bug in headscale, and the tailscale serve feature. The researchers rate many of the 11 findings High.

The attacker first needs a foothold on one device that is allowed to SSH to others, such as a hacked web app or a malicious package. In the lab, the researchers say, that one foothold spread automatically to every device the SSH rules allowed, “under a second per hop,” with no passwords. Rules that let one named device reach one named target were “the single control that stopped” the spread.

In its own update, dated October 26, Tailscale says “most of the Tailscale SSH issues we’ve identified concern privilege escalation” and calls them “serious security issues.” It says exploitation depends on the permissions of the connecting user or device and the system’s setup, and that it’s still checking which configurations are affected. Its engineers have fixes for most of the issues and are testing them. The researchers say fixes for several findings have landed in Tailscale’s public code, two of them merged on October 27, but they hadn’t shipped in a numbered release. At our check, the newest release on GitHub was still v1.104.2, from October 21. Tailscale says it will publish a security advisory with the affected versions and configurations once the patch ships.

Why it matters

Tailscale is a common way for small teams to reach office servers, home labs and cloud machines without opening ports, and Tailscale SSH is popular because it removes SSH key management. These flaws hit that model where it hurts: one compromised laptop or server that is allowed to SSH elsewhere could become root on the machines it can reach, according to the researchers.

The good news is that the main fix you can make today is one setting, and Tailscale itself says it “mitigates several of the more serious findings.” Teams on headscale should pay the most attention: the researchers say forwarding can’t be switched off per rule on headscale v0.29.5, so every SSH grant there should be treated as root access until fixed. This is the same lesson as the OpenAI Codex AGENTS.md attack and the exploited PHP2Shell flaws: attackers rarely stop at the first machine, so limit what each one can reach. Our Security hub tracks the rest.

What to do now

1. Find out if you use Tailscale SSH. In the Tailscale admin console, check your access policy for SSH rules, and check which devices have Tailscale SSH turned on. If you don’t use it, the main findings don’t apply to you, but keep Tailscale up to date.
2. Turn off SSH forwarding. On each device that accepts Tailscale SSH, set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart the service. Tailscale says this “disables SSH forwarding without disabling Tailscale SSH entirely.” On Linux installs that use Tailscale’s standard systemd service, our suggestion is to add the line TS_SSH_DISABLE_FORWARDING=1 to /etc/default/tailscaled, the environment file that service reads, then run sudo systemctl restart tailscaled.
3. Tighten your SSH rules. Tailscale’s advice is to limit access to the users and devices that need it. Our advice, following the researchers: replace rules that let a whole group or tag SSH into many servers with rules naming one source and one destination. Avoiding rules that log in as root is still good practice, but the researchers say it doesn’t stop these flaws, which work from ordinary user accounts.
4. Remove risky serve settings. The researchers advise removing any tailscale serve TCP forward that points at a Unix socket on the device.
5. Patch as soon as Tailscale ships. Tailscale says it’s targeting a patched client “by the end of Tuesday 27 October” and will link its advisory from its update page. Our advice: turn on automatic updates where you can, and update servers that accept Tailscale SSH first.
6. Clean up devices. Turn on key expiry for servers, as the researchers advise, and remove devices you don’t recognize from the admin console. The researchers note that reimaging a hacked machine doesn’t revoke keys copied from it; only removing the device from the network, or the key expiring, does.

Updates

• Oct 27, 2026, 9:27 p.m. Manila: First published. No patched Tailscale release, security advisory or CVE at our check. We’ll add a dated note when Tailscale ships the fix and names affected versions.

Sources & method

Sources

• Tailscale, “Tailscale SSH: Investigation and remediation update” (October 26, 2026)
• Tailworm report by Erica Windisch, Cyberdione Labs (updated October 27, 2026)
• Tailscale releases on GitHub (latest v1.104.2, October 21, 2026)
• Tailscale’s systemd service file for tailscaled (environment file path)
• Tailscale security bulletins (no bulletin for these findings at our check; latest TS-2026-013)
• Tailscale docs, “Tailscale SSH”

Method. Last checked October 27, 2026, at 9:27 p.m. Manila time (13:27 UTC). What Tailscale says, the forwarding setting and its quoted advice come from Tailscale’s update page; the test versions, findings, lab results and the advice on per-pair rules, serve settings, key expiry and device removal come from the researchers’ Tailworm report, which Tailscale hasn’t confirmed point by point. Labelled steps and the /etc/default/tailscaled and tailscale set --ssh=false instructions are our own advice. No affiliate links on this page. How we work.