DevonDevon MeadowsDevon
Created October 25, 2026
← Back to Summary

Tailworm and Tailscale: What a Homelab Owner Should Do

I asked for a public-sources brief on the Tailworm report against Tailscale, to decide what to change on my own hardware and what to tell owners who run their businesses the same way. Six questions: (1) what Erica Windisch published, and is she worth taking seriously; (2) what Tailscale has said and fixed as of 25 Oct 2026; (3) how people on X reacted; (4) when a Tailscale user is actually affected; (5) whether Headscale, WireGuard, or another mesh is the better move; (6) what to do next on a small homelab, for a non-developer cofounder, and for a community of owners. Sources at the end.

1. What did Windisch publish, and is she worth taking seriously?

Finding. On 24 Oct 2026 Erica Windisch of Cyberdione Labs published Tailworm, a security assessment of Tailscale client v1.104.2 and headscale v0.29.5, tested 22 to 24 Oct 2026. The report lists 11 findings. The ones that matter most to a homelab are in Tailscale’s built-in SSH server: Unix-socket forwarding runs as root, a path-check race can defeat the allowlist, and in her lab that chain reached root on another machine and captured an auth key used to join a rogue node when Tailnet Lock was off. Other findings cover experimental app connectors (conn25), a memory pin in the SSH session path, headscale and DERP client resource exhaustion, and several tailscale serve / Funnel issues, including an HTTP/2 race that leaks Tailscale-App-Capabilities across mounts.

She says every finding was reproduced in her lab. Finding 1’s two demonstration commands are printed in the report, and she published the SHA-256 of poc-docker/tailscale-privesc.sh on X on 23 Oct (c84d4616…51a2d), matching the hash in the report. The PoC directories named in the report (poc-docker/, poc-t2race/, and others) return 404 on tailworm.com; she wrote on X that “the vendor received PoCs that were not released publicly.” Independent public reproduction of findings 2 to 10 was not found for this write-up. One named practitioner, Anzal Abidi, wrote that he checked the same versions and that several findings are real, including the Unix-socket forwarding race and the serve capability leak, but that “the report overstates the reach.” Senior red-team engineer Graham Helton wrote that the report was “totally unreadable” to him as someone who reports vulns, and that he would not have filed them in that state. Neither published a reproduction.

About the researcher (sourced). Windisch’s LinkedIn and contemporaneous coverage describe her as Docker’s Security Lead (2014 to 2015), founder of Docker’s coordinated vendor disclosure program, a Docker Engine maintainer, co-founder of OpenStack Magnum, and founder/CTO of IOpipe (acquired by New Relic). She is credited as reporter of CVE-2026-79619 (OpenZFS, Aug 2026, CVSS 4.0 score 7.3 High). On 16 Aug 2026 she mailed Full Disclosure that she had notified CERT on 12 Aug and was “opting for full-disclosure.” On 22 Oct she posted “Responsible disclosure is fake” on X (@birdhax). For Tailworm she told Gregory Kurtzer and NetworkChuck that Tailscale got “a short period of notification and private disclosure, not coordination,” with PoCs and a notice of intent, and that “Disclosure happened according to the indicated timeframe.” On Hacker News she wrote: “It was reported but not coordinated,” and “I believe we live in an age of continuous disclosure.”

Researcher’s judgment. She is worth reading. The Docker CVD background and the credited OpenZFS CVE are public facts. Tailscale’s own code later moved toward the privilege-drop fix she asked for (see question 2), which is independent confirmation that the SSH forwarding class is real. Many practitioners disagree with her short private window before publication. That is a dispute about process, and it does not change the technical findings. The 11 findings are not equally proven: finding 1 is effectively reproducible from the public text; finding 11 is confirmed by Tailscale’s own commit; findings 2 to 10 remain CLAIMED without an independent public reproduction as of this writing.

2. What has Tailscale said and fixed as of 25 Oct 2026?

Finding. Mike Shaver, Tailscale VP of Engineering, posted on r/Tailscale on 24 Oct 2026 at 5:41 PM PDT (thread). Exact wording of the headline line:

based on our current assessment, we’re not recommending that everyone disable Tailscale SSH.

He wrote that Tailscale had received the researcher’s report, had already been investigating with external help, and that “Most of the issues we’ve identified so far concern what happens after someone has been authorized to connect, particularly how Unix privileges and SSH forwarding are handled.” He said a session “may be able to do more than the configured local user should be allowed to do,” called that “a serious concern,” and rejected the frame of an unauthenticated attacker reaching arbitrary machines. Precautions he listed: review SSH access policies, review forwarding permissions, consider SSH check mode (which “won’t fix privilege escalation issues”), enable automatic updates, and temporarily tighten SSH policy on sensitive systems. He promised a security advisory and a technical write-up. Asked later whether this is Tailscale’s own SSH feature rather than regular sshd over the tunnel, he replied “that’s correct.”

As of about 4:00 PM PDT on 25 Oct 2026:

Researcher’s judgment. Shaver’s post matches the technical record: this is post-authorization privilege handling inside Tailscale SSH, not internet RCE. His “don’t disable Tailscale SSH for everyone” line is a fleet-wide recommendation; a single-owner lab that can switch to OpenSSH over the same tunnel lowers its risk by turning Tailscale SSH off until the monitor fix ships. Check mode is not a fix for findings 1 to 3; Windisch measured the same, and Shaver agrees it does not fix privilege escalation. Until a release notes corp#50380 / ssh-monitor / Tailworm, treat the SSH forwarding class as unpatched in shipping builds.

3. How did people on X react?

Finding. Metrics below are a snapshot from X’s public API between about 10:15 and 10:35 AM PDT on 25 Oct 2026; they will have moved since.

Five camps showed up clearly:

  1. Process anger. @NetworkChuck (about 73.5K views, 1,763 likes): “Dude, can we please stop publishing vulns before they are disclosed to the vendor!?!?!?!??!” Gregory Kurtzer (@gmkurtzer) argued that circumventing embargos harms users.
  2. Defense of short or full disclosure. Windisch (@birdhax): “I believe in continuous disclosure… I do not want users in the dark about risks via obscurity practices.” @ThePrimeagen (about 26.9K views): “Thanks Erica.”
  3. Calm / not-hacked framing. @cocktailpeanut: “This is not about unauthenticated attackers breaking into random Tailscale nodes. It’s what attackers can do after gaining authorized SSH access or compromising an already trusted device.” Anzal Abidi’s post (quoted in question 1) sits here too.
  4. Leave Tailscale / minimize surface. @TheAhmadOsman (about 6.7K views, 164 likes): “There’s a reason I tell everyone to skip Tailscale and setup WireGaurd directly.” A reply from @lostonwww noted that Tailscale already uses WireGuard under the hood, and that leaving Tailscale SSH and serve off removes the worst of these findings.
  5. “Nothing touches a default install.” Jamieson O’Reilly (@theonejvo) called Tailworm “a misconfiguration checklist wearing a worm costume” and published tailslop, a short read-only script that checks which of the report’s preconditions a machine has switched on. @levelsio pointed his followers to it. The core point holds: every finding needs a feature that is off by default. Two of the README’s claims do not hold. It says there was “no vendor acknowledgement,” but Tailscale said it is “working to fix” issues and has merged fixes for findings 5 and 11. It also says a current client “already has the fix,” but Windisch tested the current client, and Tailscale’s open fix for findings 1 to 3 replaces the earlier path check. Read the script before running it, as its author advises.

Amplifiers such as @IntCyberDigest (about 613K views) set the “skipped coordinated disclosure” framing that most quote-tweets repeated. @alexhillman (about 69.9K views) posted a practical ACL lockdown prompt that Windisch quote-tweeted positively.

Researcher’s judgment. The loudest posts are panic or anger about the process. Camp 3 matches Shaver and the code: the problems come after authorization, depend on configuration, and mostly go away with Tailscale SSH off. Camp 4’s “just use WireGuard” works for people who will manage keys and NAT themselves, and that is real work (see question 5).

The most useful line on disclosure came from James Tucker, the Tailscale engineer writing the SSH fix, in a personal reply. He wrote that “publishing focused results almost always produces rapid PoCs” and that “there is far less process and work involved in poc / attack production than resolution production.” Windisch’s answer to critics is that the issues were “disclosed when it was discovered” and that Tailscale “were notified.” Both are accurate: Tailscale was notified before publication, but had no time to ship a fix.

4. When is a Tailscale user actually affected?

Finding. Windisch’s own prerequisite tables and Shaver’s post agree on the shape. Mapping feature to findings:

You use…Findings in scope
Tailscale SSH on any node1, 2, 3, 5
tailscale serve or Funnel7, 8, 9, 10, 11
App connectors / conn254
Headscale reachable from the internet6 (server half); DERP-client half is client-side
None of the above (mesh only)Residual: keep clients updated; watch for an advisory

Decision path in plain words:

  1. No Tailscale or Headscale at all → Tailworm does not apply.
  2. Tailscale SSH on anywhere → treat findings 1, 2, 3, 5 as in scope. Disable Tailscale SSH (tailscale set --ssh=false) or at least set TS_SSH_DISABLE_FORWARDING=true for tailscaled, and prefer OpenSSH over the tailnet. Confirm console or another SSH path first.
  3. serve or Funnel in use → findings 7 to 11 in scope. Audit configs; stop trusting App-Capabilities headers until a release contains 566f89e.
  4. App connectors / conn25 in use → finding 4 in scope.
  5. Headscale on the public internet → finding 6 (server) in scope.
  6. Otherwise → low urgency for the headline chain; still update when a fixed release ships.

Tailscale SSH is opt-in: a machine only runs it after someone passes --ssh or runs tailscale set --ssh (Tailscale SSH docs). Whether any given lab has it on is a local fact, not something this page can see.

Researcher’s judgment. If you never turned on Tailscale SSH, the headline “root on other servers” chain does not apply to you. Most coverage skipped that. Whether you are affected depends on which features you turned on, not on whether you use Tailscale.

5. Should you switch to Headscale, WireGuard, or something else?

Finding. Trust and Tailworm impact by option (licenses and docs linked in Sources):

Researcher’s judgment. Switching to Headscale to “escape Tailworm” is a mistake: you keep the vulnerable client and lose Tailnet Lock. Plain WireGuard or Nebula are the right move only when the reason is smallest attack surface or no third-party control plane, and someone on the team will own keys and NAT. For a non-developer owner, staying on Tailscale, on whichever plan fits the use, with Tailscale SSH / serve / Funnel left off is still the right default. Revisit if plan limits stop fitting, if ToS or pricing for the use case changes, or if a one-command self-hosted product reaches non-developer quality.

6. What should a small lab, a non-developer cofounder, and a community of owners do?

Finding. From Windisch’s own mitigations, Shaver’s precautions, Tailscale’s open fix work, and the plan limits above.

Small technical lab (agents on owned hardware). Default: stay on Tailscale, turn off the risky features, and gate new devices.

Non-developer cofounder on owned hardware. Tailscale on whichever plan fits the business: Personal is free but only for non-commercial use. Leave Tailscale SSH, serve, and Funnel off. Turn on device approval and approve every new device yourself; on Standard or Premium, that is the main guard against a rogue device, since Tailnet Lock is not offered on those plans. One sentence of advice: “Don’t turn on Tailscale SSH; if you need a shell, a technical partner sets up ordinary SSH.”

Community of mostly non-developer owners. Same default lesson. Do not lead with Headscale, WireGuard, or Nebula. Offer those as an advanced track only when someone already knows why they need them, with the Headscale client caveat in bold. Choose one gate for new devices: device approval (every plan) or Tailnet Lock (Personal and Enterprise only). Tailscale does not allow both.

Researcher’s judgment. The sources support neither “rip it out” nor “ignore it.” Turn off the opt-in features you don’t use, gate new devices, and update when a fixed release ships.

Status line (refresh before publishing)

As of Sunday, 25 Oct 2026, about 4:00 PM PDT: Tailscale v1.104.2 is still the newest release. There is no Tailworm security bulletin, GitHub advisory, or CVE. Two findings now have fixes on Tailscale’s main branch but not in a release: finding 11 (commit 566f89e) and finding 5, the SSH memory exhaustion (gliderssh commit 6662764, pulled into Tailscale as 5f40a06). The fix for findings 1 to 3 has started landing: the first of five pull requests (#21937) merged to main at 3:23 PM, and four are still open. Shaver’s public line remains “we’re not recommending that everyone disable Tailscale SSH.” Recheck before posting: bulletins, releases, Reddit thread, tailworm.com, headscale releases.

Sources

view as markdown

📚 Deep Research

Outside research I commissioned on what to change in a small lab after Tailworm. Part of [[My Working Notes]].

Generated with:Grok research, edited for this site
Model:Not recorded
Length:3,334 words