Researcher Erica Windisch of Cyberdione Labs has published Tailworm, a report with 11 numbered findings in Tailscale and the open-source headscale server. It reached Hacker News on 25 October 2026, with no coordinated disclosure and no fix. As of 25 October 2026 Tailscale has published no bulletin, CVE or fixed version for them, and the claims are the researcher’s lab results, not confirmed by Tailscale.
A commenter who says they work at Tailscale wrote on Hacker News that “we will have more details to follow”.
Last updated: 25 October 2026. We update this page when Tailscale publishes a bulletin or a fix.
What Does the Tailworm Report Claim?
The report says it tested unmodified software: tailscale 1.104.2, released on 21 October 2026, and headscale 0.29.5. The testing window ran from 22 to 24 October 2026. It gives no CVE ids and no patch status, and it lists interim mitigations for operators of unpatched deployments.
The 11 findings fall into five classes. Some concern headscale, and part of one finding concerns the DERP relay client that every Tailscale agent runs. The researcher rates most of them High or Medium-High.
The table below shows the researcher’s lab result and the fix status for each class. The second table says who is exposed and what an attacker needs first.
- Affected
- Unknown
Which Tailscale Features Are Exposed, and to Whom?
Each row names a feature and the people who run it. The middle column is the attacker’s starting point, which matters more than the rating. The last column repeats the researcher’s mitigation or the Tailscale documentation, where one exists.
| Feature and the researcher's rating | Who is exposed | What the attacker needs first | What to do |
|---|---|---|---|
| Tailscale SSH, High | Teams that use Tailscale SSH, where the researcher says port forwarding is on by default | One approved device and one SSH policy rule | Use per-pair SSH grants and deny forwarding in each rule |
| App connectors, High | Users of the experimental app connector feature | A device granted the connector capability | Remove the capability where unused and limit egress destinations |
| tailscale serve, High for one finding and lower for the rest | Anyone who forwards serve traffic to a Unix socket | A serve TCP forward that an administrator has set up | Remove forwards that target the agent’s own socket or other privileged paths |
| headscale server, Medium-High | Self-hosted headscale operators | Network access to the control server, no login | Set memory limits, restart supervision and rate limiting |
| DERP client, Medium-High | Clients that talk to a relay | A malicious relay that answers the client | No operator step in the report; watch for a Tailscale fix |
Is This Remote Code Execution From the Internet?
No, and the report does not claim that. For the SSH class it says the attacker already holds a foothold on one device. From there the researcher reports spread to every device the policy permits. That makes it lateral movement plus privilege escalation inside a tailnet, because Tailscale SSH runs as root.
In the lab, one hacked device reached root on other servers and could enroll a rogue node. The researcher says the app connector issue worries her most. A device with the connector capability can steer traffic to attacker-chosen destinations, such as cloud metadata and internal networks. Some commenters on Hacker News dispute how severe the findings are.
What Has Tailscale Said So Far?
We checked Tailscale’s security bulletins, its changelog, its blog and its GitHub releases on 25 October 2026. The newest bulletin is TS-2026-013 from 21 October and does not mention the report. The newest changelog entry is version 1.104.2, the version the researcher tested.
The same two areas had fixes earlier this year. The bulletins page lists TS-2026-004, SSH Unix socket forwarding ignored symlink permissions, and TS-2026-005, Serve Unix socket proxy targets not restricted to root. Both were published on 3 June 2026 and fixed in 1.98.9.
For headscale, version 0.29.6 came out on 24 October. Its release notes do not mention these findings.
The X post below is the post’s own wording. The report has 11 numbered findings in five classes, and one of them (finding 6) is mainly about headscale, the separate open-source control server.
International Cyber Digest (@IntCyberDigest) posted this on 25 October 2026. Read the original post on X.
What Can You Do Before a Fix Arrives?
These steps come from the researcher’s interim mitigations and the Tailscale SSH documentation. Tailscale has not commented on them. They fit a wider vulnerability management routine for a flaw with no patch.
- Rewrite SSH rules as per-pair grants, from one named source to one named destination. Remove identity-wide and tag-wide accept rules, and never allow privileged target accounts.
- On the Tailscale control plane, set the forwarding flags to denied in each rule action. On headscale 0.29.5 forwarding cannot be turned off, so treat every SSH grant as root-equivalent.
- Where a device does not need Tailscale SSH, run
tailscale set --ssh=falseon it. The documentation warns to confirm another way in first, or you may lose access. - Remove the connector capability from clients that do not need it. Add a kernel-level destination allowlist or a Kubernetes default-deny egress policy.
- Audit serve TCP forwards that point at Unix sockets, and remove any that target the Tailscale agent’s own socket or other privileged paths. Leave TS_SERVE_ALLOW_ALL_INTERFACES off, its default; the report says it exposes serve listeners outside the tunnel.
- For headscale, set memory limits with systemd MemoryMax, supervise restarts, put a rate-limiting proxy in front and restrict network exposure.
- Turn on node-key expiry for server fleets.
If you think a device is compromised, delete it at the control plane. The report says reimaging does not revoke keys that were already copied. If a node that signs for Tailnet Lock was compromised, rotate Tailnet Lock as well.