Key facts
- The lab tests used unmodified Tailscale 1.104.2 and headscale 0.29.5 from October 22 to October 24, 2026.
- Tailscale had published no security bulletin, CVE, or fixed version for the Tailworm findings as of publication.
- The attack requires Tailscale SSH permitting port forwarding, plus access rules that let the compromised device connect to the target.
- The findings come from lab tests only; no exploitation in real networks has been reported, and Tailscale has not confirmed the technical claims.
On Oct. 25, 2026, Erica Windisch of Cyberdione Labs published a report called Tailworm describing 11 findings in Tailscale and headscale, including SSH flaws that allow a compromised device to gain root access on reachable servers. The lab tests used unmodified Tailscale 1.104.2 and headscale 0.29.5 from Oct. 22 to Oct. 24, 2026. As of publication, Tailscale had published no security bulletin, CVE, or fixed version for the findings. The findings come from lab tests only; no exploitation in real networks has been reported, and Tailscale has not confirmed the technical claims.
Tailscale SSH replaces traditional key management with identity-based access control; administrators define access rules in tailnet policy and Tailscale handles authentication for sessions between devices. Headscale is a self-hosted server that some networks use in place of Tailscale’s hosted service. The attack needs no stolen passwords or keys; an initial foothold on one device can come from a vulnerable web application, a poisoned software package, phishing, or stolen login details.
The attack requires Tailscale SSH to permit port forwarding and access rules that let the compromised device connect to the target. In lab tests, researchers demonstrated three methods to gain root: a port-forwarding session that made the root-level Tailscale process connect to a root-only socket, a socket swap that allowed direct root command execution, and a file-path race that captured a device-enrollment key to enroll an attacker machine. The enrollment step completed only on networks without Tailnet Lock; with Tailnet Lock enabled, secrets were captured but the final step was not completed.
A single compromised device on a Tailscale network can be used to gain root access to other servers it can reach, with no passwords, no stolen keys, and no user action. In the lab, one device could spread to every device that the access rules allow in under a second per step. Tailscale SSH identifies the connecting device rather than checking passwords or keys, and a single access rule decides whether that device may open an SSH session to a target.
One finding concerns conn25, letting a permitted user reach unapproved destinations including a cloud metadata service that can issue server credentials. Windisch told The Hacker News she finds the SSH privilege escalation worrying and considers the app-connector finding potentially more impactful for some organizations. Windisch describes the result as wormable, though some researchers questioned that description while others called the root-access finding serious.
Administrators should write Tailscale SSH access rules as single source-to-destination pairs naming one device and one target, and drop broad rules granting access based on identity or tag; single source-to-destination rules and hardware-bound device keys, such as keys tied to a TPM or Secure Enclave, held the lab spread back. They should turn off SSH port forwarding where possible; on Tailscale’s hosted service this can be disabled for each rule, but headscale version 0.29.5 offers no way to turn off forwarding, so every SSH grant there equals root access on the target. Other steps include revoking app connector permissions on devices that do not require them, deleting any tailscale serve forward targeting a Unix socket, enabling node-key expiry, and if a device is compromised, deleting it at the control plane since reimaging does not remove keys the attacker may have copied. Tailscale recommends enabling SSH check mode, which inserts a login step before a session begins, and turning on automatic updates.
Check mode does not resolve the privilege escalation, though it adds another barrier in front of it. Tailnet Lock does not fix the SSH forwarding flaws since it governs node admission and key substitution rather than privileged socket access from an established session. Administrators can disable Tailscale SSH by running tailscale set –ssh=false. They should ensure they have another way in before disabling it.
Windisch described the disclosure as reported but not coordinated, posting a file hash publicly and advising users to turn off Tailscale SSH. She said she sent the report and proof-of-concept code to Tailscale’s security contact on the Saturday before the public post, and the code remains private. She also said she earlier raised concerns with Tailscale’s chief executive about the company’s architecture, and at least one commenter on Ycombinator HN called the publication irresponsible. The report states its researchers have no ties to Tailscale and received no payment for the work.
Commenters on X dispute the severity, saying the SSH bug affects only those who enabled Tailscale’s own SSH server and that admin-set SSH rules limit spread. A commenter named banteg said on X that “this concerns tailscale’s opt-in ssh server, not ordinary openssh.” The report’s most serious findings do not appear to apply to networks that do not use Tailscale SSH, app connectors, or headscale. Windisch describes the result as wormable, though some researchers questioned that description while others called the root-access finding serious; she rates most of the 11 findings High or Medium-High, and she told The Hacker News she finds the SSH privilege escalation worrying and considers the app-connector finding potentially more impactful for some organizations.
Tailscale said publicly it received the report and was working with outside security specialists on the same areas, and had found issues it is fixing. Mike Shaver, Tailscale’s vice president of engineering, said on Reddit that the company is “not recommending that everyone disable Tailscale SSH.” A Tailscale engineer commented on Hacker News that more details would follow.
Earlier in 2026, Tailscale fixed several SSH and server socket-handling flaws in version 1.98.9, including SSH Unix socket forwarding that could reach a privileged socket. The company published security bulletins TS-2026-004 and TS-2026-005 on June 3, 2026, both fixed in 1.98.9; TS-2026-004 concerns SSH Unix socket forwarding ignoring symlink permissions, while TS-2026-005 concerns Serve Unix socket proxy targets that are not restricted to root. On Jan. 14, 2026, Tailscale published advisory TS-2026-009 covering an argument injection flaw in its integrated SSH server that let authenticated users escalate to root, with patches for Linux, macOS, and Windows through standard update channels.
As of Oct. 25, 2026, Tailscale’s newest security bulletin is TS-2026-013 from Oct. 21, which does not mention the Tailworm report, and headscale version 0.29.6 released on Oct. 24 also does not mention the findings. Tailscale’s issue #4129 asking for per-rule control to block forwarding while permitting SSH remains open.

Join the discussion