Erica Windisch of Cyberdione Labs published the Tailworm report on October 25. The tests ran against Tailscale 1.104.2 and headscale 0.29.5 in a lab over three days. The attack needs two things: Tailscale SSH configured to allow port forwarding, and a foothold on one device that the network’s rules permit to connect to the target. Tailscale does not create that first foothold.

What the report claims

Tailscale SSH does not check a password or key in the usual way. It identifies the device, and a single access rule decides whether that device may open an SSH session to a target. The report describes three escalation paths:

• An ordinary SSH session caused the root-level Tailscale process to connect to a system socket that only root should access. The test gained root and read the system password file.
• A second method replaced a root-owned socket with the attacker’s, allowing direct root command execution against certain services.
• A third raced the system between checking a file path and using it, captured an enrollment key, and joined an attacker-controlled machine to the network as a trusted server.

The last step completed only on networks where Tailnet Lock was not enabled. Windisch describes the result as “wormable”: one compromised device could spread to every device the access rules allow, with no passwords, no stolen keys, and no user action, in under a second per step. That spread was measured in a lab, not observed on real networks. The report contains 11 findings in total, covering app connectors, serve, the DERP relay and headscale.

What Tailscale says

Mike Shaver, Tailscale’s vice president of engineering, wrote that the company had received the report, had already been examining the same areas with outside security specialists, and had found issues it is working to fix. Tailscale is still determining which configurations are affected and said it is not recommending that everyone disable Tailscale SSH. It has since said a patched client is close, and that its own investigation found privilege-escalation issues it considers serious, though it has not confirmed every specific technical claim.

Who is exposed

This is not a remote, unauthenticated attack. It requires a device already on the tailnet and an access rule that lets that device reach the target. The exposure is highest where:

• Tailscale SSH allows port forwarding on broad rules.
• You run headscale 0.29.5, where forwarding cannot be disabled at all. The report says every SSH grant there should be treated as giving root on the target.
• ACLs allow many sources to many destinations, so one foothold can reach the fleet.
• Tailnet Lock is disabled, removing the final barrier in the enrollment-key chain.
• Device keys are not bound to hardware such as a TPM or Secure Enclave.

What to do now

1. Audit every Tailscale SSH rule. On the hosted service, turn off forwarding per rule where it is not needed.
2. On headscale 0.29.5, assume any SSH grant is root on the target until you upgrade or restrict the rule.
3. Rewrite ACLs as single source-to-destination pairs instead of broad groups.
4. Enable Tailnet Lock and verify it is actually active.
5. Prefer hardware-bound device keys.
6. Patch the client when the fix lands and watch Tailscale’s security bulletins.
7. Monitor for unexpected devices, new enrollment keys and unusual root sessions.

What remains unproven

The findings are lab-only, from one researcher, and have not been independently reproduced. The proof-of-concept code is not public; Windisch says she provided it to Tailscale’s security contact. Some researchers have questioned the “wormable” description while calling the root-access finding serious. The app-connector finding may matter more for some organizations: the experimental conn25 feature can send traffic to destinations the security team never approved, including a cloud provider’s metadata service, which can hand out server credentials.

Sources: The Hacker News, Tailworm report, Tailscale security bulletins.