Researcher Erica Windisch of Cyberdione Labs published a report called Tailworm on 25 October describing 11 findings across Tailscale and the self-hosted headscale server. The most serious one lets a user who is already permitted to open a Tailscale SSH session reach root on the target server.
What happened
Tailscale SSH does not check a password or a key. It identifies the device and applies a single access rule. The report found that when SSH port forwarding is allowed, the root-level tailscaled process performs the forwarding on behalf of the logged-in user. An ordinary session can therefore reach sockets only root should touch, such as the Docker socket.
Windisch demonstrated three routes to root in a lab: a forwarding session that made tailscaled connect to a root-only system socket, a socket swap that allowed direct root command execution, and a file-path race that got around the check added in the earlier TS-2026-004 fix. A further stage captured a device enrolment key and joined an attacker machine to the tailnet, which completed only on networks without Tailnet Lock.
The tests ran against Tailscale 1.104.2 and headscale 0.29.5 between 22 and 24 October. As of 26 October Tailscale had published no security bulletin, no CVE identifier and no fixed release for the findings. Engineering vice president Mike Shaver confirmed on Reddit that the company had received the report, was already working in the same areas with outside specialists, and was not recommending that everyone disable Tailscale SSH.
Who is affected
Anyone running Tailscale SSH on Linux or macOS hosts, plus app connectors, tailscale serve and self-hosted headscale.
- Networks where Tailscale SSH access rules allow port forwarding.
- headscale 0.29.5 deployments, where forwarding cannot be turned off at all.
- Networks with broad access rules written by identity or tag instead of one device to one target.
- Networks without Tailnet Lock, where the enrolment step completed in testing.
No attack against a real network has been reported, no other researcher has publicly reproduced the findings, and Tailscale has not confirmed the specific technical claims. This is lab work published without a coordinated fix.
What to do now
Until a fixed release ships, treat every Tailscale SSH grant as root on the target, and rewrite your rules until that statement is true.
- Rewrite SSH rules as single source-to-destination pairs naming one device and one target. In testing, per-pair rules were the control that stopped spread.
- Turn off SSH port forwarding per rule on the hosted service. On headscale 0.29.5 no setting exists, so narrow the grants instead.
- Remove app connector permissions from devices that do not need them, and delete any tailscale serve forward that targets a Unix socket.
- Enable node-key expiry, and enable Tailscale SSH check mode as an extra barrier in front of the escalation.
- If a device is compromised, delete it at the control plane. Reimaging does not revoke keys already copied off it.
What this means for South African businesses
Tailscale has become a common shortcut for reaching a NAS, a router or an internal server without exposing a VPN to the internet, and that convenience is exactly why this matters locally. The flaw does not open anything to the internet; it multiplies the value of one phished laptop, turning a single compromised staff machine into root on everything the access rules allow it to reach. My read is that most SME tailnets are built with broad tag-based rules and no Tailnet Lock, which is precisely the shape this attack needs.
The full report is at tailworm.com, with coverage at The Hacker News.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.