Tailscale SSH 'Tailworm' flaws: 11 unpatched findings, root via forwarding, workaround
Cyberdione Labs published 11 findings against Tailscale 1.104.2 and headscale 0.29.5; Tailscale calls them serious, has no fixed version yet, and offers a forwarding workaround.
· 6 min read
Written by AI from the sources linked below. How we use AI
On this page
Tailscale has not yet shipped a fix for "Tailworm", a set of 11 findings published on 25 October 2026 by Erica Windisch of Cyberdione Labs against Tailscale 1.104.2 and headscale 0.29.5. The most serious let a user who is already allowed to connect through Tailscale SSH reach root on the target machine. Tailscale calls them "serious security issues" and targeted a patched client by the end of Tuesday 27 October, but at the time of writing there is no CVE, no advisory and no fixed version number.
Key points
- Cyberdione Labs published 11 findings on 25 October 2026, tested on Tailscale v1.104.2 and headscale v0.29.5 between 22 and 24 October.
- The worst chain abuses Unix-socket forwarding (
ssh -L/ssh -R) in Tailscale SSH, which runs as root; the attacker needs an approved device and an SSH rule that permits forwarding. - No CVE, advisory or fixed version had been published when we checked; Tailscale targeted a patched client by the end of 27 October, subject to testing.
- Tailscale's interim advice is to set
TS_SSH_DISABLE_FORWARDING=1in thetailscaledenvironment and restart it, without switching Tailscale SSH off. - On headscale 0.29.5, the researcher says SSH forwarding cannot be disabled at all.
What to do
Who is affected. Anyone running Tailscale SSH (tested on 1.104.2; the researcher's page says its mitigations apply to Tailscale up to v1.104.2 and headscale up to v0.29.6) where an SSH rule permits port forwarding for a user or device you do not fully trust. Self-hosted headscale servers are affected by separate denial-of-service findings.
Fixed version. None yet. Tailscale says it will publish a security advisory with affected versions after the patch ships, then a technical write-up. Watch the Tailscale investigation update and its security bulletins.
Workarounds today (from Tailscale's update and the researcher's page):
- Set
TS_SSH_DISABLE_FORWARDING=1in the environment of thetailscaledservice and restart it. Tailscale says this keeps Tailscale SSH running and mitigates several of the more serious findings. - Review SSH access policies and limit access to the users and devices that need it. The researcher recommends one-source-to-one-destination rules rather than broad identity or tag grants.
- On the hosted service, switch forwarding off per rule. On headscale 0.29.5, the researcher says to treat every SSH grant as root-equivalent.
- Remove the app-connector capability from devices that do not need it, and remove any
tailscale serveforward that points at a Unix socket. - Enable node-key expiry. If a device may have been compromised, delete it at the control plane: reimaging does not revoke keys an attacker may have copied.
How to check. Run tailscale version on each node, list your SSH rules in the admin console and look for any that allow forwarding, and check whether any node serves a TCP forward to a Unix socket (tailscale serve status). Tailscale has not published indicators of compromise; the researcher suggests monitoring Unix-socket operations in forwarding-allowed directories and watching enrollment and key use.
What happened
Windisch's report, titled Tailworm, went public on 25 October 2026. According to The Hacker News, it describes lab tests on unmodified released software, not attacks on real networks. The researcher says she sent the report and a proof of concept to Tailscale's security contact before publishing and posted a file hash publicly; she described the disclosure as "reported but not coordinated" on Hacker News. BleepingComputer says Tailscale received the report on the Monday before its 27 October article, while The Hacker News relays the researcher's account of the Saturday before publication. The sources disagree on that detail, and we have not resolved it. The proof of concept is not public, and The Hacker News says no other researcher had publicly reproduced the findings.
Tailscale published an update on 26 October. It says most identified issues involve privilege escalation: a user who is already authorised to connect may be able to go beyond the permissions of the local user they were configured for. It says fixes for most issues are implemented and in testing, the rest are under review, and the full scope of affected configurations is still being checked. It does not confirm every technical claim in the report, and it names no affected or fixed versions.
Background
Tailscale SSH lets the Tailscale daemon, tailscaled, accept SSH connections itself and authorise them by device identity and policy instead of keys or passwords. That daemon runs as root, so a mistake in how it handles a forwarded connection becomes a root-level mistake. It is not the first such issue this year: The Hacker News notes an earlier, separate flaw where SSH Unix-socket forwarding could reach a privileged socket, tracked by Tailscale as ts-2026-004 and fixed in version 1.98.9.
How it works
The researcher's page lists the findings in a table. The SSH group (findings 1 to 3 and 5) is the core:
- Finding 1,
ssh -L: forwarding to a Unix socket makestailscaleddial that socket as root, so a user without admin rights can reach root-only sockets. No sudo or docker-group membership is needed. - Finding 2,
ssh -R: remote forwarding can replace root-owned sockets. - Finding 3, a time-of-check/time-of-use race: the path allowlist can be defeated by swapping the path between the check and the use. Per The Hacker News, the lab chain captured an enrollment key and, on tailnets without Tailnet Lock, joined an attacker's machine as a trusted server. On networks with Tailnet Lock the secrets were captured but the final step did not complete.
- Finding 5: a session-handling bug inherited from the gliderlabs/ssh library can push root
tailscaledinto an out-of-memory loop for an authenticated session.
The rest: the experimental conn25 app connector (finding 4) lets a user with an ordinary entitlement choose where traffic exits, including a cloud metadata service that can issue server credentials; tailscale serve has a TCP-forward-to-Unix-socket gap (finding 7), a symlink recheck gap (8) and a cross-mount capability race (11); Funnel entitlement enforcement (9) and TS_SERVE_ALLOW_ALL_INTERFACES (10, a non-default knob) are rated lower; and headscale and the DERP client have memory-exhaustion issues (6), one of which needs no account on headscale.
The researcher rates six findings High, the others Medium-High or lower, and the severity ratings are hers, not Tailscale's. Her page names limits: one-to-one access rules stop the spread on their own, as do device keys bound to a TPM or Secure Enclave.
What it means
For most teams the practical risk is lateral movement after a foothold, not an attack from the open internet. Tailscale SSH identifies devices rather than checking passwords, so an attacker who controls one approved device does not need stolen credentials. If your policies allow forwarding broadly, that device may become a path to root on servers. The "wormable" label in the report is disputed by some researchers, according to The Hacker News, and Tailscale's own wording is narrower: privilege escalation by an already-authorised user.
The disclosure itself is contested. Publishing unpatched details without a coordinated deadline drew criticism in the Hacker News discussion, and the researcher's counter is that she reported first and warned users to disable Tailscale SSH. Tailscale's VP of Engineering Mike Shaver said, per BleepingComputer, that the company is not recommending everyone disable Tailscale SSH.
Headscale operators have the least room to manoeuvre: the researcher's page says forwarding cannot be turned off on 0.29.5 and a registration-cache rework (PR #3586) is still pending.
What we don't know yet
- The affected and fixed version numbers, and whether any CVEs will be assigned.
- Which of the 11 findings Tailscale confirms exactly as described.
- Whether the Tailnet Lock result generalises beyond the researcher's lab.
- Whether anyone has exploited any of this outside a lab. The researcher's page and the sources we read report none.
- Headscale's timeline for a fix.
What to watch next
A Tailscale client release and the promised security advisory, followed by the technical write-up. Several fixes have been merged to the public code repository, according to the researcher's page, but a merged change is not a shipped release. When the advisory appears, compare its affected configurations with your SSH rules.
Sources
Written by
The official account of the people who run audiotale.net: announcements, conversation starters and the newsroom's drafts. Posts written with AI say so. Every other account here is a real person.
Read next
333 Tor exit relays hijacked in Ebury campaign to intercept SSH passwords and plaintext mail
A volunteer found that about 10% of Tor's exit relays redirected SSH logins to attacker servers from 2 October; here is what happened and how to check you are safe.
audiotale.net team6 min read
KB5134133: Windows 11 update removes 7 eMudhra certificates, manual download only
Microsoft's 26 October out-of-band update strips six eMudhra roots and one cross-sign from Windows' trust list; it is for PCs that can't get certificate updates automatically.
audiotale.net team7 min read
LiteLLM 1.107.0 poisoned: PyPI and Docker images stole credentials, how to check and fix
Release 1.107.0 of the AI gateway LiteLLM carried a credential stealer for about 1 hour 44 minutes on 21 October; LiteLLM's analysis traces it to a master key leaked in May.
audiotale.net team7 min read