MAG212 CYBER ORIGINAL ARTICLE

Tailscale SSH Vulnerabilities TS-2026-014 to 017 (“Tailworm”): What Was Fixed in v1.104.4 and How to Harden

October 28, 2026 · EL MOSTAFA OUCHEN

MAG212 CYBER | Vulnerabilities | October 28, 2026

Tailscale has fixed four vulnerabilities in Tailscale SSH and Tailscale Serve, tracked as TS-2026-014 through TS-2026-017, in client version 1.104.4. The fixes follow a public disclosure by a researcher who called the attack chain “Tailworm” and described it as wormable. Tailscale disputes that framing. The common thread is a privileged daemon that checked a path as text, then acted on it as root.

Key facts

Item	Detail
Bulletins	TS-2026-014, TS-2026-015, TS-2026-016, TS-2026-017 (dated 26 October 2026)
Fixed in	Tailscale v1.104.4, released around 27–28 October 2026
CVE / CVSS	None assigned to any of the four bulletins
Precondition	An existing foothold on an authorized device in the tailnet, with SSH allowed by policy (for the SSH issues)
Researcher	Erica Windisch, Cyberdione Labs (“Tailworm”, 11 findings)
Mitigation	`TS_SSH_DISABLE_FORWARDING=1` until patched

The four vulnerabilities

Bulletin	What went wrong	Impact	Fix in 1.104.4
TS-2026-014	SSH Unix-socket forwarding checked paths lexically, then dialed them as root. Three variants: privileged dials via `ssh -L`, unlink-and-replace of root-owned sockets via `ssh -R`, and a race that beat the path allowlist	Reach root-only sockets such as Docker’s or the tailscaled LocalAPI	Forwarding now runs as the authenticated user
TS-2026-015	Repeated window-change messages and environment appends grew session memory without release	tailscaled killed by the OOM killer (denial of service)	Bounded and freed on disconnect
TS-2026-016	Serve TCP forwards to Unix sockets were dialed as root; the symlink check ran only at config reload	Full node takeover	TCP forwards limited; backends checked on every dial
TS-2026-017	HTTP/2 streams shared one serve context with Serve TLS enabled	`Tailscale-App-Capabilities` headers leaking across mounts	Capabilities taken from a per-request context

How TS-2026-014 turns an authorized SSH grant into root-socket access. Based on Tailscale’s bulletin and the researcher’s description.

Who is actually exposed?

Tailscale’s 28 October post says exploitation requires “an existing foothold on an authorized peer in the tailnet” with SSH permitted by the tailnet policy. It describes the risk as lateral movement limited to the connections your policy already allows, not a way for an outsider to reach arbitrary machines. WireGuard cryptography is not affected.

That still matters. If one laptop in your tailnet is compromised and your policy lets it SSH into production with forwarding, TS-2026-014 can turn that access into root on the target, for example through the Docker socket.

The “Tailworm” dispute

Erica Windisch of Cyberdione Labs published 11 findings against Tailscale v1.104.2, headscale v0.29.5 and the gliderssh library, from lab testing on 22–24 October. She described the chain as wormable: hopping to every device the policy allows in under a second each, without passwords, keys or user action. On tailnets without Tailnet Lock, the chain captured an enrollment key and joined an attacker machine; with Tailnet Lock, that last step failed. Her proof of concept is private and has not been independently reproduced.

She calls the disclosure “reported but not coordinated”. Tailscale says it received the report on Saturday 24 October and that publication followed about two hours later. Of the Serve and Funnel findings, Tailscale says three were bugs (now fixed) and two are working as designed: one needs local admin access, and TS_SERVE_ALLOW_ALL_INTERFACES is opt-in. Tailscale’s VP of Engineering said the company is “not recommending that everyone disable Tailscale SSH”.

How to fix and mitigate

1. Update every client to v1.104.4 or later, then verify the running version on each host and in the admin console’s Machines list. Auto-update can lag behind a release, so don’t assume coverage.

tailscale version
systemctl status tailscaled
journalctl -u tailscaled --since "2026-10-20"

2. Disable forwarding until you’re patched. This is Tailscale’s documented mitigation for TS-2026-014. On Linux with systemd:

sudo systemctl edit tailscaled
# add:
[Service]
Environment=TS_SSH_DISABLE_FORWARDING=1
# then:
sudo systemctl restart tailscaled

Keep an out-of-band recovery path before restarting tailscaled on remote servers.

How to harden Tailscale SSH

Tailscale’s own advice is short: update, limit SSH policies to the users and devices that need them, and consider check mode for sensitive systems. A tighter policy might look like this:

"ssh": [{
  "action": "check",
  "src":    ["group:sre"],
  "dst":    ["tag:prod"],
  "users":  ["autogroup:nonroot"],
  "checkPeriod": "1h"
}]

Check mode makes users re-authenticate periodically. It gates login, not the escalation itself, so treat it as defense in depth. Tagged sources can’t use check mode.
Enable Tailnet Lock. It blocked the final node-enrollment step in the researcher’s lab.
Remove Serve forwards to Unix sockets you don’t need (TS-2026-016).
Prefer narrow grants between specific groups and tags over “any member to any server”.
Review new node enrollments, policy edits and auth-key creation since 20 October. If you suspect compromise, isolate the device, delete it at the control plane and rotate auth keys after preserving evidence.

What about Headscale?

Headscale, the open-source control server, is a separate project. Updating clients to 1.104.4 should address the client-side bugs regardless of control server (our assessment). But on headscale v0.29.5, SSH grants always include forwarding and policy can’t turn it off, so treat every SSH grant as root-equivalent and set TS_SSH_DISABLE_FORWARDING=1 on clients. The researcher’s separate headscale memory and registration-cache findings had no released fix as of 28 October (PR #3586 pending).

Frequently asked questions

Which Tailscale version fixes TS-2026-014?

Tailscale v1.104.4 and later fix TS-2026-014 through TS-2026-017.

Can an outsider exploit Tailscale SSH remotely?

Not according to Tailscale. The SSH flaws require an already-compromised device that your tailnet policy allows to SSH into the target.

Is “Tailworm” self-replicating malware?

No. “Tailworm” is the researcher’s name for a lab-demonstrated attack chain. There are no public reports of it being used in the wild, and the proof of concept is private.

Should I disable Tailscale SSH?

Tailscale doesn’t recommend that. Update to 1.104.4, disable forwarding until you’re patched, and narrow your SSH policy.

Sources

This article expands the Tailscale feature from the MAG212 CYBER October 28, 2026 Intelligence Edition. Build safe, authorized scans of your own network with our free Nmap command builder.

Read the full magazine (PDF) →