Tailscale vulnerability: Tailworm alleges 11 unpatched flaws

Key takeaways

• Researcher Erica Windisch of Cyberdione Labs published "Tailworm" on 25 October 2026, describing 11 findings in Tailscale v1.104.2 and headscale v0.29.5.
• The most serious claim: if a Tailscale SSH rule allows port forwarding, a user on an approved device can make the root-run tailscaled daemon reach root-only sockets on the target.
• The release was "reported but not coordinated", according to Windisch. As of 26 October there is no CVE, no Tailscale security bulletin and no fixed version.
• Tailscale says it received the report, had already been reviewing the same areas with outside specialists, and is working on fixes. It is not advising every customer to switch off Tailscale SSH.
• Admins can reduce exposure now: narrow SSH rules to single source-destination pairs, stop forwarding where possible, enable Tailnet Lock and key expiry, and remove unneeded serve and app connector settings.

A new Tailscale vulnerability report, Tailworm, claims a user on one approved device can reach root on other machines when Tailscale SSH rules allow port forwarding. Tailscale is working on fixes, but there is no CVE or patched release yet.

The report does not describe an internet-facing attack. Every SSH path in it starts from a device the attacker already controls and that the network's access rules already trust. That makes it a lateral-movement problem: it matters most for companies whose Tailscale policies give broad SSH access across many servers.

What the Tailworm report claims

The report, published at tailworm.com, lists eleven findings across Tailscale SSH, the tailscale serve feature, the experimental "conn25" app connector, the DERP relay code and headscale, the open-source control server. Windisch rates eight of them High or Medium-High. The report states that the researchers are not affiliated with Tailscale and were not paid for the work.

The headline chain uses three SSH findings together. According to the report, standard SSH local forwarding (-L) to a Unix socket makes the root-run tailscaled process connect to sockets that only root should reach. Remote forwarding (-R) can replace root-owned sockets so the attacker impersonates the service behind them. A time-of-check to time-of-use (TOCTOU) race lets the checked path be swapped before the real connection happens.

The report says no sudo rights or docker group membership are needed on the target. In the lab, the chain was also used to capture an enrollment key and join a rogue machine to the tailnet as a trusted node.

Main findings at a glance

Source: Tailworm security assessment, Cyberdione Labs, October 2026. Ratings are the researcher's own and have not been confirmed by Tailscale. Findings 8 to 11 cover serve, Funnel and HTTP/2 issues rated Medium or lower.

Which Tailscale setups are exposed

The SSH findings apply only where all of these are true: Tailscale SSH is enabled on the target, an SSH rule lets the attacker's device connect to it, and that rule permits forwarding. On headscale, the report says forwarding is granted on every accepted SSH session and cannot be switched off in v0.29.5, so any headscale SSH grant should be treated as root on the target.

Tailnet Lock changes the picture, but only partly. The report says the rogue-node step was demonstrated end to end only on tailnets without Tailnet Lock, which is the default. With the lock enabled, the researchers say they captured disablement secrets and signer-key material in transit but did not actually disable the lock.

Check mode is not a fix. The report notes that check mode only gates the start of a session, so it does not limit what forwarding does once a session is open. Tailscale's own documentation describes check mode as requiring users to re-authenticate before an SSH connection is established.

The "worm" label is disputed. Windisch argues that one compromised device can spread to every device the rules allow. Several commenters on Hacker News pushed back, with one calling it "not wormable in the traditional sense", because each hop still needs an SSH rule that permits it.

What Tailscale has said so far

Mike Shaver, Tailscale's vice president of engineering, wrote on Reddit that the company had received the report and had already been examining the same areas with outside security specialists, finding issues it is now working to fix, according to The Hacker News and ThreatTicker. He said Tailscale was still working out which configurations are affected and was not recommending that all customers disable Tailscale SSH.

A Tailscale engineer posting on Hacker News added that "we will have more details to follow". No timeline was given. The company's public security bulletin page lists TS-2026-013, dated 21 October and unrelated to Tailworm, as its newest entry; that fix shipped in v1.104.2, the version Windisch tested.

This is not the first time the area has needed work. Tailscale's bulletins show earlier SSH fixes in 2026, including TS-2026-004 (a Unix-socket symlink bypass in SSH forwarding, fixed in 1.98.9) and TS-2026-009 (usernames with leading dashes that could open a root session, also fixed in 1.98.9).

What admins can do now

Until Tailscale publishes a bulletin and a fixed release, these steps come from the Tailworm report and from Tailscale's documentation. None of them requires waiting for a patch.

1. Narrow SSH rules. Replace rules that grant SSH from a whole group or tag to many servers with single source-to-destination pairs. Remove root and other privileged accounts from the users list where you can. The report says narrow pairs stopped propagation in testing.
2. Stop forwarding where possible. ThreatTicker's summary says forwarding can be disabled per rule on Tailscale's hosted control plane but not on headscale 0.29.5. Tailscale's public SSH reference lists only the fields action, src, dst, users, checkPeriod and acceptEnv, so confirm the setting with Tailscale before relying on it.
3. Consider pausing Tailscale SSH on sensitive hosts. Windisch recommends disabling Tailscale SSH and app connectors. Tailscale does not go that far, but hosts that hold credentials or enrollment keys are the obvious place to start.
4. Enable Tailnet Lock and node-key expiry. The rogue-node step worked end to end only without Tailnet Lock in the lab.
5. Clean up serve and connectors. Drop any tailscale serve forward that points to a Unix socket, and remove app connector entitlements from devices that do not need them.
6. Harden self-hosted headscale. Keep it off the open internet where possible and add memory limits, restart supervision and rate limits.
7. Turn on auto-updates. Running tailscale set --auto-update on Linux hosts means a fix lands without manual work once released.
8. Revoke, do not just reimage. If you suspect a device is compromised, delete it in the admin console. The report warns that reimaging alone does not revoke copied keys.

What is still unconfirmed

Readers should keep the gaps in view. Tailscale has not confirmed the specific technical claims. The proof-of-concept code has not been made public. No other researcher has publicly reproduced the findings. The severity ratings are the researcher's own. As RuntimeWire noted, the lab demonstrations do not show that any customer system has been compromised.

The decision to publish without coordinated disclosure is itself part of the story. Windisch says she sent the report and proof-of-concept to Tailscale's security contact before going public, and the report argues that "infrastructure is vulnerable today". The debate echoes recent arguments over how open-source projects handle bug disclosure.

What it means

For most small tailnets with a handful of devices and tight rules, the practical risk is limited: an attacker first needs a trusted device and an SSH rule that reaches the target. The exposure grows with the kind of setup many companies use, where one tag or group gets SSH into every server.

The lasting lesson is that a mesh VPN is only as segmented as its access policy. Teams already working through emergency patch cycles or tracking supply-chain intrusions that move from one foothold will recognise the pattern: tighten the rules now, then patch fast when the fix arrives. Bullquill will update this page when Tailscale publishes a bulletin, CVE or fixed version. More coverage is on our Tailscale topic page.