---
title: "Tailworm and Tailscale: What a Homelab Owner Should Do"
summaryNote: "research-tailworm-tailscale"
created: "2026-10-25"
wordCount: 3334
model: "Not recorded"
aiSource: "Grok research, edited for this site"
context: "Outside research I commissioned on what to change in a small lab after Tailworm. Part of [[My Working Notes]]."
summary: "Tailworm's serious findings need an already-compromised device plus Tailscale SSH or serve. Leave those off, gate new devices, and do not treat Headscale as a fix."
---

# 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](https://tailworm.com/), 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](https://www.cve.org/CVERecord?id=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](https://www.reddit.com/r/Tailscale/comments/1xeoj1l/)). 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:

- Newest client release remains [v1.104.2](https://github.com/tailscale/tailscale/releases) (21 Oct). No newer release.
- [Security bulletins](https://tailscale.com/security-bulletins) top out at TS-2026-013 (unrelated eMudhra certificates). No Tailworm bulletin.
- No GitHub Security Advisory and no CVE for these findings in NVD / cve.org searches run for this brief.
- Finding 11 (serve App-Capabilities race) was fixed on 24 Oct in [commit 566f89e](https://github.com/tailscale/tailscale/commit/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225) (PR #21931). Any Tailscale release after 1.104.2 that includes this commit carries the fix; the [changelog](https://tailscale.com/changelog) lists it.
- Finding 5 (an authenticated SSH session can make `tailscaled` run out of memory) is fixed upstream. On 25 Oct at 1:28 PM PDT, Tailscale's James Tucker committed a change to its SSH library, [gliderssh 6662764](https://github.com/tailscale/gliderssh/commit/66627641389f2b2b5d75998729f551fae6680a8e), that says "An authenticated client could exhaust memory in the server process with per-session state that persisted after disconnect." It credits "the security audit" and measured about 536 MB in 7 seconds. Tailscale's `main` picked it up at 2:05 PM ([PR #21945](https://github.com/tailscale/tailscale/pull/21945)). Not in a release.
- Findings 1 to 3 have an open fix from Tailscale engineer James Tucker ("raggi"). The first of five pull requests, [#21937](https://github.com/tailscale/tailscale/pull/21937) (the monitor's message codec and file-descriptor passing), merged to `main` at 3:23 PM PDT on 25 Oct. Four remain open (#21941, #21942, #21943, #21944); a sixth, #21939, was folded into the others. PR #21942 routes SSH forwarding through a privileged monitor so sockets are "dialed and bound by children with the authenticated local user's credentials, never by root tailscaled." That one is not merged, and none of the fix is in a release.
- Host-side mitigation available today without a new release: environment variable `TS_SSH_DISABLE_FORWARDING` is registered in `ssh/tailssh/tailssh.go` at v1.104.2 and blocks local and remote TCP and Unix-socket forwarding while leaving shells and SFTP available. Unraid's Tailscale plugin opened a PR on 25 Oct to expose it, citing Tailworm.

**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](https://x.com/NetworkChuck/status/2114355634615513270) (about 73.5K views, 1,763 likes): "Dude, can we please stop publishing vulns before they are disclosed to the vendor!?!?!?!??!" Gregory Kurtzer ([@gmkurtzer](https://x.com/gmkurtzer/status/2114372665184309677)) argued that circumventing embargos harms users.
2. **Defense of short or full disclosure.** Windisch ([@birdhax](https://x.com/birdhax/status/2114369603803726274)): "I believe in continuous disclosure… I do not want users in the dark about risks via obscurity practices." [@ThePrimeagen](https://x.com/ThePrimeagen/status/2114387631639286111) (about 26.9K views): "Thanks Erica."
3. **Calm / not-hacked framing.** [@cocktailpeanut](https://x.com/cocktailpeanut/status/2114385291301535885): "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](https://x.com/TheAhmadOsman/status/2114395742160977925) (about 6.7K views, 164 likes): "There’s a reason I tell everyone to skip Tailscale and setup WireGaurd directly." A reply from [@lostonwww](https://x.com/lostonwww/status/2114407383942271458) 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](https://x.com/theonejvo/status/2114417981015097641)) called Tailworm "a misconfiguration checklist wearing a worm costume" and published [tailslop](https://github.com/orlyjamie/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](https://x.com/IntCyberDigest/status/2114291878720151623) (about 613K views) set the "skipped coordinated disclosure" framing that most quote-tweets repeated. [@alexhillman](https://x.com/alexhillman/status/2114164454971560062) (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 node | 1, 2, 3, 5 |
| `tailscale serve` or Funnel | 7, 8, 9, 10, 11 |
| App connectors / conn25 | 4 |
| Headscale reachable from the internet | 6 (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](https://tailscale.com/kb/1193/tailscale-ssh)). 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):

- **Tailscale Personal (SaaS control plane, BSD-3 client).** You trust Tailscale Inc. for coordination, ACLs, and DERP; WireGuard data-plane keys stay on your devices. Personal plan is free for non-commercial use, up to 6 users, unlimited user devices, up to 50 tagged resources, Tailnet Lock included ([pricing](https://tailscale.com/pricing), fetched 25 Oct 2026: "Personal users have access to the free tier plan for non-commercial use, which will be free forever"). Client-side Tailworm findings apply only if you enable the features above. Tailnet Lock is available on the Personal and Enterprise plans only ([docs](https://tailscale.com/kb/1226/tailnet-lock)); a business on Standard or Premium cannot use it. Turning the risky features off removes most of this incident's exposure without leaving Tailscale.
- **Headscale (BSD-3).** Self-hosted control server; you still run the official Tailscale **client**. Windisch tested headscale 0.29.5. Client findings **1, 2, 3, 5, 7, 8, 10, 11** still apply. Finding 6's server half applies if Headscale is exposed. Funnel is unsupported; Tailnet Lock is not implemented ([features](https://headscale.net/stable/about/features/); open request [#1307](https://github.com/juanfont/headscale/issues/1307)). She claims Headscale 0.29.5 always grants SSH forwarding on accepted sessions (CLAIMED, not independently confirmed here).
- **Plain WireGuard (MIT).** No Tailscale SSH, serve, Funnel, or conn25, so none of the 11 findings apply. You take on key distribution, NAT, DNS, and policy yourself.
- **Nebula (MIT).** Certificate authority plus lighthouse; Tailworm does not apply. You run a CA (`ca.key` is critical) and a routable lighthouse.
- **NetBird.** Client BSD-3; management/signal/relay directories AGPLv3. Self-host quickstart needs a public Linux VM, DNS, TCP 80/443 and UDP 3478 ([docs](https://docs.netbird.io/selfhosted/selfhosted-quickstart)). Different codebase; Tailworm does not apply. Cloud option exists if you accept a vendor.
- **Netmaker.** Apache-2.0 core with a separate proprietary `pro/` tree. Confirm needed features are in the open core before depending on it.
- **innernet (MIT).** Opinionated WireGuard with a small community; Tailworm does not apply.

**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.

- Inventory Tailscale SSH on every node. If on: `sudo tailscale set --ssh=false` after confirming OpenSSH or console still works, or set `TS_SSH_DISABLE_FORWARDING=true` for `tailscaled` until a patched release ships.
- Remove broad `ssh` policy rules; prefer per-pair grants if any Tailscale SSH remains.
- Enable Tailnet Lock if your plan offers it (Personal or Enterprise). It cannot run alongside device approval, so turn device approval off first. Tailscale notes that "Tailnet Lock keys are stored on the device. If the device is compromised, the key can be obtained," so make only your most trusted personal machines signing nodes, never a server that runs agents or Tailscale SSH.
- Confirm serve / Funnel / app connectors are unused, or audit them against findings 4 and 7 to 11.
- Prefer one-off auth keys; enable node-key expiry on tagged servers; delete a compromised device at the control plane (reimaging alone does not revoke a stolen state file; Windisch demonstrates copying state).
- Keep auto-update on where supported; watch for a release that mentions Tailworm, corp#50380, or ssh-monitor.

**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](https://tailscale.com/security-bulletins), [releases](https://github.com/tailscale/tailscale/releases), [Reddit thread](https://www.reddit.com/r/Tailscale/comments/1xeoj1l/), [tailworm.com](https://tailworm.com/), [headscale releases](https://github.com/juanfont/headscale/releases).

## Sources

- [Tailworm report (Cyberdione Labs / Erica Windisch)](https://tailworm.com/) Primary write-up of the 11 findings, prerequisites, PoC names, and disclosure note
- [Tailscale security bulletins](https://tailscale.com/security-bulletins) Confirmed no Tailworm bulletin as of this writing; TS-2026-013 context
- [Tailscale GitHub releases](https://github.com/tailscale/tailscale/releases) Newest tag v1.104.2
- [Mike Shaver, r/Tailscale, 24 Oct 2026](https://www.reddit.com/r/Tailscale/comments/1xeoj1l/) Full vendor response text
- [Commit 566f89e / PR #21931](https://github.com/tailscale/tailscale/commit/566f89e0fb2aa4b2f1ebf98761e45e62aa5ef225) Finding 11 fix on main
- [PR #21942 (ssh-monitor forwarding)](https://github.com/tailscale/tailscale/pull/21942) Open privilege-drop fix for findings 1 to 3
- [gliderssh commit 6662764](https://github.com/tailscale/gliderssh/commit/66627641389f2b2b5d75998729f551fae6680a8e) Finding 5 fix
- [Tailscale PR #21945](https://github.com/tailscale/tailscale/pull/21945) gliderssh update on `main`
- [Tailscale PR #21930](https://github.com/tailscale/tailscale/pull/21930) tsnet ListenSSH hardening
- [Tailnet Lock docs](https://tailscale.com/kb/1226/tailnet-lock) Plans, device approval, key storage
- [Device approval docs](https://tailscale.com/kb/1099/device-approval) New-device gate on every plan
- [tailslop](https://github.com/orlyjamie/tailslop) O'Reilly's read-only triage script
- [X: @theonejvo](https://x.com/theonejvo/status/2114417981015097641) "Misconfiguration checklist" thread
- [X: @raggi on disclosure](https://x.com/raggi/status/2114432160514134061) Tailscale engineer on disclosure and PoCs
- [`TS_SSH_DISABLE_FORWARDING` in v1.104.2](https://github.com/tailscale/tailscale/blob/v1.104.2/ssh/tailssh/tailssh.go) Host-side forwarding off switch
- [Unraid Tailscale plugin PR #120](https://github.com/unraid/unraid-tailscale/pull/120) Exposes the forwarding knob; cites Tailworm
- [Hacker News item 50227138](https://news.ycombinator.com/item?id=50227138) Windisch and Tailscale engineer comments
- [CVE-2026-79619](https://www.cve.org/CVERecord?id=CVE-2026-79619) Prior OpenZFS credit for Windisch
- [Full Disclosure, OpenZFS, 16 Aug 2026](https://seclists.org/fulldisclosure/2026/Aug/40) Her prior full-disclosure practice in her words
- [Tailscale pricing](https://tailscale.com/pricing) Personal plan free-tier limits
- [Headscale features](https://headscale.net/stable/about/features/) What Headscale does and does not implement
- [Headscale issue #1307](https://github.com/juanfont/headscale/issues/1307) Tailnet Lock not implemented
- [WireGuard](https://www.wireguard.com/) Plain WireGuard baseline
- [Nebula](https://github.com/slackhq/nebula) MIT overlay option
- [NetBird self-host quickstart](https://docs.netbird.io/selfhosted/selfhosted-quickstart) Self-host requirements
- [NetBird LICENSE](https://github.com/netbirdio/netbird/blob/main/LICENSE) BSD-3 / AGPLv3 split
- [Netmaker LICENSE](https://github.com/gravitl/netmaker/blob/master/LICENSE.md) Apache-2.0 core with pro/ carve-out
- [innernet](https://github.com/tonarino/innernet) MIT WireGuard wrapper
- [X: @birdhax](https://x.com/birdhax) Researcher's posts on notice window, PoCs, continuous disclosure
- [X: @NetworkChuck](https://x.com/NetworkChuck/status/2114355634615513270) Disclosure-process reaction
- [X: @cocktailpeanut](https://x.com/cocktailpeanut/status/2114385291301535885) Not-unauthenticated framing
- [X: @AnzalAbidi](https://x.com/AnzalAbidi/status/2114362504788992420) Named partial verification
- [X: @GrahamHelton3](https://x.com/GrahamHelton3/status/2114408226431148360) Named critique of report readability
- [X: @TheAhmadOsman](https://x.com/TheAhmadOsman/status/2114395742160977925) WireGuard-direct reaction
- [X: @IntCyberDigest](https://x.com/IntCyberDigest/status/2114291878720151623) High-reach framing post
- [X: @alexhillman](https://x.com/alexhillman/status/2114164454971560062) ACL lockdown prompt
- [LinkedIn: Erica Windisch](https://www.linkedin.com/in/ewindisch) Roles at Docker, Magnum, IOpipe (profile text)
- [TechCrunch on IOpipe, 14 Aug 2017](https://techcrunch.com/2017/08/14/with-2-5m-in-seed-funding-iopipe-brings-monitoring-to-serverless-applications/) Contemporaneous IOpipe / Docker security-team coverage