Tailscale Merged Fixes for Most of the 11 “Tailworm” Findings Before Shipping a Release, and the Forwarding Switch It Recommends Already Exists in the Shipped Client

Tailscale has merged fixes into its public repository for most of the 11 findings in the “Tailworm” report, but as of 19:31 UTC on October 27 it has not shipped a release that contains them. The newest release is still v1.104.2 from October 21, the version the researchers audited, and GitHub shows the main branch 134 commits ahead of it, 30 of them titled ssh/tailssh: (the Tailscale SSH server), the newest at 03:06 UTC today. Tailscale says it is targeting a patched client by the end of Tuesday, October 27, subject to testing. The researchers at Cyberdione Labs put their report online over the weekend, before any fix existed; they label six of the 11 findings High, and neither they nor Tailscale reports exploitation in the wild.

The record around that is more useful than the headline count. By the researchers’ own labels the “11” includes a configuration note and a threat-model finding. One finding is split between Tailscale’s client and headscale, a separate self-hosted control server whose newest release, v0.29.6 of October 24, lists certificate-distrust and dependency updates as its security changes and does not mention the report. NVD lists no Tailscale CVE published in October. And the switch Tailscale tells operators to use, the TS_SSH_DISABLE_FORWARDING environment variable, is not something to wait for: it is registered in the v1.104.2 source and checked in the code for local and remote TCP forwarding, local and remote Unix-socket forwarding, and agent forwarding.

We read the Tailworm report, Tailscale’s SSH investigation and remediation update and its security bulletins page, BleepingComputer’s and SecurityWeek’s coverage, GitHub’s records for tailscale/tailscale and juanfont/headscale, the v1.104.2 source, and headscale’s changelog.

What the report says

The report is signed by Erica Windisch of Cyberdione Labs Corporation. Its testing window was October 22 to 24, against Tailscale v1.104.2, headscale v0.29.5, the gliderssh library both build on, and the experimental conn25 app-connector feature. Its introduction states: “All findings were verified by reproduction in a lab environment on unmodified, released software.” A researchers’ note says that “infrastructure is vulnerable today,” that rapid awareness will speed remediation, and that the authors are not employed or paid by Tailscale. SecurityWeek writes that the researchers “showed that these SSH flaws are wormable”; the report’s lab measurement is that spread stopped only where access grants were set per pair, in its words “per-pair access grants bound the spread.”

The labels below are the researchers’ own, not CVSS scores. The status column is what the report’s October 27 update says, checked against GitHub’s merge records at 19:31 UTC.

Counted from those labels, six findings are High (1, 2, 3, 4, 5 and 7), one is Medium-High, two are Medium, one is Medium or Low-Medium depending on deployment, and one is a configuration note. SecurityWeek’s top line agrees: “Six of the findings are rated high severity, and four of them concern Tailscale SSH.” By our reading of the table those four are findings 1, 2, 3 and 5.

What Tailscale has said

Tailscale’s update, published October 26, says: “Most of the Tailscale SSH issues we’ve identified concern privilege escalation.” It adds that “These are serious security issues, and we’re treating them accordingly,” and that “Exploitation depends on the permissions granted to the connecting user or device, the system’s configuration, and other conditions.” Its engineers “have implemented fixes for most of the issues identified,” and the company is targeting “a release by the end of Tuesday 27 October.” It also says “we’re not recommending that everyone disable Tailscale SSH.” Once fixes ship, Tailscale says it will publish “a security advisory detailing the confirmed vulnerabilities, affected versions and configurations, their impact, and how to address them,” followed by a technical blog post.

Mike Shaver, Tailscale’s VP of Engineering, answered on Reddit, whose page returns no readable text to a scripted fetch, so we rely on SecurityWeek’s quotation of him: “While it’s a serious concern, it isn’t the same as an unauthenticated attacker being able to connect to arbitrary machines,” and “the potential impact depends on how SSH access is configured.” SecurityWeek adds that Tailscale was already running its own investigation, with input from outside security specialists, when the report arrived.

What the public record shows

Releases and commits

At 19:31 UTC, GitHub’s latest-release endpoint for tailscale/tailscale still returned v1.104.2, published October 21 at 02:55 UTC. The newest tag, v1.105.0-pre, points at a commit GitHub dates September 30, so it predates every fix discussed here. A compare of v1.104.2 with main shows main 134 commits ahead, and the count was still rising during our checks. Thirty commits have titles beginning ssh/tailssh:, running from 18:32 UTC on October 24 to 03:06 UTC on October 27.

Some of the commit titles revisit ground that earlier 2026 bulletins covered. Tailscale’s bulletins page lists four bulletins between June 3 and July 24 (TS-2026-005, TS-2026-006, TS-2026-009 and TS-2026-010) about Serve’s Unix-socket proxy targets and Tailscale SSH’s handling of numeric user IDs, command-line arguments and environment variables, and this week’s titles include numerically zero user IDs treated as root and an environment-variable denylist. We read only the titles, and the report does not list those commits, so we do not tie them to the findings.

Tailscale’s own commit messages

Tailscale’s commit messages describe the mechanics for several findings in the company’s words. For Serve (pull request 21966), the message says tailscale serve --tcp to a Unix path “dialed the target socket with no check,” and explains: “The HTTP proxy path already refused this via isTailscaledSocket; the TCP-forward path, added later, did not.” In the v1.104.2 source, isTailscaledSocket has one caller, in the function that builds the HTTP reverse proxy for a backend (serve.go, line 892), and it compares the two paths with os.SameFile. That function runs when the handler for a backend is first created after a configuration reload, and the handler is then cached, so the check is not repeated for each request. That matches the message and the report’s description of finding 8.

For the relay finding (pull request 21980) the message says “connect read a non-101 response body with an unbounded io.ReadAll and inlined it into the returned error.” For the cross-mount finding (pull request 21931) it says the shared context could let a request carry another mount’s capabilities header, “letting backends that trust the header authorize the wrong mount.” For SSH forwarding, the monitor commit of October 26 says forwarded Unix sockets “are dialed and bound by children with the authenticated local user’s credentials, never by root tailscaled,” and that “The EvalSymlinks re-validation is dropped, and the kernel’s DAC is the boundary.”

Pull request 21931 merged at 00:39 UTC on October 25, about 20 minutes before the report’s first Hacker News submission at 00:59 UTC. That is consistent with Tailscale’s statement that its own work was already under way. It does not show when Tailscale received the report, and neither the report nor Tailscale’s update gives that date.

No CVE, no advisory yet

NVD’s keyword search for “tailscale” returns no CVE published in October. GitHub lists three published security advisories for tailscale/tailscale, the newest from March 2023, and none for juanfont/headscale. The newest entry on Tailscale’s bulletins page is TS-2026-013 of October 21, about the eMudhra certificates we covered in our earlier post. That bulletin says “Tailscale v1.104.2 or later includes Go 1.27.3, which explicitly distrusts the compromised certificates, even if they are still included in your system certificate store.” So v1.104.2 is both the release the researchers audited and the one that carries the eMudhra distrust.

headscale

headscale is a separate open-source project, not Tailscale’s code. Its newest release is v0.29.6, published October 24 at 10:29 UTC. The Security section of its changelog lists a build with Go 1.27.3 “to reject certificate chains containing the compromised eMudhra intermediate keys (CVE-2026-111943),” container base images whose CA bundles no longer include emSign ECC Root CA - G3, and dependency updates for HTTP/2 and text-processing vulnerabilities. The changelog does not mention the report. The researchers’ October 27 update treats headscale up to v0.29.6 as unpatched, and says a rework of its registration cache, the open pull request linked in the table, “cites this report.”

Where the coverage and the sources differ

The count. BleepingComputer writes that Tailscale is working to patch “almost a dozen security vulnerabilities,” and the report’s count is 11. Neither is a count of CVEs. The report’s own labels include a configuration note (finding 10, which it describes as a “non-default knob (upstream-acknowledged)”) and a threat-model finding (finding 9). Its introduction says “All findings were verified by reproduction in a lab environment,” while its text for finding 10 says “Source-verified (no lab LAN path in the test environment).”

“Still lack patches.” BleepingComputer says the flaws “still lack patches.” That is accurate for shipped software and for headscale. It understates the state of Tailscale’s repository on October 27, which already held merged fixes for findings 1 to 3, 5, 7 and 11 and for the client half of 6. Findings 4, 8, 9 and 10 have no merged fix that the report credits.

Who can trigger what. Headlines about root access and stolen credentials compress different attacker requirements. By the report’s summary table, the SSH findings need “One approved device + one SSH policy rule,” the app-connector finding needs a device granted the connector capability, the headscale exhaustion needs only “Internet reachability; no account,” the relay finding needs the ability to point a client at a hostile relay, and the Serve findings need an operator-configured forward or a peer racing a mount check. Tailscale and the report agree that the SSH root path starts from someone already authorized to connect; the finding the report describes as unauthenticated is the headscale one.

The mitigations. Tailscale’s mitigation is node-side: set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled environment, which its update says “disables SSH forwarding without disabling Tailscale SSH entirely, and mitigates several of the more serious findings.” The researchers’ summary is policy-side: write per-pair SSH grants, set the per-rule forwarding fields to false on the hosted service, and, for headscale, they say forwarding “cannot be disabled” and is “granted unconditionally on every accepted session.” The two do not conflict. The variable is read inside tailscaled whichever control server a node uses, by the code path we read, although we did not test it against headscale.

What operators can do now

Turn off SSH forwarding on nodes that do not need it. In the v1.104.2 source the variable is registered in ssh/tailssh/tailssh.go at line 54 and checked at lines 528, 542, 557 and 573 (reverse TCP, local TCP, local Unix and reverse Unix forwarding) and in process_unix.go at line 107 (agent forwarding). On a Linux host that uses the unit file from that source (cmd/tailscaled/tailscaled.service, line 8, which reads /etc/default/tailscaled), add this line to that file and restart the service:

# add this line to /etc/default/tailscaled
TS_SSH_DISABLE_FORWARDING=1

sudo systemctl restart tailscaled

Tailscale’s tailscaled documentation says that on Linux you can modify the flags in /etc/default/tailscaled, “which the systemd unit definition will include,” and systemd’s documentation says EnvironmentFile= “reads the environment variables from a text file” of newline-separated assignments and ignores lines that start with a number sign, so the comment line in the first block is harmless. Distribution packages can differ, so run systemctl cat tailscaled first to see which file your unit reads. The switch turns off all SSH forwarding on that node, including ordinary ssh -L port forwards and ssh -A agent forwarding that some tools rely on. We did not run these commands on a Linux host.

Tighten who may connect. Tailscale’s own advice is to review SSH access policies, limit access to the users and devices that need it, and consider tightening it temporarily. The researchers’ first recommendation is per-pair grants, meaning a specific source to a specific destination, rather than identity-wide or tag-wide accept rules, and no privileged target accounts. They add that limiting SSH to non-privileged accounts is defense in depth only and does not stop these findings.

Check the unusual features. The report advises removing any serve --tcp forward to a Unix socket that targets the agent’s own socket or another privileged path (finding 7), removing the conn25 connector capability from clients that do not need it, and, for self-hosted headscale, memory limits, restart supervision, a rate-limiting reverse proxy in front of registration, and keeping the control server off the open internet. These are the researchers’ recommendations, not Tailscale’s, and we did not test them.

Watch for the release. Tailscale says it will update its page and publish an advisory with affected versions. You can also ask GitHub for the latest release tag:

curl -s https://api.github.com/repos/tailscale/tailscale/releases/latest | grep -E '"(tag_name|published_at)"'

At 19:31 UTC on October 27 it printed "tag_name": "v1.104.2", and "published_at": "2026-10-21T02:55:49Z",. Any tag newer than v1.104.2 means a release has shipped; read Tailscale’s advisory before assuming it covers every finding.

Timeline (UTC)

What is still open

• Tailscale’s advisory, with affected versions and configurations, and its technical write-up. Both are promised for after the patched release.
• CVE identifiers and Tailscale’s own severity ratings. The labels above are the researchers’.
• Whether findings 4, 9 and 10 will be changed, and which pull request settles finding 8. The report’s update does not credit a fix for 4, 9 or 10, and Tailscale’s update does not list findings individually.
• The version number that will carry the fixes, and whether the October 27 target holds.
• When Tailscale received the report. Tailscale says its investigation was already running; the public commits are consistent with that but do not date it.
• Whether anyone has exploited any of this. SecurityWeek writes that “Neither Tailscale nor the Tailworm report mentions in-the-wild exploitation.”

For a worm that did reach a developer tool’s npm package, see our report on the Shai-Hulud worm in Tensorlake’s npm SDK; here the spread was measured in a lab, and neither side reports it happening outside one.

We fetched the report, Tailscale’s pages, the coverage, GitHub’s records, the NVD results and the v1.104.2 source between about 19:08 and 19:31 UTC on October 27. We did not run any of the report’s reproduction kits, tested nothing against Tailscale or headscale, and contacted none of the organizations. We link the report but not its proof-of-concept material. Numbers described as ours are counts and dates read from GitHub’s records; everything else is attributed to the source named.