Tailscale shipped v1.104.4 on 28 October 2026 to close privilege-escalation flaws in its built-in SSH server, in Tailscale Serve and in the self-hosted headscale control server. The details came from a public report called Tailworm, produced by Cyberdione Labs against released builds of the client and headscale.

What happened

Tailscale SSH runs its SSH server inside tailscaled, which runs with root privileges. Tailscale states the defects were in how permissions were enforced after a session had been authorised, not in the access rules that decide who may connect. Unix socket forwarding checked paths lexically but performed the underlying file operations as root, so an already-authorised session could reach sockets only root should touch, including the Docker socket and the tailscaled local API. A race condition defeated the path allowlist entirely.

Four bulletins cover the confirmed findings. TS-2026-014 covers Unix socket forwarding and root-only socket access. TS-2026-015 covers memory exhaustion in SSH session handling that can crash tailscaled. TS-2026-016 covers a tailscale serve TCP forward that could reach the local API. TS-2026-017 covers permission headers from one mount being sent with requests for another. All four are fixed in v1.104.4.

Who is affected

• Nodes running Tailscale SSH where the tailnet policy file permits local or remote forwarding, especially where Docker or the tailscaled API socket sit on the same host.
• Self-hosted headscale control servers reachable from the internet, which faced unauthenticated resource exhaustion that could block onboarding for the whole tailnet.
• Anyone running tailscale serve with TCP forwards to Unix socket backends.
• Not affected: tailnets that never enable Tailscale SSH or forwarding, and the stable app connectors.

What to do now

Upgrade every client, server and headscale instance to Tailscale v1.104.4 or later before the weekend. The fix changes how forwarding runs, so an out-of-date node on either end still carries the old behaviour.

• Update Linux servers, Windows and macOS endpoints, containers and appliances to v1.104.4.
• If you do not use SSH forwarding, set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart the service.
• Review the tailnet policy file so SSH access is limited to the users and devices that genuinely need it.
• Treat any host that runs Tailscale SSH with forwarding enabled as potentially reachable and check for unexpected local users, cron entries and new SSH keys.
• Turn on SSH check mode for the servers that matter most, and ask who could reach the Docker socket before this patch.

What this means for South African businesses

Tailscale has become the quiet default for remote access in a lot of South African SME and MSP estates because it needs no public VPN endpoint. That convenience is exactly what makes this class of bug worth taking seriously: the attacker does not need to break in from the internet, only to hold one device already on the tailnet, such as a stolen laptop or a compromised developer machine.

In practice most small environments will never grant SSH forwarding, which caps the blast radius. The ones that will are the technical shops with Docker hosts and jump boxes, and those are also the environments where a single root shell is expensive.

Source: Tailscale SSH: Findings and fixes.

Also on the blog

• DreamHost forced email and FTP password resets after 23 October incident
• Telegram for Android Call RCE: Fixed in 12.10.4, No CVE Assigned

Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.