Tailworm: What Tailscale SSH Forwarding Means for the Rest of Your Tailnet

9 November 2026 LinuxSecuritysshTailscaleVPN

The Tailworm disclosure landed in the last week of October with 11 reported findings, no CVE identifiers, and a vendor patch inside days. Two weeks on, the facts have settled enough to write down, and the interesting part is not the bug count. It is what the main finding says about trusting identity-based SSH.

What was disclosed

Cyberdione Labs published a report called Tailworm on 24 October, about two hours after Tailscale received it. Tailscale has said it received the report that morning, so this was an uncoordinated disclosure with no patch available at the time. SecurityWeek reports 11 findings, six of them rated high by the researchers, tested against Tailscale client 1.104.2 and headscale 0.29.5. Four of the findings involve Tailscale SSH. The rest touch Serve, app connectors, headscale and the client relay.

Tailscale confirmed the issues were real, called them serious, and published its own account on 28 October. Its fix is in v1.104.4. I have not found any report of exploitation in the wild.

What Tailscale says it fixed

Tailscale grouped the work into four security bulletins, all dated 26 October and all fixed in 1.104.4 or newer. None carries a CVE or a stated severity.

BulletinIssueFixed in
TS-2026-014Tailscale SSH Unix socket forwarding grants peers access to root-only sockets1.104.4
TS-2026-015Unbounded memory growth in Tailscale SSH session handling, leading to denial of service1.104.4
TS-2026-016tailscale serve Unix backends could reach privileged sockets, including the tailscaled local API1.104.4
TS-2026-017Shared HTTP/2 serve context could apply capability headers from one mount to another1.104.4

Tailscale’s own post also says two of the five reported Serve and Funnel findings work as designed, because one needs local admin access and the other is an opt-in setting. A vulnerability in Conn25, the app connector work, is in unreleased code and does not affect the stable app connectors. I did not find a headscale fix in the sources I read. Headscale is a separate open-source project, so check its releases directly if you run it.

Why the forwarding finding matters

TS-2026-014 is the one that explains the rest. Tailscale SSH lets the tailscaled daemon, which runs as root, handle SSH sessions for users it has authorised by identity. Reporting on the research, including BleepingComputer, describes Unix socket forwarding (ssh -L and ssh -R to a socket path) doing its path checks and file operations as root. Races and a missing privilege drop meant an ordinary session could replace, dial or delete privileged resources.

Tailscale’s description is more general: after a connection was authorised, permissions were not enforced correctly, so an authenticated session could do things beyond its local user’s privileges, including through forwarding. It states that the authentication and access-policy checks were not the problem.

The practical consequence is that a root-owned socket becomes reachable from a normal session. The Docker socket is the obvious example. On a host that runs Docker, access to that socket is root.

The preconditions

This is not an unauthenticated remote bug, and Tailscale is explicit about that. An attacker needs all of these:

  1. A foothold on a device that is already an authorised peer on the tailnet.
  2. An SSH rule in the tailnet policy that permits access to the target.
  3. The vulnerable behaviour to be reachable, which for TS-2026-014 means forwarding is allowed in policy.

Tailscale says the vulnerabilities do not allow an unauthenticated attacker to connect to arbitrary Tailscale SSH servers, and that access is limited to machines the policy already allows SSH to.

Is it a worm?

The researchers say the flaws can be chained into a worm that spreads between nodes without user interaction. Tailscale disagrees with that framing, stating that the issues “don’t describe self-replicating malware spreading automatically between machines.” Both statements can be true. A chain that needs no human at each hop is a lab result about what a compromised node can reach, and it still depends on policy letting that node SSH to the next one.

That is why the useful lesson is about blast radius. Per-host SSH keys limit what one stolen credential opens. Identity-based access moves that limit into the policy file. If the policy says a laptop can SSH to forty servers as a normal user, then a bug that turns a normal session into root has forty targets.

What to check

If you use Tailscale SSH, start with the version.

tailscale version

Treat anything below 1.104.4 as affected. On a Debian or Ubuntu host installed from Tailscale’s apt repository, update with:

sudo apt update && sudo apt install --only-upgrade tailscale -y
sudo systemctl restart tailscaled
tailscale version

If you cannot update straight away, Tailscale’s stated workaround for the forwarding finding is to set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart it. This turns off forwarding without turning off Tailscale SSH. On a systemd host, a drop-in does that:

sudo mkdir -p /etc/systemd/system/tailscaled.service.d
printf '[Service]\nEnvironment="TS_SSH_DISABLE_FORWARDING=1"\n' | sudo tee /etc/systemd/system/tailscaled.service.d/no-ssh-forwarding.conf
sudo systemctl daemon-reload
sudo systemctl restart tailscaled

Then review the SSH section of your tailnet policy. Tailscale recommends limiting access to the users and devices that need it, and using check mode for sensitive systems. A check rule asks for an extra authentication step before a session opens. This is an illustrative rule, so adjust the tags and users to your own policy:

"ssh": [
  {
    "action": "check",
    "src": ["autogroup:member"],
    "dst": ["tag:prod"],
    "users": ["autogroup:nonroot"]
  }
]

Tailscale does not recommend turning Tailscale SSH off. After patching, I agree. The issue was how permissions were enforced inside an authorised session, not the idea of identity-based SSH.

The wider point

This is the same trust question the rest of this site keeps returning to. In SSH Hardening Beyond the Basics the answer to “who can reach what” is a certificate authority, short-lived certificates and a bastion that records sessions. In Pivoting and Tunneling Part 6 it is segmentation and egress filtering, so that a foothold on one host cannot see the next. Tailscale SSH is a convenient way to get the first, and Tailworm is a reminder that the second still applies inside the tailnet. The forwarding behaviour in SSH Deep Dive Part 3 is also worth rereading, because every -L and -R there is a path someone can use to reach a socket.

If you were deciding between tools, Tor Deep Dive Part 10 compares Tailscale with the alternatives. Nothing in Tailworm changes that table, but it does add a row about what a compromised peer can reach.

This is the second SSH-adjacent disclosure in a few weeks, after the sshole bug in OpenSSH. Neither is a reason to abandon SSH. Both are reasons to know exactly which of your hosts run which SSH server, and what each one’s policy allows.

Sources: Tailscale: SSH findings and fixes, Tailscale security bulletins, SecurityWeek, BleepingComputer, The Hacker News, DEV Community summary of the 1.104.4 fix.

Related Posts