On the Tailscale SSH vulnerabilities: defaults are fine, but that root process deserves another look
Erica Windisch published 11 security findings for Tailscale, and the community panicked while also debunking. The default configuration indeed does not trigger any of them, but the report contains a design issue that was drowned out by the debunking: the SSH server runs in a root process, taking a different path from OpenSSH's privilege separation.
The developer timeline was restless this weekend. Erica Windisch posted a security assessment at tailworm.com, covering Tailscale v1.104.2 and headscale v0.29.5, with a testing window from October 22 to 24; all reproductions were done on unmodified release versions. There are 11 findings in total, with no coordinated disclosure, published publicly immediately.
The most serious group is in Tailscale SSH. tailscaled runs with root privileges, and its SSH server is in that same process. For Unix socket forwarding via ssh -L and ssh -R, there is a time gap between path validation and use: validation passes at check time, while unlink, bind, and dial happen afterward, leaving a window that can be bypassed with a rename race. The report measured this: an ordinary SSH session can obtain uid=0 on the target machine, including targets such as /run/docker.sock and /run/systemd/private.
How the story spread differed in tone from the report's own wording. On one side was 'Tailscale SSH vulnerability can let attackers obtain root'; on the other was Jamieson O'Reilly's debunking: in a default installation, all of these features are off. He was right. Tailscale SSH is opt-in, the app connector needs configuration, serve must be explicitly enabled, and headscale must be deployed yourself. None of the 11 findings can touch a default tailscale up. O'Reilly also wrote a read-only check script, tailslop, which compares each finding in the report one by one to see whether it is triggered on your machine.
But 'defaults are fine' and 'there is no problem' are two different things. There is a design-level observation in the report that was drowned out by the debunking: Tailscale SSH does not do user-level authentication; WireGuard authenticates devices, not people; and the authorization stage passes directly via method none. The permissions of the entire SSH session depend on how that root process handles forwarding requests.
Compare with OpenSSH: after authentication, the child process setuids to the session user, and subsequent streamlocal bind, unlink, and dial operations all run as the user. Upstream's October commit b37c095a goes further: when sshd runs as root, it directly disables streamlocal and reverse forwarding to privileged ports. Dropbear had a similar CVE-2025-14282, fixed by doing setuid earlier at USERAUTH_SUCCESS. Tailscale's approach embeds the SSH server in a highly privileged long-running process; no matter how carefully paths are checked, because it runs in a root context, the cost of a race window is much greater than for a user process.
One more layer that is easy to miss: check mode governs session establishment, but does not cover -L and -R forwarding within the session. Once you click approve in the browser, all forwarding during the window follows that session. The report states this, but most of the debunking posts do not mention it.
If you want to take action, the most direct is tailscale set --ssh=false, then use regular sshd over the tailnet. RusticStack warned: before turning it off, confirm sshd is running, otherwise you will lock yourself out. The per-pair SSH grant is the only control in the report that stopped automated spread in the lab. If a serve config has a --tcp entry pointing to a Unix socket, take a look at that too.
Tailscale VP of Engineering Mike Shaver responded on Reddit, saying they are reviewing the report, have already independently found some issues and are fixing them, and currently do not recommend that everyone disable Tailscale SSH. He said that some issues occur after authorization, involving Unix permissions and how SSH forwarding is handled, and are not the same as 'an unauthenticated attacker directly connecting to any machine.' This matches the report's premise of 'one device has already been compromised.'
Windisch wrote a judgment in the researcher's note: the design choice is moving away from defense in depth, replacing a daemon that performs privilege separation with a highly privileged process. It is not pleasant to hear, but the problem it points to is not in the 11 specific items; it is in the architectural choice. Panic is unnecessary, but before closing the report, it is worth considering whether this choice is one you are willing to accept.
发布时间: 2026-10-26 06:38