Tailscale 1.104.4 Fixes Serious Tailscale SSH and Serve Flaws: Update Every Node, Then Tighten SSH Rules

TL;DR: Tailscale has shipped the fix. Tailscale 1.104.4, released on October 28, 2026 (01:05 UTC, 9:05 a.m. Manila), fixes flaws in Tailscale SSH and Tailscale Serve that Tailscale has now published as security bulletins TS-2026-014 to TS-2026-017. One let a device allowed to forward over Tailscale SSH reach root-only sockets on the target, “such as the Docker socket or the tailscaled local API.” The flaws were made public in a report called Tailworm, whose researchers tested v1.104.2. No CVEs have been assigned and no attacks are reported. If you use Tailscale SSH or Serve, update every node to 1.104.4 or newer, starting with servers, and keep your SSH rules tight. headscale, the self-hosted control server some teams use, hasn’t shipped a release with these fixes yet, so the researchers’ interim advice still applies there.

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 first check on October 27, 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.

Update, October 28: Tailscale released v1.104.4 on GitHub at 01:05 UTC (9:05 a.m. Manila), with packages for Linux, Windows, Android and Synology on its download server. Four new security bulletins, dated October 26, say each issue “is fixed in Tailscale version 1.104.4 or newer”:

• TS-2026-014: Tailscale SSH socket forwarding ran as root, so a peer allowed to forward could reach root-only sockets “such as the Docker socket or the tailscaled local API.” It affects devices with Tailscale SSH that allow local or remote forwarding. Tailscale now forwards as the logged-in user.
• TS-2026-015: a signed-in Tailscale SSH session could make tailscaled use more and more memory until it crashed, cutting every Tailscale connection on that device.
• TS-2026-016: Tailscale Serve backends pointing at Unix sockets could reach privileged sockets, including the tailscaled local API, which Tailscale says “allowed full node takeover.” It affects devices where someone local can write Serve settings or the backend paths.
• TS-2026-017: on Serve with TLS and two or more mounts that need different capabilities, one app’s permissions could bleed into requests for another.

The bulletins list no CVE IDs. The researchers’ Tailworm report, updated October 27, says a patched release carrying the fixes it lists shipped as v1.104.4. It also says a partial fix for one more finding was still an open pull request, and that its interim advice still applies to versions before 1.104.4 and to headscale. At our check, Tailscale’s investigation page and changelog hadn’t been updated to mention 1.104.4.

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 fix is now a normal client update, and the forwarding setting below remains a stopgap for devices you can’t update today. Teams on headscale should pay the most attention: the researchers say forwarding can’t be switched off per rule on headscale v0.29.5, and that their interim advice still applies to headscale up to v0.29.6, so every SSH grant there should be treated as root access until the clients are updated and headscale ships its own fixes. 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. Update to 1.104.4 or newer. Tailscale’s bulletins say to upgrade if you use Tailscale SSH or Tailscale Serve. Our advice: update servers that accept Tailscale SSH first, then everything else, and confirm the version on each device in the admin console’s Machines page. On Linux, sudo apt update && sudo apt install tailscale (or your package manager’s equivalent) pulls the new release from Tailscale’s repository.
2. Find out if you use Tailscale SSH or Serve. In the Tailscale admin console, check your access policy for SSH rules and which devices have Tailscale SSH turned on; on each server, tailscale serve status shows Serve settings. If you use neither, the main findings don’t apply to you, but keep Tailscale up to date.
3. If you can’t update a device today, 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.
4. 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.
5. Remove risky serve settings. The researchers advise removing any tailscale serve TCP forward that points at a Unix socket on the device.
6. Turn on automatic updates. Our advice: enable Tailscale’s auto-updates where your platform supports it, so the next fix lands without a manual round.
7. 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 28, 2026, 10:45 a.m. Manila: What changed: Tailscale released v1.104.4 (October 28, 01:05 UTC) and published security bulletins TS-2026-014 to TS-2026-017, which say the SSH and Serve issues are fixed in 1.104.4 or newer. We updated the headline, summary, version table and steps: update first, and use the forwarding setting only as a stopgap. Still no CVEs, no reported attacks and no headscale fix.
• 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)
• Tailscale security bulletins TS-2026-014 to TS-2026-017 (dated October 26, 2026)
• Tailscale v1.104.4 release on GitHub (October 28, 2026, 01:05 UTC)
• Tailscale stable packages (1.104.4)
• Tailworm report by Erica Windisch, Cyberdione Labs (updated October 27, 2026)
• Tailscale’s systemd service file for tailscaled (environment file path)
• Tailscale docs, “Tailscale SSH”

Method. Last checked October 28, 2026, at 10:05 a.m. Manila time (02:05 UTC); first checked October 27 at 9:27 p.m. Manila. The fixed version, bulletin details and quotes about the fixes come from Tailscale’s security bulletins, its GitHub release and its package server. What Tailscale says in its investigation update, 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 apt, tailscale serve status, /etc/default/tailscaled and tailscale set --ssh=false instructions are our own advice. No affiliate links on this page. How we work.