Tailscale has disclosed a set of security findings affecting Tailscale SSH, plus the related Serve and Funnel features, and has already shipped fixes in version 1.104.4. If you run Tailscale on a homelab or self-hosted tailnet, here’s what happened, what it does (and doesn’t) mean for your setup, and what to do next.
What Tailscale disclosed
On October 28, 2026, Tailscale published a post on its blog titled "Tailscale SSH: Findings and fixes," written by Mike Shaver along with Mike Jensen, Jim Scott, and Sal Dazzo. The post walks through a security report covering Tailscale SSH, Serve, and Funnel, and lays out five distinct findings from that review.
Two of the five turned out to be "working as designed" once Tailscale investigated: the behavior looked odd but was intentional, not a bug. The other three were confirmed as real issues, and all three are fixed in Tailscale v1.104.4.
Tailscale is publishing four separate security bulletins for the confirmed findings, numbered TS-2026-014 through TS-2026-017. One thing you won’t find anywhere in the post is a CVE number. None of the findings has one attached, at least not yet.
What the bug actually is, and isn’t
This is the part worth reading slowly, because disclosures like this get overstated fast. The core issue Tailscale describes is that, under certain conditions, an already-authenticated SSH session could do things beyond the privileges of its configured local user, including through SSH forwarding. Put plainly: this is privilege escalation after authentication, not a way to get in without credentials in the first place.
That distinction changes how you should think about the risk. It’s not a remote, unauthenticated bypass, and it’s not some self-propagating worm crawling across your network on its own. Exploiting any of the three confirmed findings requires two things to already be true:
- An attacker already has a foothold on a device that’s an authorized peer in your tailnet.
- Tailscale SSH access is explicitly permitted for that peer in your tailnet’s ACL (policy) file.
So this is a lateral-movement risk, not an initial-access one. If someone has already compromised one of your machines, and your tailnet policy lets that machine SSH into others, the bug could let them do more than their configured user account should normally be able to do on the target. Still worth fixing, still worth understanding, but a fair bit narrower than "an outsider can walk into your tailnet from the open internet."
A separate, unrelated item: Conn25
The same post mentions an unrelated issue in something called "Conn25," described as a pre-production feature that hasn’t shipped anywhere. Tailscale is direct about this one: "the stable app connectors available today are not affected." If you’re using Tailscale’s current app connector features, none of this touches your setup. It’s in the post for transparency about the full scope of the review, not because it’s something you need to act on.
What to actually do about it
Tailscale’s own recommendations are short, and worth following even on a one-person tailnet:
Update to Tailscale v1.104.4 or later. This is the release with the fixes for all three confirmed findings. Check your version on every device, not just the ones you mentally file as "servers." A NAS running Tailscale is just as relevant here as a VPS.
Review your Tailscale SSH policies in the tailnet ACL file. Since exploitation depends on SSH being explicitly allowed between peers, this is a decent excuse to go look at who can SSH into what. If your ACL has grown generous over time for convenience’s sake, now’s a reasonable moment to trim it back toward least privilege.
Consider turning on SSH check mode for anything sensitive. Check mode forces a re-authentication step before a session is granted, which raises the bar even if a peer’s device has already been compromised. For a NAS, a backup server, or anything holding passwords, it’s a cheap way to add one more layer.
Why bother
Homelab setups lean on tools like Tailscale specifically to avoid exposing infrastructure directly to the internet. A mesh VPN built on WireGuard, which is what Tailscale is underneath, is a genuinely good piece of that approach. But cutting your attack surface isn’t the same as being immune to bugs, and this disclosure is a decent nudge that tailnet policy, meaning who can reach what and how, still matters once your services are off the public internet.
The short version: this was privilege escalation after authentication, bounded by your own ACL settings, not a remote exploit and not a worm. Update to v1.104.4, spend ten minutes on your SSH ACL rules, and think about check mode for your most sensitive hosts. For the full writeup, go straight to Tailscale’s own blog post, and if you want background on the tool itself, there’s our Tailscale app page.
Source: Mike Shaver et al., "Tailscale SSH: Findings and fixes," Tailscale Blog, October 28, 2026.