Disclosure: this post was drafted with AI assistance and reviewed by ShrineTech. The header image was generated with Krea 2. Defensive guidance only. It contains no exploit steps. Facts were checked against the Tailscale bulletins on 2026-10-31.

Tailscale published four security bulletins on 2026-10-26 (TS-2026-014 to TS-2026-017). All four are fixed in client version 1.104.4. Press coverage links them to a public researcher report nicknamed "Tailworm"; the bulletins themselves do not use that name, so we only mention it as context.

Most home-lab and small-business owners will think "it's only reachable by my own devices." That is the reason to act. Most of these issues need a device that is already authorised on the tailnet. So the useful question is: what happens if one of my own devices (a phone, a headset, an old Raspberry Pi) is compromised?

What was disclosed

• TS-2026-014: Tailscale SSH Unix-socket forwarding could let a peer reach root-only sockets (the bulletin names the Docker socket and the tailscaled local API) when Tailscale SSH is on and your policy allows forwarding. Vendor workaround: set TS_SSH_DISABLE_FORWARDING=1 for tailscaled, or update.
• TS-2026-015: memory exhaustion in Tailscale SSH sessions could crash the service. It needs an authenticated, policy-permitted session.
• TS-2026-016: tailscale serve Unix-socket backends could reach privileged sockets. The bulletin says the first weakness allowed full node takeover through the local API. It affects nodes where a local operator can write serve configuration or local users can write to a configured backend path.
• TS-2026-017: with Serve TLS and several mounts, HTTP/2 could send the wrong app-capabilities header across mounts.

What the bulletins say and do not say: each gives the fixed version and a "who was affected" description, but no affected version range and no severity score. The conditions in the bulletins (an authenticated peer, a policy that permits forwarding, local write access to serve config) mean most of these need access that is already inside your tailnet or on the machine. We saw no report of exploitation in the wild as of 2026-10-31, but we did not search exhaustively. Do not panic. Do update.

What to do now

1. Update every node. Run tailscale version on each device. You want 1.104.4 or newer.
   • Linux (apt): sudo apt update && sudo apt install --only-upgrade tailscale
   • Mac, Windows, iOS, Android: update through the app or store.
   • Small boxes such as Raspberry Pis can lag. On one of our machines the package repository only offered an intermediate version, so check again after updating.
2. Turn on auto-update: tailscale set --auto-update. Decide this deliberately on servers: some people prefer a scheduled patch window.
3. Find out whether you use Tailscale SSH. tailscale debug prefs | grep RunSSH shows it. If it is true and you log in that way every day, do not turn it off in a hurry. Disable forwarding instead (step 4).
4. Disable SSH forwarding if you don't use it. Add TS_SSH_DISABLE_FORWARDING=1 to /etc/default/tailscaled, then sudo systemctl restart tailscaled. This is the vendor's mitigation for TS-2026-014. Check your ~/.ssh/config for LocalForward/RemoteForward lines first.
5. Read your ACL. In the admin console, open Access controls.
   • The default policy lets every device reach every port on every other device. Limit phones, TVs and headsets to the ports they need.
   • In ssh rules, restrict src to the users or devices you actually log in from, and do not allow root as the target user unless you need it.
6. Harden the SSH server behind it. PasswordAuthentication no, PermitRootLogin no, keys only. Run sudo sshd -t before reloading, and keep a second session open.
7. Protect the account that owns the tailnet. Use a passkey or hardware-key MFA on your identity provider. That login is the real master key. Turn on device approval and sensible key expiry.
8. Consider Tailnet Lock if you have many devices or other people on the tailnet. It stops a stolen login from adding devices, but every new device then needs a signing node. For a handful of personal devices, do steps 1 to 7 first.
9. Don't expose services because "it's on the tailnet". List what listens on all interfaces with ss -tlnp, and bind internal services to localhost or the tailnet address.

Update, test, then tighten, in that order. Never remove your fallback way in until you have proven the new route works.

How to verify

• tailscale version on each node, and tailscale status for the device list. Remove any device you do not recognise.
• tailscale debug prefs | grep RunSSH matches what you intended.
• Forwarding: systemctl show tailscaled -p Environment should show the setting (or check /etc/default/tailscaled) after the restart.
• Admin console, Access controls, Tests: add allow and deny checks for the paths that matter, and run them before saving any policy change.
• From a device that should be blocked, try the port and confirm it fails.
• sudo sshd -T | grep -i -E 'passwordauthentication|permitrootlogin' shows no for both.

Quick answers

Which Tailscale version fixes the October 2026 security bulletins?

Client version 1.104.4 or newer fixes all four bulletins, TS-2026-014 to TS-2026-017. Run tailscale version on each device to check.

Is my tailnet safe because it is private?

Not automatically. Most of these issues need a device that is already authorised on the tailnet or local access to the machine, so one compromised device can matter. Update and limit what each device can reach.

How do I disable Tailscale SSH forwarding?

Tailscale's workaround for TS-2026-014 is to set TS_SSH_DISABLE_FORWARDING=1 for tailscaled (for example in /etc/default/tailscaled) and restart the service. Updating also fixes it.

Do I need Tailnet Lock for a home lab?

Usually not first. It stops a stolen login from adding devices but makes adding new devices harder. Update, tighten ACLs and protect the owning account first.

Related in this series: the Brotli CVE-2026-111497 patch guide; the Linux TCP and Chrome CVE guide; the egress-audit method.

Sources

• Tailscale security bulletins, TS-2026-014 to TS-2026-017 (published 2026-10-26, read directly on 2026-10-31): https://tailscale.com/security-bulletins
• Tailscale documentation on ACLs, Tailscale SSH and Tailnet Lock: https://tailscale.com/kb

---