AI and security briefsSecurity
Is Tailscale SSH vulnerable to the Tailworm flaws, and does v1.104.4 fix them?
Published Updated Editorial policy
Tailscale says the fixes are in v1.104.4. The flaws let a peer already allowed to connect over Tailscale SSH act beyond its local user's permissions, including reaching root-only sockets such as Docker's. An outsider can't use them alone. Update every node, then tighten who may forward sockets.
Who should act: Anyone who runs Tailscale SSH or Tailscale Serve on servers or CI hosts, or self-hosts headscale, and has not confirmed that every node runs v1.104.4 or newer.
Update log
- : Published.
What happened
A researcher published a report named Tailworm on Saturday 24 October 2026, two hours after sending it to Tailscale, which says it was already investigating (Tailscale, 28 October). The researchers tested Tailscale v1.104.2 and headscale v0.29.5 between 22 and 24 October. On 26 October Tailscale posted an investigation update with interim advice.
The pages differ on timing. That update, marked updated 27 October, still says Tailscale is aiming for a client release by the end of Tuesday 27 October if testing finishes. A banner above it links four security bulletins and a blog post. The blog, dated 28 October, says the fixes are available in v1.104.4. GitHub shows that release at 01:05 UTC on 28 October, the researchers say it was tagged on 27 October, and the bulletins carry 26 October.
The bulletins cover four issues. TS-2026-014 covers Unix socket forwarding in Tailscale SSH, which ran as root and could reach root-only sockets such as Docker's or the tailscaled local API. TS-2026-015 is memory exhaustion that lets an authorized peer crash tailscaled. Serve with Unix backends is TS-2026-016, which Tailscale says allowed full node takeover. TS-2026-017 is a Serve race that mixes capability headers between mounts.
Severity is disputed. Tailscale says exploitation needs a foothold on an authorized peer and an SSH rule in the policy file, and calls it lateral movement inside the policy, not a worm. The researchers list root execution on target servers. Their 28 October snapshot lists a connector egress fix and the Funnel check as open, with the headscale fixes pending. Tailscale calls two Serve and Funnel findings by design and the connector bug unreleased.
Who is affected
- Nodes running Tailscale SSH, most of all where policy allows forwarding. The bulletins name the fix, v1.104.4, and no earliest affected version.
- Any node with Tailscale SSH enabled, for the memory bug. A session the policy permits is enough.
- Nodes using Serve with Unix socket backends where a local operator can write serve config, and Serve with TLS and two mounts that need different capabilities.
- Self-hosted headscale. Tailscale's pages don't cover it, and the researchers list headscale-side fixes for v0.29.5 as pending.
What we checked
Run on on the Mac that builds this site. Each command and its output are copied as they ran.
$ curl -s https://api.github.com/repos/tailscale/tailscale/releases/tags/v1.104.4 | grep -E '"(tag_name|published_at)"'
"tag_name": "v1.104.4",
"published_at": "2026-10-28T01:05:26Z",
$ curl -s https://tailscale.com/security-bulletins | grep -o 'TS-2026-01[4-7]' | sort -u
TS-2026-014
TS-2026-015
TS-2026-016
TS-2026-017
GitHub lists v1.104.4 as released at 01:05 UTC on 28 October, and Tailscale's bulletins page carries the four TS-2026-014 to 017 entries. No Tailscale client runs on this Mac, so there was nothing here to update.
What to do now
- List every node's client version. The admin console's Machines page shows it, and on a node:
tailscale version - Update to v1.104.4 or newer through your package manager, or on Linux with the built-in updater, then confirm the version.
sudo tailscale update --yes tailscale version - If a node can't update today, switch off forwarding. Tailscale says this mitigates several of the more serious findings without disabling Tailscale SSH. On Debian and Ubuntu the service environment file is /etc/default/tailscaled.
echo 'TS_SSH_DISABLE_FORWARDING=1' | sudo tee -a /etc/default/tailscaled sudo systemctl restart tailscaled - Put sensitive hosts in check mode and write rules for specific pairs of users and hosts. In the ssh section of the policy file:
{ "action": "check", "src": ["group:ops"], "dst": ["tag:prod"], "users": ["deploy"] } - Look for misuse since 22 October: tailscaled killed for memory, and containers nobody started.
journalctl -k --since 2026-10-22 | grep -i 'out of memory' | grep tailscaled docker ps -a --format '{{.CreatedAt}} {{.Names}} {{.Image}}' - On headscale, read its own release notes. The researchers advise treating every headscale SSH grant as root-equivalent until fixed.
What should have been in place
- SSH rules written per user and host pair, not identity-wide accept rules.
- Check mode on production hosts, which Tailscale recommends for sensitive systems.
- Forwarding off unless a named job needs it.
- Memory limits and restart supervision on hosts that run tailscaled.
- A node inventory with client versions and an update window measured in days.
Questions people ask
Can someone on the internet use the Tailworm flaws against my servers?
Tailscale says no, not on their own. The attacker needs a foothold on an authorized peer with SSH permitted in your policy. The researchers separately list an unauthenticated crash bug in headscale v0.29.5, which Tailscale doesn't ship.
Does Tailscale's status page say the patch is out?
Its body text still says Tailscale was aiming for the end of 27 October. The banner above it points to the bulletins and the 28 October blog, which say v1.104.4 has the fixes. Check the version on the node.
Should I turn Tailscale SSH off?
On 26 October Tailscale said it wasn't recommending that everyone disable it. After updating to v1.104.4, there is no reason to.
Is Tailworm a worm?
Tailscale says nothing self-replicates and movement is limited to connections the policy file already allows. The researchers chose the name.
Digiton's production review maps who can reach which host and with which privileges, and the checks it runs are on the vibe coded app audit page.
How this brief was made: researched from the sources below, drafted with AI assistance and checked against each source on the dates shown. See the editorial policy.
Sources
- Tailscale, SSH investigation and remediation update (updated 27 October), 27 October 2026, read 28 October 2026. https://tailscale.com/ssh-investigation-update
- Tailscale, Tailscale SSH findings and fixes, 28 October 2026, read 28 October 2026. https://tailscale.com/blog/tailscale-ssh-findings-fixes
- Tailscale, security bulletins TS-2026-014 to TS-2026-017, 26 October 2026, read 28 October 2026. https://tailscale.com/security-bulletins
- GitHub, tailscale v1.104.4 release, 28 October 2026, read 28 October 2026. https://github.com/tailscale/tailscale/releases/tag/v1.104.4
- Tailworm, security assessment report of Tailscale v1.104.2 and headscale v0.29.5, 27 October 2026, read 28 October 2026. https://tailworm.com/
- Hacker News, Tailscale SSH investigation and remediation update, 27 October 2026, read 28 October 2026. https://news.ycombinator.com/item?id=50264857
More briefs
How these briefs are sourced and corrected. All AI and security briefs
Building something that has to hold up in production?
Start with a free 25-minute scoping call. If it fits, the first paid step is a production review: five working days on your real repository, scored against ten layers, with a costed fix list.
Book a 25-minute scoping call