Tailscale SSH vulnerability: patch to 1.104.4, then fix ACLs

The Tailscale SSH vulnerability disclosed this week needs no stolen key: it needs a peer your policy already lets in. In the researcher's lab, an unprivileged session forwarded to the Docker socket came back as uid=0(root). Upgrade to 1.104.4, turn forwarding off and narrow SSH grants to single pairs. You do not need to go back to a bastion host.

That is the decision this post settles for a platform team that replaced its bastion with Tailscale SSH: what the patch covers, what remains contested, and which three policy changes still matter after you upgrade.

Bulletin	What it covers	Precondition
TS-2026-014	Unix socket forwarding could grant peers access to root-only sockets	Tailscale SSH on, forwarding allowed in policy
TS-2026-015	Memory exhaustion in SSH session handling (denial of service)	An authenticated session the policy permits
TS-2026-016	tailscale serve Unix backends could reach privileged sockets, including the tailscaled local API socket	Someone who can write Serve config or backend paths
TS-2026-017	Serve over HTTP/2 could send the wrong app capabilities across mounts	Serve TLS with two or more mounts on one node

All four are dated 26 October 2026 on Tailscale's security bulletin page, each fixed in 1.104.4 or newer, with no CVE or CVSS score listed as of 28 October.

The Tailscale SSH vulnerability starts with a peer you already allowed

Tailscale's investigation update says most of the issues are privilege escalation by someone "already authorized to connect over Tailscale SSH". Nothing here lets an outsider into your tailnet. The risk is that a login as an ordinary user ends with root on the target.

The mechanism is in Erica Windisch's Tailworm report from Cyberdione Labs, which tested tailscale 1.104.2 and headscale 0.29.5 between 22 and 24 October. Because tailscaled runs as root and performed socket forwarding itself, ssh -L to the Docker socket gave a non-root session root access. Reverse forwarding with ssh -R could replace root-owned sockets.

Two controls that teams lean on do not help here. The report calls non-root target accounts "defense-in-depth only", because the findings work from unprivileged accounts, and says check mode "does not mitigate the forwarding findings", since it only gates session start.

Which Tailscale version fixes the SSH vulnerabilities?

Tailscale 1.104.4 is the fixed release. Its version commit landed at 22:46 UTC on 27 October and the GitHub release went live at 01:05 UTC on 28 October, which meets Tailscale's stated target of the end of Tuesday 27 October. The bulletins carry 26 October, the day Tailscale published its update, not the day the fix shipped.

On the date conflict: The Hacker News calls it "the October 27 update" because that is when it added Tailscale's statement to its 25 October article. Tailscale's own page reads "Published October 26th 2026", so we use 26 October.

The diff between 1.104.2 and 1.104.4 runs to 42 commits. The ones that matter here route SSH forwarding through a privileged monitor, relay Unix forward payloads "as the bound user" and dial TCP forwards as that user. The release notes only point to the changelog, which had no 1.104.4 entry when we checked on 28 October.

The fix is not complete. Windisch's mitigation matrix, a snapshot from 28 October, marks seven of her 11 findings fixed in 1.104.4, two partial, one open and one documented with no change planned.

What is contested, and what is not

The "wormable" label is the contested part. The report measured spread in a lab at under a second per hop. The Hacker News reports that some researchers publicly questioned the label and that no other researcher has publicly reproduced the findings. The proof of concept is not public.

The report itself states limits. The race against systemd succeeded 0–4% of the time. The root read in Finding 1 ran on an SELinux-enforcing distribution that blocked host-file reads. Windisch also calls the disclosure "reported but not coordinated"; she told The Hacker News she sent the report and proof of concept to Tailscale's security contact the Saturday before publication.

Here is the strongest case for ripping Tailscale SSH out: the server runs as root, the fix arrived within three days of publication, and the researcher's own matrix still lists open findings. Windisch advised users to disable Tailscale SSH when she published. That case argues for treating every SSH grant as root, which is what the report's mitigations do. It does not argue for a bastion, which concentrates access on one host and carries its own patch queue. Tailscale's update says "we're not recommending that everyone disable Tailscale SSH".

What to change before you trust the patch

The upgrade fixes code. These changes fix the policy that made the code reachable, and most of them can ship today.

1. Upgrade every node running the SSH server to 1.104.4. The client on your laptop is not the exposure; tailscaled on the target is.
2. Turn forwarding off where nobody needs it. TS-2026-014's precondition is forwarding allowed in policy.
3. Rewrite SSH rules as single source-to-destination pairs. Per-pair grants were the one control that stopped spread in testing; tag-wide accept rules are what let it travel.
4. Remove any tailscale serve forward pointing at a Unix socket, especially tailscaled's own (TS-2026-016).
5. Delete suspect devices in the admin console. The report says reimaging alone does not revoke copied keys.

TS_SSH_DISABLE_FORWARDING in Tailscale

Set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart. TS-2026-014 says this disables forwarding without disabling Tailscale SSH. Coverage written before 26 October, such as Konfirmity's advisory, still calls the switch undocumented and unendorsed. Tailscale now recommends it. Konfirmity's warning that it breaks tools tunnelling over SSH still holds, so check who uses -L before you flip it. The report also describes per-rule forwarding fields on hosted tailnets; we could not find them in Tailscale's SSH documentation, so the environment variable is the documented route.

Does Tailnet Lock stop the Tailscale SSH attack?

Tailnet Lock stops the last step, not the escalation. In the lab, a captured auth key let a rogue node join "under the victim's identity" only with Tailnet Lock off, which is the default. With it on, the disablement secret and signer key material were captured but the disable was never run. If a signing node was exposed, rotate the lock.

Headscale users cannot turn forwarding off in policy

The report states that "on headscale v0.29.5 forwarding cannot be disabled" and tells you to "treat every headscale SSH grant as root-equivalent". The forwarding itself happens in tailscaled on each node, so 1.104.4 applies there regardless of control server. Whether TS_SSH_DISABLE_FORWARDING behaves the same under headscale is something neither Tailscale nor the report addresses, so test it before you rely on it. The latest headscale release, 0.29.6 of 24 October, has no SSH notes, and the report marks the headscale part of its Finding 6 as pending.

If you run headscale, keep the server off the open internet, as Konfirmity advises, and do not hand out SSH grants you would not hand out as sudo.

Keep Tailscale SSH or go back to a bastion?

Keep it, on three conditions: every SSH server on 1.104.4, forwarding off by default and allowed per host only where a named workflow needs it, and SSH rules written as pairs rather than tags. This is the wrong choice if you cannot audit your policy file this week, or if you run headscale and cannot stop granting SSH broadly. In that case, switch Tailscale SSH off on the most sensitive hosts until you can.

The same assume-the-worst habit applied to the Artifactory vulnerability chain, and 1.104.2 was itself the fix for the eMudhra CA compromise a week earlier. Two Tailscale security releases in one week means auto-update and infrastructure monitoring of node versions are part of the access model.

If you need someone to rewrite an SSH policy into per-pair grants, roll the forwarding switch out without breaking your tunnels and prove every node is on 1.104.4, our DevOps and cloud engineering team can take that audit on with you.