> ## Content Index
> Fetch the complete content index at: https://bullquill.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Tailscale vulnerability: Tailworm alleges 11 unpatched flaws
- URL: https://bullquill.com/tailscale-ssh-tailworm-flaws-what-to-do/
- Published: 2026-10-26T02:14:28.000Z
- Updated: 2026-10-26T02:26:23.000Z
- Description: A researcher's lab report says one trusted device with Tailscale SSH forwarding can reach root on other machines. Tailscale is working on fixes, but there is no CVE or patched release yet.
- Author: Rowan Ashby
- Tags: Tech, Trending, Tailscale, Tailscale SSH, Headscale, Tailworm, Cybersecurity, #lang-en, #tr-tailscale-ssh-tailworm-flaws-what-to-do

## Key takeaways

- Researcher Erica Windisch of Cyberdione Labs published "Tailworm" on 25 October 2026, describing 11 findings in Tailscale v1.104.2 and headscale v0.29.5.
- The most serious claim: if a Tailscale SSH rule allows port forwarding, a user on an approved device can make the root-run `tailscaled` daemon reach root-only sockets on the target.
- The release was "reported but not coordinated", according to Windisch. As of 26 October there is no CVE, no Tailscale security bulletin and no fixed version.
- Tailscale says it received the report, had already been reviewing the same areas with outside specialists, and is working on fixes. It is not advising every customer to switch off Tailscale SSH.
- Admins can reduce exposure now: narrow SSH rules to single source-destination pairs, stop forwarding where possible, enable Tailnet Lock and key expiry, and remove unneeded serve and app connector settings.

A new Tailscale vulnerability report, Tailworm, claims a user on one approved device can reach root on other machines when Tailscale SSH rules allow port forwarding. Tailscale is working on fixes, but there is no CVE or patched release yet.

The report does not describe an internet-facing attack. Every SSH path in it starts from a device the attacker already controls and that the network's access rules already trust. That makes it a lateral-movement problem: it matters most for companies whose Tailscale policies give broad SSH access across many servers.

## What the Tailworm report claims

The report, published at tailworm.com, lists eleven findings across Tailscale SSH, the `tailscale serve` feature, the experimental "conn25" app connector, the DERP relay code and headscale, the open-source control server. Windisch rates eight of them High or Medium-High. The report states that the researchers are not affiliated with Tailscale and were not paid for the work.

The headline chain uses three SSH findings together. According to the report, standard SSH local forwarding (`-L`) to a Unix socket makes the root-run `tailscaled` process connect to sockets that only root should reach. Remote forwarding (`-R`) can replace root-owned sockets so the attacker impersonates the service behind them. A time-of-check to time-of-use (TOCTOU) race lets the checked path be swapped before the real connection happens.

The report says no `sudo` rights or `docker` group membership are needed on the target. In the lab, the chain was also used to capture an enrollment key and join a rogue machine to the tailnet as a trusted node.

### Main findings at a glance

| Finding (report numbering)              | Area                          | Researcher rating | What it needs                                   |
| --------------------------------------- | ----------------------------- | ----------------- | ----------------------------------------------- |
| 1\. SSH \-L Unix-socket forwarding      | Tailscale SSH                 | High              | SSH rule that permits forwarding                |
| 2\. SSH \-R Unix-socket forwarding      | Tailscale SSH                 | High              | SSH rule that permits forwarding                |
| 3\. TOCTOU race in path allowlist       | Tailscale SSH                 | High              | SSH rule that permits forwarding                |
| 4\. conn25 egress not validated         | App connectors (experimental) | High              | conn25 configured, ordinary app entitlement     |
| 5\. SSH session memory exhaustion       | gliderlabs/ssh (upstream)     | High              | Authenticated SSH session                       |
| 6\. Memory exhaustion                   | headscale and DERP client     | Medium-High       | Internet reach to headscale, or a hostile relay |
| 7\. serve --tcp to the local API socket | tailscale serve               | High              | Serve-configuration access on the node          |

*Source: Tailworm security assessment, Cyberdione Labs, October 2026\. Ratings are the researcher's own and have not been confirmed by Tailscale. Findings 8 to 11 cover serve, Funnel and HTTP/2 issues rated Medium or lower.*

## Which Tailscale setups are exposed

The SSH findings apply only where all of these are true: Tailscale SSH is enabled on the target, an SSH rule lets the attacker's device connect to it, and that rule permits forwarding. On headscale, the report says forwarding is granted on every accepted SSH session and cannot be switched off in v0.29.5, so any headscale SSH grant should be treated as root on the target.

Tailnet Lock changes the picture, but only partly. The report says the rogue-node step was demonstrated end to end only on tailnets without Tailnet Lock, which is the default. With the lock enabled, the researchers say they captured disablement secrets and signer-key material in transit but did not actually disable the lock.

Check mode is not a fix. The report notes that check mode only gates the start of a session, so it does not limit what forwarding does once a session is open. Tailscale's own documentation describes check mode as requiring users to re-authenticate before an SSH connection is established.

The "worm" label is disputed. Windisch argues that one compromised device can spread to every device the rules allow. Several commenters on Hacker News pushed back, with one calling it "not wormable in the traditional sense", because each hop still needs an SSH rule that permits it.

## What Tailscale has said so far

Mike Shaver, Tailscale's vice president of engineering, wrote on Reddit that the company had received the report and had already been examining the same areas with outside security specialists, finding issues it is now working to fix, according to The Hacker News and ThreatTicker. He said Tailscale was still working out which configurations are affected and was not recommending that all customers disable Tailscale SSH.

A Tailscale engineer posting on Hacker News added that "we will have more details to follow". No timeline was given. The company's public security bulletin page lists TS-2026-013, dated 21 October and unrelated to Tailworm, as its newest entry; that fix shipped in v1.104.2, the version Windisch tested.

This is not the first time the area has needed work. Tailscale's bulletins show earlier SSH fixes in 2026, including TS-2026-004 (a Unix-socket symlink bypass in SSH forwarding, fixed in 1.98.9) and TS-2026-009 (usernames with leading dashes that could open a root session, also fixed in 1.98.9).

## What admins can do now

Until Tailscale publishes a bulletin and a fixed release, these steps come from the Tailworm report and from Tailscale's documentation. None of them requires waiting for a patch.

1. **Narrow SSH rules.** Replace rules that grant SSH from a whole group or tag to many servers with single source-to-destination pairs. Remove `root` and other privileged accounts from the `users` list where you can. The report says narrow pairs stopped propagation in testing.
2. **Stop forwarding where possible.** ThreatTicker's summary says forwarding can be disabled per rule on Tailscale's hosted control plane but not on headscale 0.29.5\. Tailscale's public SSH reference lists only the fields `action`, `src`, `dst`, `users`, `checkPeriod` and `acceptEnv`, so confirm the setting with Tailscale before relying on it.
3. **Consider pausing Tailscale SSH on sensitive hosts.** Windisch recommends disabling Tailscale SSH and app connectors. Tailscale does not go that far, but hosts that hold credentials or enrollment keys are the obvious place to start.
4. **Enable Tailnet Lock and node-key expiry.** The rogue-node step worked end to end only without Tailnet Lock in the lab.
5. **Clean up serve and connectors.** Drop any `tailscale serve` forward that points to a Unix socket, and remove app connector entitlements from devices that do not need them.
6. **Harden self-hosted headscale.** Keep it off the open internet where possible and add memory limits, restart supervision and rate limits.
7. **Turn on auto-updates.** Running `tailscale set --auto-update` on Linux hosts means a fix lands without manual work once released.
8. **Revoke, do not just reimage.** If you suspect a device is compromised, delete it in the admin console. The report warns that reimaging alone does not revoke copied keys.

## What is still unconfirmed

Readers should keep the gaps in view. Tailscale has not confirmed the specific technical claims. The proof-of-concept code has not been made public. No other researcher has publicly reproduced the findings. The severity ratings are the researcher's own. As RuntimeWire noted, the lab demonstrations do not show that any customer system has been compromised.

The decision to publish without coordinated disclosure is itself part of the story. Windisch says she sent the report and proof-of-concept to Tailscale's security contact before going public, and the report argues that "infrastructure is vulnerable today". The debate echoes recent arguments over [how open-source projects handle bug disclosure](https://bullquill.com/bitcoin-core-ai-bug-disclosure-policy/).

## What it means

For most small tailnets with a handful of devices and tight rules, the practical risk is limited: an attacker first needs a trusted device and an SSH rule that reaches the target. The exposure grows with the kind of setup many companies use, where one tag or group gets SSH into every server.

The lasting lesson is that a mesh VPN is only as segmented as its access policy. Teams already working through [emergency patch cycles](https://bullquill.com/php-emergency-security-patches-what-to-do/) or tracking [supply-chain intrusions that move from one foothold](https://bullquill.com/storm-0940-artex-ai-agents-connectwise-attack/) will recognise the pattern: tighten the rules now, then patch fast when the fix arrives. Bullquill will update this page when Tailscale publishes a bulletin, CVE or fixed version. More coverage is on our [Tailscale](https://bullquill.com/tag/tailscale/) topic page.

## Frequently asked questions

### What is the Tailworm Tailscale vulnerability?

Tailworm is a report published on 25 October 2026 by Erica Windisch of Cyberdione Labs. It describes 11 findings in Tailscale v1.104.2 and headscale v0.29.5, led by a Tailscale SSH Unix-socket forwarding issue that the researcher says lets a user on a trusted device reach root on the target machine.

### Is there a patch or CVE for the Tailscale SSH flaws?

Not as of 26 October 2026\. Tailscale has not published a security bulletin, CVE or fixed version for the Tailworm findings. The company says it is working on fixes and that more details will follow.

### Should I disable Tailscale SSH?

The researcher recommends disabling Tailscale SSH and app connectors. Tailscale is not recommending that all customers disable it. A middle path is to narrow SSH rules to single source-destination pairs, stop forwarding where possible, and pause Tailscale SSH on the most sensitive hosts.

### Does Tailnet Lock protect against Tailworm?

Partly. The report says the rogue-node step worked end to end only on tailnets without Tailnet Lock. It does not stop the SSH forwarding path to root on a target that an SSH rule already allows.