TL;DR
- Tailscale SSH is the embedded SSH server inside the Tailscale client: a device claims port 22 on its own Tailscale address, and one access rule decides which devices may open a session on it.
- A report called Tailworm, published on 25 October 2026 by Erica Windisch of Cyberdione Labs, describes eleven findings in five classes against Tailscale 1.104.2 and headscale 0.29.5, all reproduced in a lab between 22 and 24 October 2026.
- The first class covers Tailscale SSH itself: unix-socket forwarding runs as root inside tailscaled, so an ordinary approved session can dial docker.sock, /run/systemd/private or tailscaled.sock on the target.
- Per-pair access rules and hardware-bound device keys were the two controls that stopped the spread in testing, and the report measured a spread of under a second per hop without them.
- Tailscale's vice president of engineering says the company has the report, has found issues it is working to fix, is still working out which setups are affected, and is "not recommending that everyone disable Tailscale SSH"; no bulletin, CVE or fixed version existed when the report went public.
- The operator work runs to four checks: rewrite SSH rules as single source-to-destination pairs, turn forwarding off where the product allows it, remove app-connector permissions and serve forwards that point at a unix socket, and turn on node-key expiry.
When a company runs its servers on a mesh VPN, the access rule becomes the security boundary. Tailscale SSH authenticates a device over WireGuard with node keys, then applies the tailnet's access-control policy to the session. The Tailworm report argues that this design weakens security-in-depth: highly privileged processes absorb functions that OpenSSH isolates through privilege separation, while network security boundaries extend beyond what the products advertise.
What the Tailworm report tested
The report assesses released software inside a lab. Erica Windisch of Cyberdione Labs tested Tailscale client agent version 1.104.2 and headscale version 0.29.5, the self-hosted control server some networks run in place of the hosted service, between 22 and 24 October 2026. Every finding was reproduced on unmodified builds, with organisational identifiers redacted.
The audit covers the tailscaled daemon, its embedded SSH server, its Serve and Funnel surface, its DERP relay client, the headscale control server, the shared gliderssh library and the experimental conn25 app connector. The report groups eleven findings into five classes: Tailscale SSH socket forwarding; conn25 app-connector traffic sent beyond authorized destinations; unauthenticated headscale resource exhaustion that can crash the control server and block onboarding; an unbounded DERP-client read that exhausts agent memory; and Tailscale Serve failures that can expose the local administrative API or let some requests bypass per-mount authorization. Readers who want to check the work will find no public proof-of-concept code: the report says the kits went to Tailscale's security contact.
The head of the Tailworm report at tailworm.com, retrieved 2026-10-25, whose summary table names each finding class, the mechanism that breaks, the attacker requirement and the principal outcome. The first row describes unix-socket forwarding inside Tailscale SSH.
How an approved session reaches root on another server
Tailscale SSH works through device identity. When the feature is enabled, the client claims port 22 on the device's Tailscale address, and the connection is authenticated over WireGuard with node keys; an access control policy then decides whether the session is allowed. Tailscale SSH completes authentication from the device identity established by WireGuard. That design simplifies operation and makes a single policy mistake expensive.
The finding sits in what the SSH server does after the session opens. Unix-socket forwarding, the ssh -L and ssh -R options most administrators use for port tunnelling, is handled inside tailscaled, and tailscaled runs as root. Path checks and file operations therefore execute with root rights, and the report describes races plus a missing privilege drop that let an ordinary session replace, dial or delete privileged resources. A rule that admits an unprivileged account still produces a session that can reach docker.sock, /run/systemd/private or tailscaled.sock.
Netics editorial diagram of the mechanism: the policy admits a device and an ordinary account, while the forwarding code inside tailscaled runs with root rights and reaches the sockets that control containers, the init system and the daemon itself.
The second class widens the same idea beyond one host. The experimental conn25 app connector accepts the destinations a permitted user chooses, and network ACLs are never consulted for the destination that traffic actually reaches. On a cloud host that path ends at the metadata service; inside Kubernetes it ends at every cluster service. That is a policy-visibility problem in the same family as the socket problem: the thing being protected is reachable through a component that the rule did not describe.
The habit that makes this worth checking on a small estate is ordinary. Somebody enables ssh -L to reach a database console, or ssh -R to expose a local service to a colleague, and nobody revisits the rule that allowed the session afterwards. Each of those habits widens what one compromised laptop can do.
Tailscale's own SSH documentation at tailscale.com/kb/1193/tailscale-ssh, retrieved 2026-10-25, cut below the embedded video. The page states that Tailscale SSH lets Tailscale manage authentication and authorisation for SSH connections in a tailnet, and that the access control policies decide which devices may connect.
Why per-pair access rules stopped the spread
The report's wormable characterization depends on a specific chain of conditions: an attacker already controls a policy-permitted device, Tailscale SSH is enabled on reachable targets, and forwarding is available. Its evidence consists of the report's own lab reproductions on two named releases; independent reproduction and production evidence remain open questions in the cited record. The disclosure record also leaves remediation status unsettled: Tailscale acknowledged issues and was still determining which configurations were affected. The measurement is a lab result: one compromised device spread to every device the policy allowed, with no passwords, no stolen keys and no user action, at under a second per hop. Nobody has reported the same behaviour on a production network, and the report says as much.
Two structural limits held during the tests. The first is rule shape. Access rules written as single source-to-destination pairs, naming one device and one target, bounded the spread by themselves, because a compromised device could only reach the targets its own pair named. Rules that grant access by identity or by tag produced the wide graph. The second limit is key custody: device credentials bound to a TPM or a Secure Enclave prevented the identity theft that turns a temporary foothold into a persistent one, and Tailnet Lock stopped the final enrolment step even where the enrolment key itself had been captured.
Netics editorial diagram on the limit that held: the enrolment key was still captured with Tailnet Lock enabled, and adding the attacker node to the tailnet then failed.
What Tailscale says about the report
Tailscale has not published a bulletin for these findings. Its security bulletin page, read on 25 October 2026, lists TS-2026-013 from 21 October as the newest entry, and that one covers eight compromised eMudhra TLS intermediate certificates. The Hacker News reports no CVE identifier and no fixed version either, and the report's author describes the disclosure as reported but not coordinated.
The company has answered in public. Mike Shaver, Tailscale's vice president of engineering, wrote on Reddit that Tailscale had received the report, had already been looking at the same areas with outside security specialists, and had found issues it is working to fix. He said the company is still working out which setups are affected. He also said Tailscale is "not recommending that everyone disable Tailscale SSH."
Tailscale's security bulletin list at tailscale.com/security-bulletins, retrieved 2026-10-25. The newest entry is TS-2026-013 from 21 October 2026 on eight compromised eMudhra TLS intermediate certificates; nothing on the Tailworm findings appears above it.
Four checks an operator can run now
The mitigations that cost nothing are available today; apply each one. Start with the SSH rules: list every rule with an accept action, and rewrite each one as a pair that names one source device and one destination. Rules built on tags or on identity groups are the ones that produced the wide graph in the lab.
Then decide about forwarding. On the hosted service, forwarding can be switched off per rule. On headscale 0.29.5 the report says forwarding cannot be turned off at all, which turns every SSH grant on such a network into a grant of root on the target; that is the sharpest sentence in the whole document for anyone self-hosting the control plane. Where forwarding has to stay, check mode adds a login step in front of a session; the forwarding path remains capable of the privilege escalation described by the report.
The remaining checks sit in the same family. Remove app-connector permissions from devices that have no reason to hold them, and delete every tailscale serve forward that points at a unix socket. Turn on node-key expiry so a stolen key ages out, and enable automatic updates so the next bulletin lands without a project. If a device is compromised, delete it at the control plane; a revoked device cannot use a socket it can no longer reach.
Netics editorial card on the measured rate: with policy-granted Tailscale SSH and the socket findings, the lab spread to every permitted device at one second or less per hop, with no password and no stolen key.
The inventory question underneath all of this is the one worth writing down: which devices hold an SSH grant, which of those grants permit forwarding, and which devices can use an app connector. That list is short on most networks, and keeping it current gives you a policy that describes your estate. This inventory also informs alert design that explains an incident, where the value sits in the field somebody can act on.
Originally published on the Netics blog.
Top comments (0)