Tuesday, 3 November 2026Global tech news & guides — what changed, and what it means for you.
AuTechWire
Original editorial illustration of a dark server room at night, a glowing tunnel of light running between two server racks, with a small side door in the tunnel wall standing open

Tailworm: Tailscale SSH Flaws Fixed in 1.104.4 — What to Update Now

by

In brief

  • Tailscale fixed the reported Tailworm SSH flaws in version 1.104.4. What the four bulletins cover, who must update, and what to change tonight.
  • Researcher Erica Windisch of Cyberdione Labs published the “Tailworm” report on October 25, 2026, after testing Tailscale 1.104.2 and headscale 0.29.5 between October 22 and 24. It describes 11 flaws, most rated high severity.
  • The core mechanism is privilege, not authentication: the Tailscale daemon runs as root, and the reported flaws abuse socket-forwarding operations the daemon performs with its own elevated privileges rather than the SSH user’s.
  • Tailscale published four security bulletins (TS-2026-014 through TS-2026-017) on October 26 and shipped the fix in version 1.104.4 on October 28, changing forwarding to run as the logged-in user rather than as root. The bulletins carry no CVE identifiers or severity ratings, and no exploitation in the wild has been reported. Headscale fixed its server-side findings in version 0.29.7, released October 30, 2026.
  • What to change tonight: update every node to 1.104.4 or later; where you cannot update yet, disable SSH forwarding where you do not need it (TS_SSH_DISABLE_FORWARDING=1, set on the node), replace broad access rules with single source-to-destination pairs, and turn on SSH check mode. If a device is compromised, delete it at the control plane — reimaging alone does not revoke its keys.

Update, November 1, 2026: Headscale released version 0.29.7 on October 30, a security release that fixes the Tailworm server-side findings: pending registrations are now kept at capacity instead of evicting approvals awaiting review, pending registration data is capped, and the amount of an unexpected relay response read is bounded. Headscale calls none of its side of the findings critical but says some could cause denial of service, and recommends upgrading to 0.29.7 and Tailscale 1.104.4 or newer, especially for Tailscale SSH users. Upgrading headscale alone does not fix the client-side flaws, which live in tailscaled on each node. The passages below that described the headscale findings as unfixed have been corrected.

The trust inversion at the heart of Tailworm

Tailscale SSH is popular precisely because it removes the painful parts of SSH: no key distribution, no bastion hosts, access governed by the same identity and access rules as the rest of the tailnet. A device joins, an admin writes a rule, and an approved user can open a shell. That convenience rests on a daemon, tailscaled, that runs with root privileges on every machine and brokers those sessions.

Tailworm’s central claim is that this architecture inverts under attack. When a user asks Tailscale SSH to forward a local or remote Unix socket, the daemon performs that socket operation with its own root privileges rather than restricting it to the permissions of the authenticated SSH user. Unix sockets are the back doors of a Linux system: they front container runtimes, system services, and administrative APIs that are root-only by design. If a forwarded socket operation runs as root, a user who should only reach their own files can reach services that answer only to root.

That is the mechanism behind the most serious reported findings. In Windisch’s lab, local socket forwarding reached root-only sockets and read the system password file. Remote socket forwarding replaced a root-owned socket, which led to root code execution through a command daemon. A timing gap between a path check and the file action that follows it let a rogue node join the network. None of these required a stolen password or a stolen key — they required an attacker-controlled device that the network’s own access rules already permitted to reach the target, plus SSH forwarding enabled on that path.

The word “wormable” comes from the reported speed: lab demonstrations spread across devices permitted by access rules in under a second per step. That characterization is disputed by some researchers, and it is important to keep the dispute attached to the claim. What was demonstrated in a lab, under access rules that permitted the movement, is not the same as a worm loose on real networks. But the underlying point survives the dispute: once an attacker holds one permitted device, the reported flaws convert that foothold into a path to root on the next permitted machine, and the access rules themselves supply the map.

The eleven findings, in plain terms

Cyberdione Labs disclosed 11 flaws across Tailscale SSH, app connectors, headscale, and Tailscale Serve. The severity pattern matters more than the count: eight of the findings are rated high, and they cluster around three ideas — forwarding that runs as root, checks that can be raced or bypassed, and registrations that should not be possible.

The forwarding findings are the core. Local socket forwarding running as root reaches root-only sockets. Remote socket forwarding replaces root-owned sockets. A race between a safety check and the file action it guards lets an attacker swap in a different path. Together, these turn “SSH forwarding enabled” from a convenience into a privilege boundary failure — for any user the access rules permit.

The app-connector finding widens the blast radius beyond SSH. An ordinary user entitlement reportedly allowed any outbound destination through a connector, reaching cloud metadata services and Kubernetes APIs — the kind of internal services that trust the network rather than the caller. The serve findings are similar in shape: a TCP forward to the local API socket let a remote peer write to the local API, and a symlink swapped after setup defeated a socket guard.

The headscale and DERP findings affect self-hosters most directly. Unauthenticated registrations could evict pending device approvals, and a hostile relay could force a client to read up to 1.34 GB. Headscale 0.29.7, released October 30, addresses both: pending registrations are kept at capacity instead of evicting approvals awaiting review, and the amount of an unexpected relay response read is bounded. The report found SSH forwarding could not be disabled in headscale policy; the node-side TS_SSH_DISABLE_FORWARDING=1 setting is the switch that works regardless of control plane.

One more finding deserves its own sentence because it is easy to miss: session churn reportedly caused the root daemon to allocate about 536 MB in 7 seconds, a memory-exhaustion path available to any authenticated SSH session. It does not yield root, but it gives an authenticated user a denial-of-service lever against the daemon itself.

What Tailscale did: four bulletins, one fixed release

Precision about the vendor’s position is part of the story, not a courtesy. Tailscale published four security bulletins on October 26 — TS-2026-014 through TS-2026-017 — and shipped the fix in client version 1.104.4 on October 28 (the GitHub release record lists 1.104.4 as the latest release, dated 28 October 01:05 UTC). The bulletin descriptions below are as reported by The Hacker News and Atlasum from Tailscale’s bulletins; tailscale.com itself returned an access-denied error to direct reads during verification for this article, so the bulletin wording is attributed to those reports rather than quoted from Tailscale’s site.

  • TS-2026-014: Tailscale SSH Unix socket forwarding could grant peers access to root-only sockets. In version 1.104.4, Tailscale changed forwarding to run on behalf of the authenticated user rather than as root, relying on the operating system’s own file permissions instead of the earlier path check.
  • TS-2026-015: Memory exhaustion in Tailscale SSH session handling could lead to denial of service — a permitted SSH session could use up a server’s memory and crash the Tailscale process, cutting all Tailscale networking on that node.
  • TS-2026-016: tailscale serve Unix backends could reach privileged sockets, including the tailscaled local API socket — a forward to a Unix socket could reach the local API, giving remote control of the node, plus a related socket-swap issue.
  • TS-2026-017: HTTP/2 shared serve context could send the wrong Tailscale-App-Capabilities values across mounts — with TLS-enabled Serve and two or more mounts with different capability requirements, one request could receive another mount’s permission headers.

Tailscale called the privilege-escalation problems “serious security issues,” said it had reproduced the main ones, and added that it was still working out which configurations are affected. The four bulletins carry no CVE identifiers and no severity ratings, and none states the oldest affected version. Tailscale rejected the “wormable” description: the findings do not describe self-replicating malware spreading on its own, it said, but lateral movement limited to the connections a policy file already allows. The report’s proof-of-concept code is not public, and neither Tailscale nor the report says the flaws have been used in real attacks.

Two limits matter. First, the wider Tailworm report covered 11 findings, including app connectors and Serve/Funnel features beyond the four bulletins. Tailscale said the app-connector finding is in conn25, an experimental feature it has not released, and that the connectors customers use today are not affected; of five Serve and Funnel findings, it fixed three and said the other two work as designed. Second, the headscale picture was worse at report time: on headscale, SSH forwarding is granted on every accepted session and cannot be turned off in the policy, headscale 0.29.7, released October 30, fixes the server-side findings — unauthenticated memory exhaustion and eviction of pending device approvals. Headscale users fix the client-side flaws the same way everyone else does, by updating every node to 1.104.4, and switch forwarding off on the node itself with TS_SSH_DISABLE_FORWARDING=1 where they do not need it. The 0.29.7 notes do not describe a new headscale policy switch for SSH forwarding.

Tailscale’s interim advice, for nodes that cannot be updated yet, is specific and worth following exactly: review SSH access policies, disable SSH forwarding when it is not needed (TS_SSH_DISABLE_FORWARDING=1, set on the node), and apply the updated client release when it becomes available. It did not recommend disabling Tailscale SSH for everyone. SSH check mode, which adds a login step, is advised as a hardening measure — but check mode does not fix the reported privilege escalation, and this article does not present it as a fix. The same trust problem appears in other remote-management software: a backdoor in a WordPress management plugin’s update keys turned a trusted update channel into an access path, and the lesson there, as here, is that the tool that reaches every machine is the one whose permissions deserve the closest review.

What to change tonight

The mitigations below are ordered by impact. First, update: every node running Tailscale SSH or Serve should move to 1.104.4 or later, and no node should be assumed updated until its version is checked. The rest of this section is the plan for nodes you cannot update yet — and the hardening worth keeping even after you do.

If you rely on remote access over hotel or cafe Wi-Fi, the same ordering discipline applies to the network underneath: complete any captive-portal login before connecting, as in our public-Wi-Fi VPN fix ladder.

Disable SSH forwarding everywhere you do not actively need it. On Tailscale’s hosted service, TS_SSH_DISABLE_FORWARDING=1 does this. This single change removes the mechanism behind the most serious findings. If some users genuinely need forwarding, scope it to them and to specific destinations rather than leaving it on by default.

Second, replace broad access rules with single source-to-destination pairs. The reported spread mechanism follows whatever the access rules permit: a rule that allows “engineering to all servers” is a highway, while a rule that allows “this laptop to this server on this port” is a footpath. Windisch’s own report notes that single source-to-destination rules limited spread in the lab. This is the highest-leverage change for teams that cannot disable forwarding outright.

Third, review app-connector entitlements and remove any that are broader than the job requires. An entitlement that allows any outbound destination is the connector equivalent of a broad SSH rule, and the reported finding shows it reaching cloud metadata and Kubernetes services.

Fourth, turn on SSH check mode and node-key expiry. Check mode adds a login step that raises the bar for session abuse, and key expiry bounds how long a compromised device’s credentials remain useful. Neither fixes the reported flaws, and neither should be presented as doing so — but both shrink the window in which a flaw can be turned into an incident.

Fifth, for headscale self-hosters: upgrade the control server to 0.29.7, which fixes the registration and memory-exhaustion findings, set TS_SSH_DISABLE_FORWARDING=1 on nodes where forwarding is not needed, and keep the access-rule tightening above in place. Treat relay trust as a first-class concern.

Finally, the incident-response rule that surprises most people: if a device is compromised, delete it at the control plane. Reimaging the machine does not revoke its keys, so a wiped-and-rebuilt device can rejoin with the same identity the attacker already holds. Deletion at the control plane is what actually cuts the attacker’s access. The same two-half rotation lesson applies to any stolen credential: changing the stored copy is not enough until the issuer revokes the old one, as the Railway environment-variable incident showed.

What to watch next

Three things will change this story further, and each has a different consequence.

First, the update itself: mixed-version tailnets leave the old behavior alive on unpatched machines, so the priority now flips from waiting for a fix to getting every node updated — servers first, then every client that can open an SSH session to them. Check the version on each node; do not assume an auto-update ran.

Second, headscale: version 0.29.7 (October 30) fixes the server-side findings, so the watch item is now adoption — upgrade the control server and every node, and keep the access-rule tightening in place until both are done. The 0.29.7 notes do not describe a new policy switch for SSH forwarding; the node-side setting remains the way to turn it off.

Third, exploitation: no exploitation in the wild has been reported, the proof-of-concept code is not public, and none of the four bulletins is in CISA’s Known Exploited Vulnerabilities catalog. If that changes — a public exploit, a KEV listing, or a report of real-world use — the urgency changes with it, and this article will be updated. Independent reproduction, or a vendor refutation of specific findings, would likewise settle the “wormable” dispute and the severity debate.

Until then, the honest posture is the one this article has taken throughout: the findings were reported and plausible, Tailscale reproduced the main ones and shipped a fix in 1.104.4, the headscale server findings are fixed in 0.29.7, released October 30, and the mitigations are worth keeping because they cost little and they match what both sides recommend. Teams that run Tailscale SSH with forwarding enabled and broad access rules are the ones with something to change tonight. Teams that already scope forwarding tightly and write narrow rules have mostly done the work already — which is, in the end, the quiet moral of this disclosure: the access rules were always the security boundary, and Tailworm is what happens when they are written loosely.

Sources

Shoaib Hassan

Shoaib Hassan is the founder and editor of AuTechWire, an independent technology publication covering broadband, mobile networks, privacy, startups, and consumer tech.

Related Stories

Leave a Comment