AW Dev Rethought Flash: Tailworm — 11 Unpatched Tailscale Flaws and No Fix Yet

Tailscale has confirmed the Tailworm findings. VP of Engineering Mike Shaver: "These are serious security issues, and we're treating them accordingly."

On 25 October, Erica Windisch of Cyberdione Labs published 11 security flaws in Tailscale v1.104.2 and headscale v0.29.5. The findings were reproduced in a lab against unmodified releases between 22 and 24 October, then released publicly without coordinated disclosure.

Two days later Tailscale validated them, opened an investigation page, and targeted a patched client release for 27 October. The company says it is still verifying the full scope and which configurations are affected. No CVE IDs have been assigned.

The researcher named the cluster Tailworm, and that name is doing real work.

The SSH Forwarding Flaw

The headline finding concerns Tailscale SSH. According to the researcher, when Tailscale SSH is enabled, unix-socket port forwarding runs as root.

A user holding one approved device and an SSH rule for a target node can obtain root on that target. On its own that is already a serious privilege escalation — it means your ACL policy is not the thing deciding what a principal gets. If you deliberately restricted someone to a non-privileged account on that host, that restriction was declared but not enforced.

The second half is what elevates it. The researcher reports that the same access allows capture of enrollment keys from the compromised host.

Why It Is Called Tailworm

Enrollment keys are what let a machine join a tailnet. If you can reach root on a node and lift its enrollment material, you are no longer bounded by the ACL rule you started with. You can enroll as something new, carrying whatever access that identity has, and do it again from there.

One compromised laptop becomes root on a server. That server yields credentials to the mesh. Those credentials reach the next server. Each hop expands what the next hop can touch.

That is a propagation path rather than a single escalation, and propagation paths are what turn an incident into an outage.

The Other Findings

The SSH issue is the most severe but not the only one. Three further categories were disclosed.

Experimental app connectors can bypass ACL policy. Per the report this includes reaching cloud metadata endpoints and internal LAN addresses — the two destinations you least want a bypass pointed at. Cloud metadata services are a well-worn route to instance credentials, and internal LAN reachability defeats the point of segmenting what a tailnet member can touch.

A tailscale serve forward can expose the local API, which is the control surface for the daemon on that machine.

headscale and DERP are both vulnerable to memory exhaustion. These are availability issues rather than access ones, but headscale is the self-hosted control plane for a lot of deployments and DERP relays traffic when a direct connection cannot be established.

Full technical detail on all 11 has not been published in one place, and the upstream report dates are not documented.

How Bad Is It, Honestly

The researcher rates this High, and Tailscale has now called the issues serious. What has not changed is the attack prerequisite, and that matters for how you triage.

This is lateral movement from an existing foothold, not internet-facing remote code execution. Nobody is scanning the internet and taking your tailnet. An attacker needs one approved device on your tailnet and an SSH rule before any of it begins.

That caveat should lower your panic without lowering your priority. The entire argument for a zero-trust mesh is that one compromised endpoint should not become access to everything behind it. Device compromise is the threat model Tailscale exists to contain — a phished laptop, a stolen session, a contractor’s machine with something on it. A flaw that converts precisely that event into root across your fleet is attacking the product’s central promise, not a peripheral feature.

So: not an emergency in the drop-everything sense. An emergency in the sense that your blast radius is considerably larger than your architecture diagram claims.

Published Without Coordination

The researcher states the issues were reported upstream but that the release was not coordinated with Tailscale.

For two days that left operators in the worst available configuration: the flaws public, reproducible, and described well enough to act on, with nothing shipped. Whatever one makes of the ethics, defenders and attackers received this information at the same moment, and only one of those groups needed the vendor's cooperation to proceed.

The counterargument has some force now. Tailscale moved from silence to a confirmed advisory, a named mitigation and a targeted patch inside roughly 48 hours — faster than many coordinated disclosures manage. Whether that speed vindicates the method or merely survived it is a judgement call, and a reasonable person could land either way.

What is not a judgement call is the practical lesson: for those two days, the only thing between a compromised device and a fleet was each operator's own configuration.

What To Do Right Now

Tailscale is not recommending that everyone disable Tailscale SSH. Its guidance is narrower: set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart the service. That addresses several of the more serious findings without turning the feature off.

If you were about to disable Tailscale SSH outright, confirm you have another route into the device first — Tailscale's own documentation warns about exactly that.

Alongside it: audit where Tailscale SSH is actually enabled, which in most tailnets is broader than people remember, because it is convenient, it gets switched on per node, and then it is forgotten. Tighten SSH access policies to only the users and devices that genuinely need them, use per-pair grants, and deny forwarding in each rule where you can.

Beyond SSH: remove the app connector capability where it is not needed, audit any tailscale serve forwards targeting unix sockets, and if you self-host headscale, set memory limits and restart supervision on your control plane.

One more that is easy to miss. If you believe a device was compromised, delete it at the control plane rather than reimaging it. Reimaging does not help, because the enrollment keys have already been copied.

Then apply the patched client release as soon as it lands, and watch Tailscale's security bulletins directly rather than the news cycle. That page is where the version number will appear, and the version number is the thing that ends this.