Tailscale Investigates SSH Flaws That Could Let Authorized Users Gain Elevated Privileges

Tailscale said on October 26, 2026 that its engineering and security teams are investigating reported issues with Tailscale SSH, working with external security specialists. In its investigation and remediation update, the company said most of the issues it has identified concern privilege escalation, meaning a way for a user to obtain more access on a machine than they were granted.

According to Tailscale, a user who is already authorized to connect over Tailscale SSH may, in some circumstances, perform actions beyond the permissions of their configured local user, potentially gaining elevated privileges. Exploitation depends on the permissions granted to the connecting user or device, the configuration of the system, and other conditions.

BleepingComputer reported on October 27 that Tailscale's security team is working to patch almost a dozen security vulnerabilities. The outlet described the Tailscale SSH flaws as allowing root privilege escalation, meaning control of the most powerful account on a system, and reported that the vulnerabilities could be exploited to steal credentials.

Tailscale said its engineers have implemented fixes for most of the identified issues and are completing testing before a patched client release. The company is targeting that release by the end of Tuesday, October 27, subject to successful completion of testing. The release is a target, not a shipped build.

On mitigation, Tailscale said that based on its current assessment it is not recommending that all users disable Tailscale SSH. It recommended two steps instead. The first is reviewing Tailscale SSH access policies so that access is limited to the users and devices that need it. The second is setting the environment variable TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restarting the service. That setting disables SSH forwarding, which relays a connection through one machine to another, without disabling Tailscale SSH entirely. Tailscale said disabling forwarding mitigates several of the more serious findings.

Tailscale also outlined its disclosure sequence. Once fixes are available, it will publish a security advisory covering confirmed vulnerabilities, affected versions and configurations, impact, and remediation. A technical blog post explaining the findings, their underlying causes, and the engineering changes made will follow the advisory.

An earlier item in Tailscale's security bulletins, TS-2026-012, was issued on October 13, 2026. It describes a bug in libtailscale's use of the SCM_RIGHTS API, a Unix mechanism for passing open file descriptors, the handles a program uses to reach files and sockets, between processes. Tailscale's security bulletins advise updating to Tailscale v1.104.2 or later.

In my view, the practical question for operators is less whether to switch Tailscale SSH off than how broadly it has been granted. Tailscale's own description makes the exposure conditional on who is authorized and how the host is configured, so an access policy that reaches more users and devices than necessary widens the set of accounts that could exercise these behaviors. The forwarding flag is a narrower control. Teams that depend on SSH forwarding will need to weigh that dependency against the mitigation it provides until a patched client is available and installed.

The broader context here is that teams running overlay networks now manage SSH access through identity and policy rather than only through host-level keys. That model reduces the friction of reaching a machine and concentrates authorization decisions in one place. When that layer has a defect, the blast radius is set by how carefully the policies were written. Tailscale's guidance points operators toward that review as the first task.