A security researcher has published a report — dubbed “Tailworm” — that describes multiple vulnerabilities in Tailscale’s SSH implementation and related components which, in lab tests, allowed an attacker on one compromised device to rapidly gain root on other machines across a private Tailscale mesh. The findings raise questions about how privilege is handled inside tailscaled and call attention to administrative rules and configurations that can turn a single foothold into broad, automated lateral movement.
Key findings from the Tailworm report
The Tailworm report, published October 25, 2026 by Erica Windisch of Cyberdione Labs, lists 11 findings in five groups covering Tailscale’s SSH server, serve and app connector features, the DERP relay client, and the open-source headscale control server. The researcher tested Tailscale 1.104.2 and headscale 0.29.5 between October 22 and October 24, 2026. The report assigns severities and describes what an intruder needs for each finding:
| # | Finding ID | Component | What breaks | Severity | What an intruder needs |
|---|---|---|---|---|---|
| 1 | F1 (T3) | Tailscale SSH | Local socket forwarding (ssh -L) runs as root and reaches root-only sockets. In the lab, this gave root and read /etc/shadow. | High | An SSH rule that allows local forwarding |
| 2 | F2 (T2) | Tailscale SSH | Remote socket forwarding (ssh -R) replaces root-owned sockets. This allowed root code execution through a command daemon. | High | An SSH rule that allows remote forwarding |
| 3 | F3 (T2-RACE, T3-RACE) | Tailscale SSH | A timing gap lets a path check be defeated before the file action runs. In the lab, this led to a rogue node joining the network. | High | Ordinary SSH session with forwarding allowed |
| 4 | F4 (C1) | App connectors (conn25) | A user entitlement allows any outbound destination through the connector. This reached cloud metadata and Kubernetes services. | High | An ordinary app entitlement |
| 5 | F5 (T1) | Tailscale SSH | Session churn causes the root daemon to run out of memory in a loop. About 536 MB was allocated in 7 seconds. | High | An authenticated SSH session |
| 6 | F6 (C2, C3, C4) | headscale and DERP client | Unauthenticated registrations can evict pending device approvals. A malicious relay can also force a client to read up to 1.34 GB. | Medium-High | Internet access to headscale, or a hostile relay |
| 7 | F7 (SERVE-F-1) | tailscale serve | A TCP forward to the local API socket lets a remote peer write to the local API. In the lab, a settings change returned success, which means node takeover. | High | Serve configuration by the operator, plus an allowed peer |
| 8 | F8 (SERVE-F-2) | tailscale serve | A symlink swapped after setup defeats the socket guard, which allows root dials to root-only sockets. | Medium (contained) | Local write access to the backend path’s directory |
| 9 | F9 (SERVE-F-3) | Funnel | Funnel access depends only on the peer capability and local settings. The report treats this as a threat-model issue. | Medium | A funnel-enabled node |
| 10 | F10 (SERVE-F-4) | tailscale serve | The TS_SERVE_ALLOW_ALL_INTERFACES setting exposes serve outside the tunnel bind. The report calls this a configuration note. | Configuration note | Nodes that set this variable |
| 11 | F11 (SERVE-F-5) | tailscale serve | A race in shared serve context lets one mount’s permissions carry over to another. | Medium, or Low-Medium without header authorization | Serve setups that use header-based authorization |
How the most severe SSH issues work
According to the report, tailscaled — the privileged background daemon that implements Tailscale SSH — performs socket operations with root privileges. When SSH rules permit Unix socket forwarding (local or remote), those forwarding operations can open, replace, or connect to sockets that are normally root-only. In controlled tests this allowed an attacker with an ordinary SSH session and forwarding rights to read /etc/shadow, execute code as root, or enroll a rogue node that looked like a trusted peer. A timing/race weakness also let path checks be bypassed in some operations.
Other affected components
Beyond SSH, the Tailworm findings cover experimental app connectors (conn25), tailscale serve, the Funnel feature, DERP relays, and headscale. Notable issues include an app connector entitlement that can reach cloud metadata endpoints and internal Kubernetes services, unauthenticated registrations and memory exhaustion possibilities in headscale, and serve forwards that expose local admin interfaces when directed at Unix sockets.
Why this changes the threat model
Tailscale creates a mesh where devices trust each other according to policy, and every device receives a list of peers. The researcher argues that this design means a single compromised device can become a launchpad for rapid lateral movement if access rules are too broad. In the lab, per-pair access grants (explicit one-source-to-one-destination rules) were the control that stopped the spread. The report notes that threat actors have already used Tailscale for movement in real incidents, and that defenders should treat trusted-device assumptions with more caution.
Practical mitigations for administrators
Because no official patch or CVE appeared in the report date, the researcher and the article recommend interim steps drawn from the Tailworm findings and Tailscale’s documentation:
- Replace broad identity-wide or tag-wide SSH grants with per-pair grants that name a single source and a single destination.
- Set forwarding to denied in any rules where that setting exists.
- Turn off Tailscale SSH on devices that don’t need it (for example: tailscale set –ssh=false), but verify alternate access before doing so to avoid lockout.
- Remove unused app connector permissions and serve forwards that point to Unix sockets.
- Turn on node-key expiry.
- If a device is compromised, remove it from the control plane; reimaging alone does not revoke keys that were already copied.
Context and prior fixes
This isn’t the only Tailscale SSH concern this year: in July 2026 Tailscale fixed TS-2026-009, a bug where usernames starting with a dash could cause account lookups to return the root account; that issue was fixed in version 1.98.9. The Tailworm report emphasizes that Tailscale’s SSH path differs from OpenSSH’s layered privilege model — keeping a highly privileged process in charge rather than dropping privileges — and that this design has consequences for attack surface.
Caveats and what to watch next
The Tailworm results come from lab tests; some commentators dispute the practical severity of every finding. Tailscale had not published a bulletin or fixed versions as of the report date, and the report contains detailed reproduction steps and severity descriptions that defenders should review directly. The researcher also highlights non-code risks: credentials have been abused in the past — Tailscale reported that an AI agent used a stolen credential to enroll 181 nodes during the Hugging Face intrusion, though Tailscale said no vulnerability was exploited in that incident.
What defenders should do now
Teams using Tailscale SSH should immediately review SSH ACLs and capability grants, apply the interim mitigations above, and monitor Tailscale’s official security bulletins for patches or CVEs. Review serve and connector configurations, audit node lists for unexpected peers, and consider temporarily disabling features that expose Unix sockets or allow broad forwarding until fixes are released. Finally, treat credential hygiene and key management as important as code fixes: stolen or copied keys can bypass many controls.
Licensed under CC BY-ND 4.0 International