Tailscale has shipped version 1.104.4 to fix a set of Tailscale SSH and Serve vulnerabilities that could let an attacker who already controls one trusted device reach root-only Unix sockets, such as the Docker socket or the tailscaled local API, on other machines in the tailnet. Released on October 28, 2026, the update covers four bulletins, TS-2026-014 through TS-2026-017, and follows a report called “Tailworm” by researcher Erica Windisch of Cyberdione Labs, who described the chain as “wormable.” Tailscale disputes the worm label but calls the privilege-escalation issues “serious security issues.” If your team uses Tailscale for admin access to Linux servers, here’s what broke, how to fix it, and what the patch doesn’t cover.
What Went Wrong in Tailscale SSH
Tailscale SSH lets devices open SSH sessions based on tailnet identity and policy instead of passwords or keys, and it supports forwarding TCP and Unix sockets. According to Tailscale’s bulletin for TS-2026-014, the SSH server inside the root-privileged tailscaled process “validated Unix socket paths lexically but would perform the operations as root.” That created three problems:
- Privileged dials: local forwarding (
ssh -L) could connect to root-only sockets. - Socket replacement: remote forwarding (
ssh -R) could unlink and replace root-owned sockets. - Race condition: a time-of-check/time-of-use trick defeated the path allowlist because the kernel re-resolves paths after the initial check.
The Hacker News reports that in Windisch’s own tests, forwarding to the Docker control socket produced a root shell and exposed the system password file without administrator rights. Tailscale’s fix makes forwarding run as the authenticated user rather than root, leaning on normal operating system permissions.
The Four Bulletins at a Glance
- TS-2026-014: SSH Unix socket forwarding could grant peers access to root-only sockets.
- TS-2026-015: an authorized SSH session could exhaust
tailscaledmemory with continuous window-change messages and environment variable appends, triggering an OOM kill that drops every Tailscale connection on the node. - TS-2026-016:
tailscale serveUnix backends could reach privileged sockets, including the local API socket, which Tailscale says “allowed full node takeover.” - TS-2026-017: with Serve TLS and two or more mounts, HTTP/2 streams could leak
Tailscale-App-Capabilitiesvalues from one mount to another.
As The Hacker News noted, the bulletins carry no CVE identifiers or severity scores so far, and neither Tailscale nor the researcher reports exploitation in the wild. The proof-of-concept code has not been made public.
Worm or Not? The Scope Debate
The exploit chain has real limits. Tailscale stresses that the flaws “don’t allow an unauthenticated attacker to connect to arbitrary Tailscale SSH servers.” An attacker needs an existing foothold on an authorized peer, SSH access explicitly permitted in the tailnet policy file, and, for the most serious issues, forwarding allowed. Tailscale describes the result as “lateral movement limited to connections allowed by a tailnet policy file,” not self-replicating malware.
Windisch’s tests, as summarized by The Hacker News, showed one compromised device spreading to every device the policy allowed in under a second per step. Two controls stopped the spread: writing access rules as single device-to-device pairs, and binding device keys to hardware such as a TPM. The disclosure itself was rocky, too: Tailscale says it received the report on Saturday, October 24, about two hours before it was published.
What IT Teams Should Do Now
- Upgrade: move every node running Tailscale SSH or Serve to 1.104.4 or newer. Note that 1.104.3 was internal-only.
- Mitigate if you can’t update: set
TS_SSH_DISABLE_FORWARDING=1in thetailscaledservice environment and restart, which disables forwarding without turning off Tailscale SSH. - Tighten SSH policy: limit SSH grants to the users and devices that truly need them and avoid broad source groups.
- Don’t over-trust check mode: SSH check mode re-authenticates at session start, but the forwarding flaws happen inside an already-approved session.
- Rotate suspect device keys: if a node may be compromised, the report warns that reimaging alone doesn’t revoke its key; delete the device at the control plane.
A Warning for headscale Users
Self-hosters have extra homework. According to the Tailworm report as cited by The Hacker News, headscale, the open-source self-hosted control server, grants SSH forwarding on every accepted session with no policy switch to turn it off, and the latest release at the time, 0.29.5 from October 13, does not address the reported issues. Until that changes, Windisch advises treating every SSH grant on headscale as equivalent to root, which makes the client upgrade and the forwarding kill switch doubly important.
Looking Ahead
This is the latest in a string of fixes in the same corner of Tailscale this year; version 1.98.9 already closed a separate SSH Unix-socket forwarding flaw earlier in 2026. Expect continued scrutiny of mesh-VPN SSH features as more teams replace bastion hosts with identity-based access, and expect CVE assignments to follow for these bulletins.
For admins, the broader lesson is that “zero trust” networking still depends on least privilege inside the policy file. Tight, pairwise SSH grants and hardware-bound device keys turned a potential tailnet-wide spread into a contained incident in testing, and those are worth adopting regardless of the patch.
Sources:
- Tailscale, October 28, 2026
- The Hacker News, October 28, 2026
- Tailscale, October 27, 2026
