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 at the time. Since then Tailscale has published four security bulletins and released version 1.104.4, which fixes most of the findings. The claims began as the researcher’s lab results; Tailscale’s bulletins now confirm the ones they cover.
A commenter who says they work at Tailscale wrote on Hacker News that “we will have more details to follow”.
Update 28 October 2026: Tailscale has shipped fixes for most of the report. Version 1.104.4 appeared on GitHub on 28 October, and four bulletins dated 26 October (TS-2026-014 to TS-2026-017) name it as the fixed version. The app connector finding and the headscale side of finding 6 are not fully fixed. The details are in the Tailscale section below.
Last updated: 28 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. When first published it gave no CVE ids and no patch status, and it listed interim mitigations for operators of unpatched deployments. The researchers have since added a fix status to each finding.
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
- Fixed
- 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 forwarding comes with every SSH grant on headscale and is set per rule on Tailscale’s service | One approved device and one SSH policy rule | Update to 1.104.4, use per-pair SSH grants and deny forwarding in each rule |
| App connectors (conn25), High | Users of conn25, the next-generation connector that Tailscale says is not released | 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 | Update to 1.104.4 and 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 | Update clients to 1.104.4, which the researchers list as the client-side 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, 26 and 28 October 2026. On 26 October Tailscale posted an investigation update. Its bulletins page now lists four bulletins dated 26 October, TS-2026-014 to TS-2026-017, each fixed in version 1.104.4 or newer.
On 28 October its blog post Tailscale SSH: Findings and fixes named the report and said the fixes were available. Version 1.104.4 was published on GitHub on 28 October at 01:05 UTC. As of that day the four bulletins show no CVE id. The bulletins do not use the report’s finding numbers; the matches below are our own reading.
- TS-2026-014, SSH Unix socket forwarding: Tailscale says forwarding was done as root. Peers allowed to forward could reach root-only sockets such as the Docker socket or the
tailscaledlocal API. By our reading this matches findings 1 to 3. Before updating, settingTS_SSH_DISABLE_FORWARDING=1in the tailscaled environment and restarting the service turns off forwarding without turning off Tailscale SSH. - TS-2026-015, SSH session memory: an authenticated peer could make
tailscaledgrow without bound until it was killed, which disrupts every Tailscale connection on that node. By our reading this matches finding 5. - TS-2026-016,
tailscale serveUnix backends: TCP forwards to Unix sockets were dialed as root and the symlink guard ran only at configuration time. Tailscale says the first weakness allowed full node takeover through the local API. Affected nodes are those where a local operator can write serve configuration or local users can write to backend paths. By our reading this matches findings 7 and 8. - TS-2026-017, HTTP/2 shared serve context: capability headers from one mount could reach another mount on the same TLS connection. It affects nodes with two or more mounts that need different capabilities. By our reading this matches finding 11.
Tailscale’s blog says the SSH flaws need an existing foothold on an authorized device, and that an attacker could reach only machines the policy file already allowed SSH to. It calls the pattern lateral movement within the policy and says it does not describe a self-replicating worm.
Of the five Serve and Funnel findings, it says three were bugs fixed in 1.104.4 and two work as designed. Those two are the Funnel attribute check, which needs local admin access to bypass, and TS_SERVE_ALLOW_ALL_INTERFACES, an opt-in setting.
In its 26 October update Tailscale said it was not recommending that everyone disable Tailscale SSH. It advised reviewing SSH access policies and, where needed, tightening them.
On app connectors, Tailscale says the finding concerns Conn25, the next generation, which is still pre-production and unreleased. It says the stable app connectors available today are not affected. The researchers list the Conn25 fix as an open pull request as of 28 October.
The commit list of the release includes “fix serve app caps leaking across mounts” and “update gliderssh for resource exhaustion fixes”. We described two commits with those titles on 26 October as unreleased. It also lists “route SSH forwarding through the privileged monitor”. Treat 1.104.4 or newer as the fix, and use the steps below for what it does not cover.
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. Tailscale’s changelog puts the Serve fix in version 1.98.9 (14 July) and the SSH fix in version 1.98.10 (28 July).
For headscale, version 0.29.6 came out on 24 October and is still the newest release on 28 October. Its release notes do not mention these findings.
A headscale project collaborator opened draft pull request 3586 on 26 October, citing Tailworm. It proposes bounding pending authentication without evicting sessions, which by our reading matches the pending-approval part of finding 6. It was still open on 28 October.
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.
How Big Is the Reaction to Tailworm?
We counted the posts on X that name Tailworm, using a paid X search run on 26 October 2026. It returned 186 posts from 25 October to the morning of 26 October (UTC). The view counts X shows add up to about 373,000, of which about 343,000 are on posts from 25 October. Most posts are in English (112), Japanese (43) or Chinese (13).
Three themes stand out in our reading of the posts.
- Critics object that the report skipped coordinated disclosure and left no fix.
- Some practitioners say the findings need an opt-in feature, such as Tailscale SSH with forwarding, and do not touch a default install.
- Others publish ways to check your own setup.
The report says that on headscale 0.29.5 forwarding comes with every accepted SSH session and cannot be turned off, while on Tailscale’s own service it is set per rule. Whether it is on in a normal setup is one of the points commenters dispute.
This researcher (@GrahamHelton3) posted it on 25 October 2026. Read the original post on X. It is one expert’s view, not a finding of ours.
What Should You Do Now That a Fix Exists?
The first step comes from Tailscale’s bulletins and the rest from the researcher’s interim mitigations and the Tailscale SSH documentation. They fit a wider vulnerability management routine.
If you run Tailscale yourself, the six-check tailnet audit with commands goes through each feature in turn.
- Update every device that runs Tailscale SSH or serve to 1.104.4 or newer, and check with
tailscale version. If you cannot update yet, setTS_SSH_DISABLE_FORWARDING=1in the tailscaled environment and restart the service, as TS-2026-014 advises. - 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. Tailscale also suggests SSH check mode for sensitive systems.
- 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, even though Tailscale says the stable app connectors are not affected. 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. Continuous attack surface management can confirm whether your headscale server answers on the public internet.
- 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.
Frequently Asked Questions
Should I turn off Tailscale SSH?
Only on devices that do not need it. The Tailscale documentation gives the command tailscale set --ssh=false and warns to confirm another way into the device first. The researcher also suggests per-pair SSH grants. Tailscale's 26 Oct update said it was not recommending that everyone disable Tailscale SSH.
Is there a CVE for Tailworm?
The report gives no CVE ids. As of 28 Oct 2026 Tailscale's four bulletins for these findings (TS-2026-014 to 017) show no CVE id.
Does reimaging a compromised device remove the risk?
The report says no. Keys that were already copied stay valid, so delete the device at the control plane.
Has Tailscale fixed Tailworm?
Mostly. Tailscale 1.104.4, published on GitHub on 28 Oct 2026, fixes the SSH and Serve issues in bulletins TS-2026-014 to 017. The Conn25 connector fix and the headscale side of finding 6 are still open, and Tailscale says two Serve and Funnel items work as designed.
