Tailworm report alleges 11 Tailscale and headscale flaws

Tailscale and headscale users should read this one with care rather than alarm. An independent researcher published a long report, which reached Hacker News on October 25, alleging 11 problems in Tailscale’s client and the headscale control server, and no fix had shipped when we checked. We read the full report, looked at Tailscale’s public commits and security bulletins, and read the Hacker News discussion, including a reply from a Tailscale employee. This article covers what the report claims, what Tailscale has said or done, how far the claims can be trusted for now and what operators can do. Everything about the findings is the author’s account. We ran none of it, and we left out how to reproduce any of it.

What is the Tailworm report?

A security assessment by Erica Windisch of Cyberdione Labs Corporation, published at tailworm.com. It covers Tailscale client v1.104.2 (released October 21), headscale v0.29.5, the gliderssh library both use and the experimental conn25 app-connector feature. The testing window was October 22 to 24, and the author says every finding was reproduced in a lab on unmodified released software. The report calls itself independent and unpaid and says it is not affiliated with Tailscale. It also argues that infrastructure is vulnerable today and that quick awareness will speed remediation, which is the author’s stated reason for publishing before any fix. The 11 findings carry the author’s own labels, not CVE numbers.

What does it claim?

In the report’s own grouping:

• Tailscale SSH (findings 1 to 3): unix-socket forwarding (ssh -L and ssh -R) does its path checks and file operations as root, and the report says races let an ordinary session replace, dial or delete privileged resources. It rates all three High. The stated requirement is one approved device and one SSH policy rule, with forwarding granted automatically on headscale and per rule on Tailscale’s hosted service. The claimed outcomes include root on the target and capture of the keys that enroll new devices.
• App connectors (finding 4): the experimental connector accepts attacker-chosen destinations without validation, and network ACLs are not consulted for the real destination. The report says this reaches cloud metadata services, internal networks and, in Kubernetes, every cluster service. In the Hacker News thread the author says this is the one that worries them most.
• Memory exhaustion (findings 5 and 6): a gliderssh session behavior that can make the root tailscaled run out of memory, and unauthenticated memory growth in headscale plus an unbounded read by the relay (DERP) client. These are availability problems. The headscale one needs only internet reachability, the report says.
• tailscale serve (findings 7 to 11): a TCP forward to a unix socket lacks a guard the HTTP path has and can expose the local administrative API to a peer, a related guard is checked only at configuration time, funnel entitlement is enforced only by local config and peer capability, an environment variable can expose serve beyond the tunnel and a race lets one mount’s capabilities leak into another. Severities range from High to a configuration note.

The report also lists negative results it measured, such as an app-connector route to other tailnet nodes that WireGuard’s own routing blocked, no memory-corruption path from the out-of-memory cases and no crashes in about 117 million fuzz executions. It compares the SSH forwarding class with OpenSSH and Dropbear and says Dropbear’s CVE-2025-14282 is a precedent.

What has Tailscale said or done?

Little in public so far, and some of it is indirect. What we found:

• No bulletin or release. Tailscale’s security bulletins page lists TS-2026-013 on October 21, the eMudhra certificate issue, as the newest entry, and the latest client release is v1.104.2 from October 21, before the testing window ended. The headscale v0.29.6 release notes from October 24 mention the eMudhra rejection and dependency updates, not this report.
• A reply on Hacker News. A user identifying as working at Tailscale wrote that it had been a long day and more details would follow. On the enumeration claim they said some of it may be a headscale difference, because Tailscale’s control plane trims a node’s view so two nodes with no allowing rule do not see each other. We cannot confirm either side of that exchange.
• Commits. Between October 23 and 25 the tailscale/tailscale main branch received a set of changes cited to one internal ticket, tailscale/corp#50380: SSH hardening such as environment-variable limits and host-key file permissions, a gliderssh update to remove a data race on timeouts, and, on October 25, “fix serve app caps leaking across mounts”. That last commit describes the same cross-mount capability leak as the report’s finding 11. We did not see a commit by title for the unix-socket forwarding in findings 1 to 3, though we only read commit titles and a few full messages. Neither the commits nor the report refer to each other, and the dates overlap the testing window, so we cannot say which came first.
• A Reddit reply we could not read. A Hacker News commenter says Tailscale’s VP of engineering posted a response on Reddit. Reddit showed us a verification page, so we have not read it.

How far can the report be trusted for now?

It is detailed and self-consistent in the parts we read, but nothing here is independently confirmed. The author says the findings were reported to Tailscale but not coordinated, and commenters on Hacker News faulted that, along with the report’s length and style, some calling it machine-written. Others argued the SSH escalation, if real, matters because one compromised node could reach many. We cannot judge from outside which side is right. Two cautions from the report itself: the SSH findings assume the attacker already holds an approved device, which the author says happens through ordinary footholds such as a vulnerable web app or a malicious dependency, and one Hacker News commenter doubted that the “worm” in the name fits, since an SSH foothold does not by itself replicate.

What can operators do now?

The report offers interim steps, which are the author’s recommendations and not Tailscale’s:

• Tighten SSH rules. Use per-pair grants from one device to one device, drop identity-wide and tag-wide accept rules and avoid target accounts like root or ones with passwordless sudo. On headscale the report says to treat any SSH grant as root-equivalent. On Tailscale’s hosted service, set forwarding to denied per action unless you need it.
• Audit tailscale serve. Look for TCP forwards to unix sockets and remove any that target the agent’s own socket or other privileged paths.
• Constrain app connectors. Remove the capability from clients that do not need it, and enforce allowed destinations at the firewall or, in Kubernetes, with a default-deny egress policy.
• Do not rely on check mode for forwarding. The report says SSH check rules gate session establishment, not forwarding inside an approved session.

The report adds that firewalls cannot see unix-socket operations, so for those it recommends monitoring. Watch Tailscale’s bulletins and release notes for an official response.

What is still unknown?

• Which findings Tailscale confirms, how it rates them and when fixes ship.
• Whether the October 23 to 25 commits answer the report, beyond the one that matches finding 11.
• Reproduction by others. We found no independent confirmation.
• How exposed real deployments are. The findings depend on policy choices such as SSH rules, forwarding settings and app-connector use.
• The disclosure history. The author says it was reported but not coordinated; the dates and content of that report are not public.

What to keep in mind

These are our observations:

• Treat this as an allegation until the vendor responds. A detailed report is not a confirmed vulnerability, and a single long document is hard to check quickly.
• Disclosure timing is part of the story. Publishing before a vendor can respond leaves users with only the author’s mitigations. We saw the same tension in our PHP embargo report.
• The configuration advice holds up either way. Narrow SSH rules, no root targets and tighter app-connector egress are cheap steps whatever Tailscale concludes.
• Tailscale was also in the news for a different reason this week. Its October 21 bulletin on the eMudhra certificate keys says v1.104.2 or later distrusts them.

Editorial review: October 25, 2026 (AI). Prepared from the full text of the Tailworm report at tailworm.com (including its summary, findings, negative results, check-mode section and remediation sections; the exploit-reproduction kits were not examined), the public tailscale/tailscale commit history for October 20 to 25 (GitHub API; four commit messages read in full, the rest by title), Tailscale’s security bulletins page, the headscale v0.29.6 release notes and the Hacker News thread (read through the Algolia API; its first dozen top-level comments). We did not test any finding, run any proof of concept or contact Tailscale or the researcher. The Reddit replies mentioned in the thread could not be opened. The report, the thread and Tailscale’s pages may have changed since our reading.