Tailworm: Tailscale SSH Flaws Need a Foothold

Quick verdict: The Tailworm report is not describing an internet-facing Tailscale exploit. Its headline SSH issue is a post-compromise privilege escalation. An attacker needs an approved device, an SSH rule that permits access, and forwarding. Give them those, and a normal ssh -L or ssh -R command can make the root-owned tailscaled process reach root-only Unix sockets on a target. In a lab, that produced root on Docker and systemd, and a captured enrollment key that added a rogue node to the tailnet.

That split explains the disagreement. For an outsider with no foothold, the attack is hard: there is no unauthenticated path from the internet. For an insider, a compromised laptop, or malware on an approved server, the attack can be easy if the tailnet’s SSH rules are broad and forwarding is allowed. The report calls the result "wormable" because it spread from one permitted device to every device the policy allowed in under a second per hop. Per-pair SSH grants stopped that spread in the lab. Hardware-bound device keys raised the cost of persistence.

Key takeaways

• Not an internet RCE. No password, key, or unauthenticated connection from outside the tailnet.
• Needs a foothold and a rule. One approved device plus an SSH rule that permits access and forwarding.
• Root via standard SSH. The root tailscaled process performs the privileged Unix-socket dial, not the unprivileged user.
• The race bypasses the path allowlist. A rename loop defeats the check on paths outside the allowed directories; the systemd variant was intermittent (0 to 4 percent), not deterministic.
• No CVE or patch yet. As of October 25, 2026, Tailscale has no bulletin for these findings; its VP says fixes are being tested.
• "Wormable" has a narrow meaning. It spreads within a permissive tailnet; it does not cross tailnet boundaries or break WireGuard.

What the Tailworm report found

Erica Windisch of Cyberdione Labs published Tailworm on October 24, 2026, with coverage following on October 25. The report contains 11 numbered findings across five classes: Tailscale SSH, the experimental conn25 app connector, the headscale control server, the DERP relay client, and the serve/funnel feature. The tests ran from October 22 to 24 against Tailscale v1.104.2 and headscale v0.29.5, both unmodified released software.

The headline is the SSH class, findings 1 through 3. The mechanism is a privilege mismatch. Tailscale SSH does not authenticate a user with a password or an SSH key. WireGuard identifies the device, and one policy rule authorizes the session. The SSH server itself runs inside tailscaled as root. When the session asks for Unix-socket forwarding, that root process performs the bind, dial, unlink, or chmod. The report says the path checks and the privileged operations are not safely separated, so an unprivileged session can make root act on a socket the session could not touch directly.

This is not the first problem in this area. Tailscale fixed TS-2026-004, where SSH Unix-socket forwarding did not respect symlink permissions, and TS-2026-005, where Serve Unix-socket proxy targets were not restricted to root, in version 1.98.9. The new report says v1.104.2 still has a check-to-use gap and a missing guard on the TCP-forward path.

Finding 1: local forwarding to a root-only socket

The simplest variant uses local forwarding. The report’s example points an ssh -L tunnel at the Docker socket in /tmp, which is inside the path allowlist, and then speaks the Docker API through it:

ssh -fNT -L /tmp/relay.sock:/tmp/docker.sock user@target
docker -H unix:///tmp/relay.sock run --rm -v /:/host busybox sh -c 'id; head -c 40 /host/etc/shadow'

The lab got uid=0(root) and read /etc/shadow with no sudo, no Docker group membership, and no access to the victim daemon. The report measured the elapsed time as zero seconds. This variant does not need the race. It needs a socket in an allowed directory and a policy rule that permits local forwarding.

Finding 2: remote forwarding replaces a root-owned socket

The second variant uses ssh -R. The root process unlinks a root-owned socket and binds the attacker’s listener at the real path, so the attacker impersonates the service. For a command-channel daemon, the report says one crafted message produced root code execution. For Docker, the result was cleartext registry-credential capture and control over pulls of unpinned tags; host root required a further step. The prerequisite is a rule that permits remote forwarding.

Finding 3: the path check is a TOCTOU

The third variant defeats the allowlist. The validation function checks the lexical path at check time; the unlink, bind, or dial happens later, when the kernel resolves the path again. A rename loop running in the SSH session, measured at roughly 170,000 path-state flips per second, can win the gap. The report demonstrated a root-credential dial of /run/systemd/private, a kubelet socket that saw uid=0 comm=tailscaled, and a hijacked Tailscale local API socket that captured an enrollment key. The full chain added a rogue node to the tailnet in the lock-disabled case. The systemd path was intermittent, with the report citing a 0 to 4 percent success rate for delivery through the race. The Docker path in finding 1 is the reliable one.

The race also produced two side effects: an arbitrary root chmod 0600 on regular files, and an arbitrary root unlink of regular files. The report calls these availability and destruction primitives rather than content modification.

How hard is it to exploit?

The answer depends on where the attacker starts. This table separates the scenarios because "easy" and "hard" are both correct in different columns.

Two details make the low-difficulty cases credible. First, the attacker does not need a password or a stolen SSH key. The device identity is the credential, and a foothold on the device inherits the device’s full authorization, regardless of which local user the malware runs as. Second, the attacker does not need a custom exploit for findings 1 and 2. A stock SSH client and the target’s own API are enough.

The race in finding 3 is the part that deserves the "hard" label. It is a timing attack with an intermittent win rate, and it needs the right target path. It is also repeatable. The report’s full rogue-node chain required holding the rebind for at least four minutes. That is more than a one-shot, but far less than a typical remote exploit chain. The report’s proof-of-concept code is not public; Windisch says she provided it to Tailscale’s security contact.

Why "wormable" is contested

The report’s strongest claim is that one ordinary foothold becomes fleet-wide privileged access at machine speed. In the lab, once a device was compromised, the attack used the policy’s own SSH grants to reach the next device, with no passwords, no stolen keys, and no user interaction. The report measured under a second per hop. That is automated lateral movement inside a tailnet.

It is not a traditional internet worm. It does not jump to a device the policy does not permit, it does not cross tailnet boundaries, and it does not break WireGuard. The report says per-pair access grants were the single control that stopped the spread, and hardware-bound device credentials such as TPM or Secure Enclave prevent the identity theft that makes compromise persist. That is why the label is a scope argument. Within a flat, permissive tailnet, "wormable" is a fair description. Across the internet, it is not.

Tailscale’s vice president of engineering, Mike Shaver, made the same distinction in his public response: "it isn’t the same as an unauthenticated attacker being able to connect to arbitrary machines." A Tailscale engineer also noted on Hacker News that the hosted control plane trims peer maps, so devices with no policy relationship may not see each other; the report’s enumeration claim may be more applicable to headscale. That reduces reconnaissance, not the privilege escalation once a path exists.

There are other caveats. The report is self-published, and no independent researcher has publicly reproduced the findings. The report describes lab tests, not attacks on real networks. Some readers have criticized its length and presentation, and some have disputed the worm label. None of that is a technical rebuttal. Tailscale says it has identified issues in the same area and is fixing them.

The other findings in the report

The SSH class is the headline, but it is not the whole report. The other findings matter because they change the blast radius for different deployments.

• conn25 app connector (High). A user entitled to one app can register arbitrary destinations with the connector. The report says the destination is validated only by address family and transit-pool membership, and the real destination is never a policy object. In the lab, an entitled peer reached internal LAN services and, in Kubernetes, the service CIDR and kube-apiserver; the report says the same path can reach cloud metadata. The feature is experimental and requires an entitlement. Windisch told The Hacker News this finding may be more impactful to some organizations than the SSH bug.
• Tailscale SSH server memory exhaustion (High). An authenticated session can send window-change and environment churn that parks goroutines and grows memory in the root daemon. The report measured about 536 MB allocated in seven seconds, persisting after disconnect. The fix belongs upstream in the gliderlabs/ssh library.
• headscale denial of service (Medium-High). The report describes unauthenticated memory growth and cache eviction against an internet-reachable headscale: embedded DERP history growth, 1,024 tiny registrations evicting pending approvals, and a DERP client response that expands from 10 MB to 1.34 GB. The result is a crash loop or an onboarding lockout, not data theft. headscale 0.29.6, released October 24, lists unrelated security updates and does not list a Tailworm fix.
• Serve and funnel (Medium to High). A local operator can configure tailscale serve --tcp <port> unix:/run/tailscale/tailscaled.sock and expose the local API to a remote peer, which the report says can read status and patch preferences. The HTTP proxy path blocks that target; the TCP path did not. A separate shared-context race can leak capability headers across serve mounts, and a local-config gate can arm funnel without the control-plane attribute. These require local configuration or specific deployments.
• DERP client (Medium). A hostile relay can return an oversized response that the client reads in full, causing memory exhaustion. The attacker needs to position or point the client at that relay.

What Tailscale says

Tailscale has not confirmed the specific findings, but it has acknowledged the report and the general class. Shaver’s response says the company had already been investigating the same areas with external security specialists, and that the work identified issues it is fixing. The key passage:

"Most of the issues we’ve identified so far concern what happens after someone has been authorized to connect, particularly how Unix privileges and SSH forwarding are handled. In some cases, a session may be able to do more than the configured local user should be allowed to do."

That is a narrower claim than the report’s, but it is not a denial. Shaver also said Tailscale is "not recommending that everyone disable Tailscale SSH," and that it will publish a security advisory with the confirmed findings, affected configurations, recommended actions, and available patches. There is no timeline and no CVE as of October 25. Tailscale’s latest bulletin, TS-2026-013, is about the eMudhra certificate authorities, not Tailscale SSH.

The practical read: the vendor agrees that post-authorization forwarding is the sensitive area. It has not agreed that every finding is exploitable as described, and it has not shipped a fix. Treat the report as a credible warning and the vendor response as an incomplete confirmation, not a clean bill of health.

What to do now

1. Rewrite SSH rules as per-pair grants. Name one source and one destination. Remove identity-wide and tag-wide accept rules. The report says per-pair grants were the single control that stopped the lab spread. Tailscale’s default SSH policy is already narrower than a broad accept rule: check mode to your own devices. The risk grows when operators add broad rules.
2. Turn off SSH forwarding where you can. On Tailscale’s hosted service, the report says forwarding can be denied per rule. On headscale 0.29.5, it cannot be disabled; the report says to treat every SSH grant there as root-equivalent. Tailscale’s own advice is to review forwarding permissions and remove what you do not need.
3. Do not rely on check mode to fix this. Check mode adds an authentication step at session start. It does not constrain forwarding inside an established session. The report also says a successful check can cover multiple destinations for the check period, so one approval can amortize across the tailnet.
4. Use ordinary OpenSSH over Tailscale for sensitive hosts. The report says OpenSSH is clean for this privilege class because the post-auth child drops to the session user before the server loop. If you do not need Tailscale SSH’s identity features, disabling Tailscale SSH and running regular SSH over the tailnet removes this forwarding path.
5. Remove app-connector entitlements you do not need. For conn25, remove the capability from clients that do not require it. In Kubernetes, apply a default-deny egress NetworkPolicy to the connector namespace. On connector hosts, use a kernel-level destination allowlist. The report ships a mitigation script.
6. Audit serve and funnel. Remove any tailscale serve --tcp forward that targets a Unix socket, especially the agent’s own socket. Check for funnel configurations that were armed locally without the control-plane attribute.
7. Harden identity and persistence. Enable node-key expiry on server fleets, use TPM or Secure Enclave-bound state where possible, and enable Tailnet Lock. The report says the lock-disabled path was demonstrated end to end; the lock-enabled path captured the disable secret and signer material in transit but did not complete the disable. These controls raise the cost; they do not replace the policy fix.
8. Detect the race and the enrollment. Audit Unix-socket bind, unlink, and chmod operations in forwarding-allowed directories. Alert on rename storms. Baseline each device identity’s network endpoint and alert when one endpoint starts serving a second identity. Alert on authkey issuance and use outside change windows. For headscale, monitor memory and registration-cache churn.
9. If a device is compromised, delete it at the control plane. Reimaging is not containment. A root attacker can copy the node state file, and the copied identity remains valid until the device is deleted or its keys expire. Rotate authkeys and secrets reachable from the host, and review policy history for unauthorized route, DERP, or approver changes.
10. Patch when Tailscale ships. Tailscale recommends automatic updates so you pick up the fix when it is released. Until then, the configuration changes above are the mitigation.

Bottom line

Tailworm is not a reason to assume every Tailscale user is exposed, and it is not a nothingburger. It is a precise warning about what happens when a root-owned SSH server performs forwarding for an unprivileged session, combined with a policy model that can grant one compromised device a path to many others. The exploitability question is therefore not "can an outsider hit this from the internet?" It cannot. The useful question is "who can already reach whom, and what can a root-owned forwarding process do on the target?" If the answer is broad SSH rules and forwarding, fix that now. If the answer is per-pair grants and no forwarding, the report is a reminder to keep it that way.

Sources and References

• Tailworm: Tailscale v1.104.2 and headscale v0.29.5 security assessment, Erica Windisch, Cyberdione Labs
• Tailscale Security Bulletins, including TS-2026-004 and TS-2026-005 (fixed in 1.98.9) and TS-2026-013
• Tailscale SSH documentation and tailnet policy file syntax
• The Hacker News: Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers
• Brandefense: Tailworm, Tailscale Flaws and Who Is Exposed
• Hacker News discussion, including Tailscale engineer comments
• Tailscale VP Mike Shaver’s public response on Reddit
• headscale v0.29.6 release notes
• X discussion referenced in the report’s circulation

Related Reading

Enterprise Kubernetes DNS via Tailscale VPN