On October 25, a researcher named Windisch posted a disclosure on Hacker News covering 11 findings in Tailscale and Headscale. One of them let a compromised device on a tailnet reach root on another server through Tailscale SSH. The Hacker News reported that Tailscale had no bulletin, no CVE and no fixed version when the story ran.
On October 26, Tailscale published four security bulletins, TS-2026-014 through TS-2026-017. Each one says it is fixed in Tailscale 1.104.4 or newer.
What the SSH bug was
The lead entry on Tailscale’s security bulletins page is TS-2026-014: “Tailscale SSH Unix socket forwarding could grant peers access to root-only sockets.”
The Hacker News describes the lab setup. A standard SSH port-forwarding session made the root-level Tailscale process connect to a root-only system socket on the target. The report says “the test gained root and read the system password file almost immediately.” Windisch tested Tailscale 1.104.2 and Headscale 0.29.5.
The same story notes that Tailscale had already fixed an earlier flaw of this kind in version 1.98.9, one where SSH Unix socket forwarding could reach a privileged socket. So this is a second pass at a known weak spot.
The other three bulletins
- TS-2026-015: memory exhaustion in Tailscale SSH session handling could lead to denial of service.
- TS-2026-016:
tailscale serveUnix backends could reach privileged sockets, including thetailscaledlocal API socket. - TS-2026-017: HTTP/2 shared serve context could send the wrong
Tailscale-App-Capabilitiesvalues across mounts.
For TS-2026-014 there’s also a mitigation if you can’t update right away. The bulletin says you can disable SSH forwarding by setting TS_SSH_DISABLE_FORWARDING=1.
How worried to be
Less than for an internet-facing bug, and it’s worth saying why. The attacker has to already be a device on your tailnet that your access policy lets SSH in. Nobody gets to this from a random scan of the open internet.
The disclosure itself was messy. Windisch called it “reported but not coordinated.” She told The Hacker News she’d sent Tailscale the report and proof-of-concept code the Saturday before the public post. Tailscale’s VP of engineering, Mike Shaver, said on Reddit that the company was still working out which setups were affected. He also said Tailscale was “not recommending that everyone disable Tailscale SSH.”
That’s a reasonable position, and the bulletins back it up. The fix is a point release, not a rip-and-replace.
One limit on what we can tell you: the bulletins don’t map to the 11 findings one to one. We don’t know which of the 11 each bulletin covers, so we’re not going to guess.
What we’d do
Update tailscaled to 1.104.4 or newer on every machine that runs it. Don’t forget the boring ones: the NAS, the mini PC in the closet, the VM you set up two years ago and haven’t logged into since.
Then read your SSH rules. Most people use Tailscale SSH to get a shell and never need socket forwarding. If that’s you, set TS_SSH_DISABLE_FORWARDING=1 and leave it off. A feature you don’t use is only attack surface, and this is the second time socket forwarding has been the weak point.
Here’s our position. We run the Plex and Arr stack here, and we’d rather reach it over a tailnet than forward a single port to the internet. That hasn’t changed. A mesh VPN is still a much smaller target than an open port 22. But the whole bet is that the inside of the tailnet is trusted, and a bug like this is what happens when one compromised laptop gets to act as root on a server. Treat every node as something that might get popped, and give the people and devices on it the least access that still lets them work.
We also think the right way to judge Tailscale here is the patch, not the disclosure drama. Four bulletins, one fixed version, one environment variable for people who can’t update yet. That’s easy to act on. It only helps if somebody does.