Home Lab

Tailscale SSH: what the "Tailworm" report found, and what to do on your home lab

A researcher's report claimed serious flaws in Tailscale SSH. Tailscale says the issues are real but limited, and fixed in version 1.104.4. If you SSH into your Pi, NAS or Proxmox box over Tailscale, here is what to check.

By Andrew Ingleton · Published

Tailscale blog card for Tailscale SSH: Findings and fixes
Tailscale's own graphic for its findings post © Tailscale

Many home labs use Tailscale to reach a Raspberry Pi, a NAS or a Proxmox host from anywhere, and some let Tailscale handle SSH logins directly. On 28 October 2026 Tailscale published its response to a report, nicknamed Tailworm, that described weaknesses in that feature.

What Tailscale says happened

Concerns began circulating on social media on Friday 23 October. Tailscale received the report on the morning of Saturday 24 October, and the researcher published it about two hours later. Engineers worked through the weekend, and Tailscale posted an investigation update on Monday 26 October.

Tailscale describes the SSH problems as being mainly about how permissions were enforced after a connection was authorised, not about who is allowed to connect. Under certain conditions, an authenticated SSH session could do things beyond the privileges of its configured local user, including through SSH forwarding.

The report also covered Tailscale Serve and Funnel, with five findings. Tailscale says three were bugs, fixed in version 1.104.4, and two are behaviour it considers working as designed: bypassing the Funnel attribute check needs local admin access, and the setting TS_SERVE_ALLOW_ALL_INTERFACES is an opt-in way of exposing Serve beyond your tailnet. A further finding concerned Conn25, a next-generation app connector that is pre-production and unreleased; Tailscale says the stable app connectors are not affected.

How serious is it?

Tailscale gives no formal severity score in the post, but it sets out the conditions. An attacker would already need a foothold on an authorised device in your tailnet, with SSH access explicitly permitted in your policy file. Tailscale says this does not let an unauthenticated attacker connect to arbitrary Tailscale SSH servers, and that it is better described as limited lateral movement across connections your policy already allows than as a self-spreading worm. Those are Tailscale's own assessments; the four security bulletins it published, TS-2026-014 to TS-2026-017, hold the details.

What to do

  1. Update every machine that uses Tailscale SSH to version 1.104.4 or later.
  2. Review your policy file. Allow SSH only between the users and devices that genuinely need it; a home lab rarely needs "everyone to everything".
  3. Consider check mode for sensitive machines such as a hypervisor or backup server. It asks for an extra authentication step before access is granted.
  4. Read the bulletins if you run Serve, Funnel or anything exposed beyond your tailnet.

Tailscale asks anyone finding another issue to write to its security address.

The wider lesson

A mesh VPN shrinks your exposure to the internet, but it does not make the devices inside it trustworthy. Keep each machine's own SSH configuration sensible, and keep the policy tight. If you are new to Tailscale, our guide to running your own RSS reader with FreshRSS draws on a Tailscale post about reaching self-hosted services safely, and our notes on Ubuntu 26.10 for home servers cover another thing worth updating this month.

Source: Tailscale blog, 28 October 2026 (Tailscale SSH: Findings and fixes).

You might also like