A security researcher has published a report called Tailworm that describes 11 alleged flaws in Tailscale, the popular WireGuard-based mesh networking tool, and in headscale, the open-source self-hosted control server that many teams use in place of Tailscale’s hosted service. The most serious claims concern Tailscale SSH. According to the report, a user who is already allowed to open a Tailscale SSH session on a server can abuse its forwarding feature to gain root on that server.
The report was written by Erica Windisch of Cyberdione Labs and went public on October 24 and 25, 2026. Tailscale has said it is fixing what it calls “serious security issues” in Tailscale SSH and is targeting a patched client release by the end of Tuesday, October 27. As of the morning of October 27, 2026, no fixed release, security bulletin or CVE had been published. BreachNews will update this article when the patch ships.
What the Tailworm report claims
The researcher says the findings came from 3 days of lab testing, October 22 to 24, against unmodified releases of Tailscale 1.104.2 and headscale 0.29.5. Each finding carries the researcher’s own severity rating. None has a CVE or CVSS score, and Tailscale has not publicly confirmed any individual finding.
The “11 flaws” figure is loose. One finding bundles 3 separate memory issues, and another is described by the researcher as a configuration note rather than a bug. Grouped by area, the report alleges:
- Findings 1 to 3, Tailscale SSH forwarding (rated High): the report claims the built-in SSH server performs Unix socket forwarding as root instead of as the logged-in user, letting an ordinary session reach or replace root-only sockets, and that a race defeats the path checks meant to limit this. These are the headline root escalation flaws.
- Finding 4, app connectors (rated High): in the experimental “conn25” feature, a user allowed to use one app could allegedly reach any destination the connector can, including cloud metadata services.
- Finding 5, SSH session memory exhaustion (rated High): crafted sessions could allegedly exhaust the root service’s memory.
- Finding 6, headscale and relay client denial of service (rated Medium-High): headscale memory exhaustion and approval eviction, plus an unbounded read in Tailscale’s relay client.
- Findings 7 to 11, Tailscale Serve and Funnel (rated High to Low): issues including a Serve setup that could expose a node’s local admin interface to remote peers, weak Funnel permission checks, a race that could leak permissions between mounts, and the configuration note about a non-default setting.
Who is actually exposed
Tailscale SSH is not on by default. An administrator has to opt each server in, and according to Tailscale’s SSH documentation, the server side only runs on Linux and on macOS with the open-source tailscaled daemon.
For the headline flaws, the report says an attacker needs:
- A foothold on a device that is already part of the tailnet, such as one compromised through a vulnerable web app or stolen credentials
- An SSH access rule that admits that device to the target server
- Forwarding allowed under that rule
Tailscale does not create the first foothold. The researcher’s argument is that the mesh can turn one compromised device into root on every server its SSH rules reach. On headscale 0.29.5, the report says every accepted SSH rule grants forwarding and there is no policy setting to turn it off, so the researcher advises treating every headscale SSH grant as root-equivalent. Restricting rules to non-root users or using check mode does not help, according to the report, because the forwarding runs as root no matter which user logs in.
Fleet, a device management vendor, says it reproduced the core forwarding finding in its own lab on Ubuntu 24.04 with Tailscale 1.104.2 and headscale 0.29.5. Fleet says socket forwarding arrived in Tailscale 1.98.0, which would put versions 1.98.0 through 1.104.2 in scope. BreachNews could not confirm that starting version in Tailscale’s own changelog.
Root, rogue nodes and the “wormable” claim
In the lab, the researcher claims the forwarding flaws led to root on target servers, the capture of a device enrollment key and, on tailnets without Tailnet Lock, a rogue machine joining the network.
The report calls the chain “wormable,” saying it measured automated spread to every device the policy allowed in under a second per hop, with no passwords or user action. It says per-pair access rules were the control that stopped the spread.
Not everyone agrees with that framing. Commenters in public discussions questioned whether “wormable” fits. A Tailscale engineer also pushed back on the report’s claim that every node can see the full list of peers, saying Tailscale’s hosted control plane trims each node’s view to peers its access rules allow. That suggests the peer list issue may mainly affect headscale. All impact claims come from lab testing. No exploitation in the wild has been reported.
Tailscale’s response and the fix timeline
The report was published before any fix was available. On disclosure timing, the researcher’s stated view is that infrastructure is vulnerable today. In its investigation and remediation update, dated October 26, Tailscale says most of the SSH issues it identified concern privilege escalation. It says someone already authorized to connect “may be able to perform actions beyond the permissions of their configured local user, including potentially gaining elevated privileges.” The company says it has been investigating with help from outside security specialists, that exploitation depends on permissions and configuration, and that it is “not recommending that everyone disable Tailscale SSH.” Fixes for most issues are implemented and in testing.
Fixes are already visible in Tailscale’s public repository. They include #21941, which runs forwarding with the logged-in user’s credentials, #21944, which enforces SSH policy at the connection level, #21945 for the memory exhaustion issue, #21966 for the Serve admin socket issue, #21931 for the permission leak and #21980 for the relay client. A headscale change, #3586, was still pending.
As of the morning of October 27, 2026, the latest version on Tailscale’s releases page was still 1.104.2. The latest headscale release, 0.29.6 from October 24, carried unrelated security updates. Tailscale had not issued a security bulletin or CVEs at time of publication. It says it will publish an advisory covering confirmed vulnerabilities, affected versions and configurations once fixes are out.
What Tailscale tells admins to do now
Tailscale’s official interim guidance is:
- Disable SSH forwarding if you do not need it: set
TS_SSH_DISABLE_FORWARDING=1in thetailscaledservice environment and restart the service. Tailscale says this keeps Tailscale SSH working while mitigating several of the more serious findings. - Review SSH access policies so only the users and devices that need access have it.
- Tighten access to sensitive systems temporarily while the investigation continues.
- Apply the patched client as soon as it is released.
Hosts that do not need Tailscale SSH at all can turn it off with tailscale set --ssh=false, per Tailscale’s documentation.
The researcher recommends further steps, which are the researcher’s advice rather than Tailscale’s:
- Write SSH rules as single source to single destination pairs instead of group-wide or tag-wide rules
- Enable node key expiry on servers, hardware-bound keys where possible, and Tailnet Lock
- Restrict which destinations app connectors can reach
- After a suspected compromise, delete the device in the control plane, because reimaging alone does not revoke keys an attacker may have copied
Fleet has also published a guide to finding and disabling exposed hosts.
Not the first Tailscale SSH privilege bug this year
Tailworm lands in an area Tailscale has patched before. Its security bulletins for 2026 include:
- TS-2026-004: SSH socket forwarding could reach privileged sockets through symlinks. Fixed in 1.98.9.
- TS-2026-005: a non-root Serve operator could proxy privileged sockets. Fixed in 1.98.9.
- TS-2026-006: a numeric user ID could bypass SSH root restrictions. Fixed in 1.98.9.
- TS-2026-009: a crafted username could open a root session against policy. Fixed in 1.98.9.
- TS-2026-011: 4via6 subnet routers could reach cloud metadata services. Fixed in 1.102.3.
The core forwarding issue also has a close parallel outside Tailscale. Dropbear’s CVE-2025-14282 described an SSH server performing client-requested socket forwarding as root, letting any user who could log in reach Unix sockets with root’s credentials. Dropbear fixed it in version 2025.89.
Linux root escalation bugs keep piling up, as BreachNews reported on a third major privilege escalation flaw in weeks. Remote access tools have also been a favorite target, from the Check Point VPN zero-day added to KEV to Qilin attacks exploiting a PAN-OS VPN bypass. Tailworm’s chain also depends on an initial foothold, the kind web flaws like WP2Shell can provide.
Until the patched release ships, admins running Tailscale SSH should turn off forwarding wherever it is not needed. BreachNews will update this article when the fix and advisory are published.
