Tailworm – TL;DR
On October 25, 2026, researchers published Tailworm: 11 security findings in Tailscale, the mesh VPN many small teams use to reach their servers. The headline attack lets someone who already controls one of your devices use Tailscale SSH to get root on other servers, then add a device of their own to your tailnet. However, there’s no fixed release, CVE or official advisory yet. But almost every finding needs a feature that’s off by default, so a 10-minute check tells you where you stand.
- Find every device with Tailscale SSH turned on and switch it off where you don’t need it, since it’s behind the headline attack.
- Then tighten the SSH rules you keep: one rule per person and server, and no root.
- Remove Serve and Funnel setups you don’t use, especially TCP forwards to Unix sockets.
- Keep auto-update on so the fix installs itself when it ships.
- Also turn on Tailnet Lock, because the report’s full attack only worked with it off.
This guide covers what Tailworm is, who’s exposed, how to check your tailnet, what to do until the fix ships, and how to tell whether anyone got in. Feel free to share it; we’ll update it when Tailscale publishes its advisory.
In this guide
- What is Tailworm?
- Are you affected by Tailworm?
- How to check your tailnet in 10 minutes
- How to reduce your risk until the fix ships
- Were you already hit?
- Lessons for small teams
- Tailworm FAQ
- Updates
- Sources
What is Tailworm?
Tailworm is a set of 11 findings in Tailscale 1.104.2 and headscale 0.29.5, an open-source alternative to Tailscale’s control server. Erica Windisch of Cyberdione Labs found them in lab tests on October 22–24 and then published them on tailworm.com. However, none has a CVE yet, and Tailscale hasn’t confirmed them.
| Feature | Findings | What goes wrong, in plain English | On by default? |
|---|---|---|---|
| Tailscale SSH | 1, 2, 3, 5 | Port forwarding inside a Tailscale SSH session runs as root, so a user can take over sockets that belong to root. An open session can also exhaust the server’s memory. | No |
| App connectors (experimental) | 4 | Anyone entitled to an app can make the connector send traffic almost anywhere, such as cloud metadata endpoints. | No |
| Serve and Funnel | 7–11 | Some Serve setups let peers reach Tailscale’s own control socket, let permissions for one path apply to another, or expose listeners outside the tunnel. | No |
| Self-hosted headscale | 6 | Anyone who can reach the server can exhaust its memory, without an account. | Not used with Tailscale’s own service |
| Relay (DERP) client | 6 | A malicious relay server can make a device use too much memory and crash Tailscale. | Yes, but needs a hostile relay |
Why Tailworm matters
Three details matter more than the count:
- It starts after a break-in. The headline attack needs a foothold on a device your tailnet already trusts, such as a laptop with a malicious package or a server with a vulnerable web app. In fact, Tailscale’s VP of Engineering, Mike Shaver, said most issues “concern what happens after someone has been authorized to connect” (VPNrevie.ws).
- There’s no patch yet. The disclosure wasn’t coordinated, so the report came out before a fix. Tailscale has merged related changes into its public code, but 1.104.2 is still the newest release (Tailscale on GitHub).
- No attacks reported so far. So far, the results come only from the researchers’ lab, and we found no public reports of exploitation as of October 26.
One caution: check your setup with Tailscale’s own settings and admin console, as in the steps below, rather than running third-party “Tailworm scanner” scripts on your servers.
Tailworm timeline, Oct 21–26
| Date | What happened | Source |
|---|---|---|
| Oct 26 | Tailscale merges changes that make SSH port forwards run as the logged-in user instead of root. Still no release. | GitHub |
| Oct 25 | Tailscale merges fixes for Serve permissions leaking between paths and for SSH memory exhaustion | GitHub, GitHub |
| Oct 25 | Tailworm report published with 11 findings and no CVEs | Tailworm |
| Oct 25 | Tailscale’s VP of Engineering responds on Reddit: the company is investigating with outside help, an advisory and patches will follow, and it isn’t asking everyone to turn off Tailscale SSH | VPNrevie.ws |
| Oct 24 | headscale 0.29.6 released; its notes don’t mention the findings | headscale |
| Oct 22–24 | Researchers test Tailscale 1.104.2 and headscale 0.29.5 in a lab | Tailworm |
| Oct 21 | Tailscale 1.104.2 released with an unrelated certificate fix (TS-2026-013) | Tailscale |
Dates are UTC.
Are you affected by Tailworm?
You are IF any device in your tailnet runs Tailscale SSH, Serve, Funnel or an app connector, or you run your own headscale server. Otherwise, the only finding that reaches you needs a malicious relay server, and even then the worst it can do is crash Tailscale on a device.
| Feature | Default | Findings | How to tell it’s on |
|---|---|---|---|
| Tailscale SSH | Off on every device | 1, 2, 3, 5 | The device’s Tailscale settings show SSH turned on (RunSSH) |
| Serve TCP forward to a Unix socket | Off | 7, 8 | The device’s Serve settings forward traffic to a Unix socket |
| Serve HTTPS with app permissions on several paths | Off | 11 | The device’s Serve settings list several paths with app permissions |
| Funnel | Off | 9 | Funnel is turned on for the device |
TS_SERVE_ALLOW_ALL_INTERFACES | Unset | 10 | Set in the Tailscale service’s or container’s environment |
| App connector | Off | 4 | Listed on the Apps page of the admin console |
| Self-hosted headscale | Not used with Tailscale’s service | 6 | You run your own control server |
Where Tailscale SSH hides
Tailscale SSH is off by default, but it’s a single setting to turn on and easy to forget, so check these places:
- Servers where someone turned Tailscale SSH on years ago and then forgot about it
- Setup scripts and config management, such as Ansible, Terraform, cloud-init and Dockerfiles, that switch it on
- Containers and Kubernetes sidecars with the SSH option in
TS_EXTRA_ARGS - Raspberry Pis, home-lab boxes and other Linux machines someone set up “just to try it”
The default-policy trap
However, turning Tailscale SSH on is only half of it, because your policy file decides who gets in. For example, new tailnets ship with an SSH rule that lets every member reach their own devices as any user, including root, in check mode (Tailscale docs). Check mode then asks you to sign in again every 12 hours by default. So on a small tailnet, turning on Tailscale SSH on one server lets a compromised laptop signed in as you open a root session there within that window.
A safer policy replaces that default with one rule per person and server: the person’s own account as the source, a single tagged server as the destination, and a named non-root user such as deploy instead of root. The Tailscale SSH docs also show the exact format.
How to check your tailnet for Tailworm in 10 minutes
Aim for one row per device, with each answer taken from the device itself rather than from memory. In particular, you’re looking for Tailscale SSH, Serve or Funnel, app connectors, and any self-hosted headscale server.
1. List every device in the admin console
Open the Machines page in the Tailscale admin console and copy the list, because that’s your checklist. Then open Access controls and read the "ssh" section of your policy file, and note any app connectors on the Apps page.
2. Linux servers
Next, on each Linux server, open Tailscale’s settings and check four things: Tailscale SSH (the RunSSH setting) is off, there’s no Serve or Funnel configuration, no app connector is advertised, and TS_SERVE_ALLOW_ALL_INTERFACES isn’t set for the Tailscale service. If Tailscale SSH is on, see the fixes below.
3. Macs, Windows PCs and phones
Only Linux and the open-source macOS build can run a Tailscale SSH server (Tailscale docs). The Mac App Store, standalone Mac, Windows, iOS and Android apps can’t, but Serve and Funnel work on desktops, so check every Mac and Windows PC for those too.
However, if a Mac runs the open-source build, for example one installed with Homebrew, check it the same way as a Linux server.
4. Containers and Kubernetes
Tailscale containers and Kubernetes sidecars, on the other hand, take their settings from environment variables. So look for the SSH option in TS_EXTRA_ARGS, a Serve configuration in TS_SERVE_CONFIG, and TS_SERVE_ALLOW_ALL_INTERFACES. Keep auth keys out of anything you copy while you check.
5. headscale servers
Note which headscale version you run, then read the "ssh" section of your policy. The report says headscale 0.29.5 allows port forwarding with every SSH rule and has no way to turn it off, so treat any headscale SSH rule as root access until a fix ships.
6. Record what you found
Finally, copy this tracker into a spreadsheet and add one row per device. The example row shows the level of detail to aim for.
| Device | Tailscale version | Tailscale SSH | Serve / Funnel | App connector | Action | Owner |
|---|---|---|---|---|---|---|
| Example: web-01 (Ubuntu 24.04) | 1.104.2 | On; default rule allows root | None | No | Turn SSH off; use OpenSSH over the tailnet | Ops lead |
How to reduce your Tailworm risk until the fix ships
There’s no fixed release yet, so the job is to shrink what Tailworm can reach. Start with shared and internet-facing servers, since attackers reach those first.
- Turn off Tailscale SSH where you don’t need it. Before you do, make sure you have another way in, such as regular OpenSSH over the tailnet.
- Replace wide SSH rules. In other words, swap the default rule, and anything like “all members to all servers”, for one rule per person and server with a named non-root user, as described above.
- Remove Serve and Funnel setups you don’t use, especially TCP forwards to Unix sockets.
- Stop advertising app connectors you don’t use, since the feature is still experimental.
- Turn on Tailnet Lock, so a new device needs a signature from one you trust before it can join.
- Keep node key expiry on wherever you can live with signing in again, so a copied key stops working.
- Keep auto-update on so the fixed release installs itself when it ships.
- Verify. Finally, re-run the checks above and record the result for every device.
Stopgaps by finding
| Mitigation | Covers | Limits |
|---|---|---|
| Turn off Tailscale SSH | 1, 2, 3, 5 | You need another way in, such as OpenSSH over the tailnet |
| One SSH rule per person and server, no root | Limits how far 1–3 spread | A trusted device can still reach what its rule allows |
| Remove Serve TCP forwards to Unix sockets | 7, 8 | The underlying check still needs Tailscale’s fix |
Leave TS_SERVE_ALLOW_ALL_INTERFACES unset | 10 | None; it’s off by default |
| Remove unused app connectors; firewall the destinations of the ones you keep | 4 | Needs an egress allowlist on the connector host |
| Memory limits, restart supervision and rate limiting for headscale | 6 | Limits the damage of a crash rather than preventing it |
| Tailnet Lock | The rogue-device step | Doesn’t stop root on the server itself |
Were you already hit by Tailworm?
Tailworm is a way to spread after a break-in, so look for signs of both. However, no official indicators of compromise exist yet. Still, any one of these is a reason to dig deeper:
- Devices on the Machines page you don’t recognize, especially tagged servers or devices with approved routes
- Auth keys you didn’t create, under Settings → Keys
- Device or key changes you can’t explain in the configuration audit log, under Logs
- Tailscale SSH logins you can’t explain in a server’s Tailscale logs
If something looks wrong
- Delete the device in the admin console, because reinstalling doesn’t revoke keys an attacker already copied.
- Then revoke auth keys and API keys you didn’t create or no longer need.
- Also rotate secrets reachable from affected servers: SSH keys, API tokens, database passwords and cloud credentials. If a device that signs for Tailnet Lock was involved, rotate its lock key too.
- Rebuild affected servers from a clean image rather than cleaning them in place.
Lessons from Tailworm for small teams
A private network is only as safe as its least-protected device. So use Tailworm to set up habits that outlast this report:
- Inventory features, not just versions. Know which devices run SSH, Serve, Funnel or connectors, as well as who owns each one.
- Grant access in pairs. One person, one server, one non-root user; no blanket “everyone reaches every server” rules.
- Treat every device as a way in. After all, a laptop that installs a malicious package is already inside your VPN.
- Turn on Tailnet Lock and key expiry, so a copied key or rogue device can’t quietly join.
- Keep auto-update on and know how fast fixes reach every device, containers included.
- Act on configuration, not headlines. You can check unconfirmed findings today, because the 10-minute check works whatever the advisory ends up saying.
This post reflects public information as of October 26, 2026. We’ll update it when Tailscale publishes an advisory or a fixed release.
Running PHP too? Then read our PHP2Shell guide. Want a second pair of eyes on your network? Get in touch with Testify Labs, or read more posts on our blog.
Tailworm FAQ
Does Tailscale 1.104.2 fix Tailworm?
No. In fact, 1.104.2 is the version the researchers tested. Fixes are in Tailscale’s code but not in a release yet; with auto-update on, the fixed version installs itself when it ships.
I don’t use Tailscale SSH. Am I affected?
Not by the main attack chain (findings 1–3 and 5). Check Serve, Funnel and app connectors too. If all of them are off, only the relay finding applies, and even then it needs a malicious relay server.
Can someone on the internet exploit Tailworm?
Not through Tailscale’s hosted service, because the attacks need a device that’s already in your tailnet. However, a self-hosted headscale server reachable from the internet is an exception, since an attacker can crash it without an account.
Are Macs, Windows PCs and phones affected?
So far, the researchers have only tested Linux. The Tailscale SSH server only runs on Linux and the open-source macOS build, so the app-store and standalone apps can’t be SSH targets. Any device can still be the compromised one an attack starts from.
Should I stop using Tailscale?
There’s no need. Turning off features you don’t use removes most of the risk. Meanwhile, Tailscale says an advisory and patches will follow.
Is there a CVE for Tailworm?
Not yet. Instead, the report uses its own finding numbers, and Tailscale’s security bulletins page has no entry for it as of October 26.
Is Tailworm being exploited?
We found no public reports of attacks as of October 26. So far, all the results come from the researchers’ lab.
Updates
- October 27, 2026: Published.
Sources
- Cyberdione Labs: Tailworm report
- Tailscale: Security bulletins
- Tailscale docs: Tailscale SSH
- Tailscale docs: Tailnet Lock
- Tailscale docs: Tailscale Serve
- Tailscale docs: App connectors
- Tailscale on GitHub: releases
- Tailscale on GitHub: relay Unix forward payloads as the bound user
- Tailscale on GitHub: fix serve app caps leaking across mounts
- headscale 0.29.6 release notes
- VPNrevie.ws: Tailworm, the Tailscale bugs that only bite if you let them in first
- Brandefense: Tailworm, Tailscale flaws and who is exposed