Tailscale SSH vulnerability: who has to update to 1.104.4, and the switch that limits the risk

The Tailscale SSH vulnerability fixes shipped in Tailscale v1.104.4 on October 28, 2026. Update every node that runs the Tailscale SSH server, or uses Tailscale Serve with Unix socket backends or TLS, to 1.104.4 or newer. If you can't update today, setting TS_SSH_DISABLE_FORWARDING=1 and restarting tailscaled mitigates the more serious SSH findings.

We read Tailscale's bulletins, changelog and docs on October 29, 2026. Security pages change, so check the live security bulletins before you act. This is a summary of the vendor's own statements, not security advice for your network.

What the Tailscale SSH vulnerability bulletins cover

Tailscale lists four bulletins dated October 26, 2026, TS-2026-014 to TS-2026-017, on its security bulletins page. The October 28 changelog entry for v1.104.4 lists all four fixes and notes that v1.104.3 was an internal-only release. Each bulletin says the flaw is fixed in 1.104.4 or newer.

The impact statements are blunt. For TS-2026-014 the bulletin says an attacker "could reach root-only sockets such as the Docker socket or the tailscaled local API." For TS-2026-016 it says the first issue "allowed full node takeover by providing remote access to the local API."

The bulletin pages we read name only the fixed version. They give no earliest affected version, so in our view any older node that matches the right-hand column should count as exposed.

Which of your machines need the update

Sort your nodes with three questions.

• Does the node run the Tailscale SSH server? That covers TS-2026-014 and TS-2026-015. A host opts in with tailscale set --ssh. Tailscale's SSH docs, last validated January 5, 2026, say the server component is available only on Linux and on the open-source tailscale plus tailscaled variant of macOS, while you can connect from any platform. A Windows laptop that only connects out is not an SSH server by that description.
• Does your policy allow SSH forwarding? TS-2026-014 is limited to setups that allow it. Check the ssh rules in your access policy and ask who actually uses ssh -L or ssh -R to reach a host.
• Do you use tailscale serve? TS-2026-016 and TS-2026-017 concern Serve, not SSH. Unix socket backends and TLS with several mounts are the triggers the bulletins name.

If none of those apply, none of the four "who was affected" lines matches your nodes. We would still move to 1.104.4, because Tailscale's update docs recommend always running the latest client, and a separate October 21 bulletin (TS-2026-013, leaked eMudhra certificate keys) needed 1.104.2 or later, which 1.104.4 also satisfies.

How to check and update to 1.104.4

1. Open the Machines page of the admin console and read the Version column. Tailscale's update docs say a red arrow marks a device with a security update available, and the Version filter can show only devices with an update available.
2. On a host, run tailscale version. The CLI reference says the --daemon flag also prints the local node's daemon version.
3. Update. If auto-updates are on, the client uses the same mechanism as its install, such as your Linux package manager. Otherwise the CLI reference documents tailscale update, with --dry-run to preview and --yes to skip prompts.
4. Schedule the restart. The SSH docs list as a limitation that restarting tailscaled, for example during an upgrade, stops any existing Tailscale SSH session. Keep a second way into the host.
5. Check containers separately. Tailscale's docs recommend the stable tag so each container deploy or restart runs the latest stable client, and warn that a container pinned to a version such as v1.76.0 reverts to that version on redeploy. The October 28 changelog entry we read lists the client and a Terraform provider release but no container image, so check your registry before you assume a 1.104.4 image exists.

The update docs also warn that tailnets created before February 2024 must switch auto-updates on by hand, in the Device management page and on each existing device. Existing devices are not changed by the tailnet-wide toggle.

If you can't update yet, switch off SSH forwarding

For TS-2026-014 Tailscale gives one interim step. The bulletin says: "you can disable SSH forwarding by setting TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restarting the service. This disables forwarding without disabling all of Tailscale SSH." Tailscale's investigation update says the same switch "mitigates several of the more serious findings."

The pages we read don't give per-platform steps for this variable. On Linux, Tailscale's tailscaled docs say the systemd unit includes /etc/default/tailscaled, and its Linux install page shows an environment variable added to that file. In our reading that file is the natural place for this setting on package installs, but confirm on one test host before you roll it out.

The cost is real. Anything that relies on forwarding through Tailscale SSH, such as ssh -L or ssh -R tunnels to a database, stops working while the variable is set. That is our inference from the word "forwarding," so test your own tunnels. Remove the variable after you update.

Tighten the SSH policy while you are in there

The SSH docs describe a default rule that lets each user reach their own devices in check mode, as root or non-root. They also carry a warning: if you change the destination from autogroup:self to another target, such as a tag, also consider replacing autogroup:nonroot in the users field. Otherwise anyone permitted by the source setting can SSH in as any non-root user on that destination.

Two more lines from the same page are worth reading against your setup. Check mode with a checkPeriod of always prompts for approval on every new connection, though the docs warn it can disrupt automation such as Ansible. And Tailscale SSH "may not be a good fit" for multi-user machines, or for machines with outbound access where you don't trust the code running on them.

Check mode is not a patch. The Hacker News reported that it "does not fix the privilege escalation" and only adds a barrier in front of it. The same article says the researcher's lab spread was stopped by access rules written as single source-to-destination pairs. That is one researcher's lab result, but in our view narrowing broad tag-to-tag SSH rules costs little, and the docs say you can write SSH tests to assert your rules behave as intended.

What the Tailworm report claims, and what Tailscale has confirmed

Part of the story began outside Tailscale. Researcher Erica Windisch of Cyberdione Labs published a report called Tailworm on October 25, 2026, which The Hacker News covered. It reports 11 findings, tested in a lab on Tailscale 1.104.2 and headscale 0.29.5, and calls the SSH result "wormable." The article says some researchers dispute that word, that the proof-of-concept is not public, and that no other researcher has publicly reproduced the findings.

Tailscale's own position, on its investigation page updated October 27, is narrower. It says most identified SSH issues concern privilege escalation: someone already authorized to connect over Tailscale SSH "may be able to perform actions beyond the permissions of their configured local user." It calls them "serious security issues," and says it is "not recommending that everyone disable Tailscale SSH." According to The Hacker News, the company has not confirmed each claim in the report. The four bulletins above are what it has published on the SSH and Serve issues.

If you run headscale, the bulletins describe fixes in the Tailscale client, and The Hacker News says the daemon-level switch works regardless of control plane. We did not check headscale's own release notes, so read them before you decide.

Where this leaves your remote-access stack

In our view the practical order is short: find which nodes run the SSH server, update them to 1.104.4, then trim forwarding and broad rules. Rotating credentials is a separate decision that depends on whether you suspect compromise; our post on rotating secrets after a hosting breach covers that routine.

Upfynd lists Tailscale in its directory, and as of October 29, 2026 it lists 952 products under Developer Tooling, 361 under Open Source and 257 under Security if you are weighing other remote-access options. A listing is not an endorsement, and none of these tools has been tested by us. Start with the Version column on your Machines page.