Tailscale releases 1.104.4 to fix remote-access security flaws

Tailscale has released version 1.104.4 with fixes across four security bulletins, including flaws that could let a permitted remote session reach resources reserved for root, the system’s administrator account. The update changes connection forwarding so it runs with the logged-in user’s permissions rather than root’s.

The release follows Tailworm, a report published on October 24 by Erica Windisch of Cyberdione Labs. Tailscale says the confirmed SSH flaws concern permissions after a connection is approved: an attacker must already control an authorised device, have permission to connect to the target and, for the forwarding flaws, have forwarding allowed.

SSH provides remote command-line access. Tailscale’s built-in SSH server uses device identities and network policy instead of a separate SSH password or key. A compromised trusted device therefore supplies the starting access, but the attacker can reach only machines the policy already permits. The SSH server runs on Linux and the open-source macOS build; the attacker’s device can use any platform.

How forwarding crossed the permission boundary

Forwarding carries connections through an SSH session. The vulnerable implementation checked the path to a Unix socket—a local endpoint through which programs communicate—but then made the connection as root. An attacker could replace the path between the check and its use, bypassing the intended restriction.

Version 1.104.4 replaces that path check with the operating system’s file-permission checks and performs forwarding as the logged-in user. The Hacker News detailed the change and the four bulletins covering the confirmed issues.

As of October 28, the bulletins did not state the oldest affected versions or carry CVE vulnerability identifiers or severity scores. Tailscale said it was still determining which configurations were affected.

Update, or temporarily disable forwarding

Tailscale recommends that SSH users install version 1.104.4 or later. For a server that cannot yet be updated, the company says administrators can set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart the service. This disables forwarding without disabling Tailscale SSH and blocks several of the more serious findings.

Disabling SSH forwarding is a temporary measure for the forwarding flaws, not a substitute for the fixes to SSH memory exhaustion or the separate Serve issues. Those issues are addressed by the update.

The company also recommends limiting SSH rules to the users and devices that need access. For sensitive systems, it suggests check mode, which requires users to authenticate again before a session starts. That check controls entry; it does not stop forwarding abuse inside an approved session.

What Windisch demonstrated, and what remains on headscale

Windisch said her laboratory tests of released Tailscale clients and the self-hosted headscale control server produced a root command shell and access to /etc/shadow, the system password file, by forwarding to Docker’s control socket without administrator rights. Tailscale’s bulletin describes the confirmed impact more narrowly as access to root-only sockets.

Windisch called the chain “wormable,” saying her tests moved from one compromised device to policy-permitted devices without passwords, stolen keys or user action, in under a second per step. Tailscale disputes that description: it says the findings show movement between machines allowed by policy, rather than malware automatically copying itself between machines. Neither Tailscale nor Windisch has reported exploitation in real attacks.

A separate policy limitation affects headscale. Windisch says it grants forwarding on every accepted SSH session and offers no policy setting to turn forwarding off; she therefore recommends treating each SSH grant on an unpatched deployment as granting root access. The Hacker News said headscale’s latest release, version 0.29.5 dated October 13, did not fix the reported issues. That headscale status is separate from the fixes now available in Tailscale software.

For a machine that may already have been compromised, Windisch says updating or reimaging alone does not invalidate a stolen device key. She recommends deleting the device from the control plane—the system managing network membership—to revoke that identity. In her tests, device-to-device access rules limited spread, while hardware-bound device keys prevented a stolen identity from being reused elsewhere.

From investigation to released fixes

Tailscale says it began investigating on October 23 after concerns circulated publicly. It received Windisch’s report on the morning of October 24, two hours before she published it, while engineers were already examining related issues. The company published initial precautions on October 26 and announced the available fixes on October 28.

The broader report also covered other Tailscale features. The company says three of five Serve and Funnel findings were bugs now fixed. It classifies the other two as intended behaviour: bypassing a Funnel access check requires local administrator access, and the TS_SERVE_ALLOW_ALL_INTERFACES setting deliberately exposes Serve beyond the Tailscale network.

Tailscale says the app-connector finding concerns Conn25, an unreleased replacement for its existing app connectors. The company already knew about that issue and says stable connectors are unaffected. For administrators using the affected released features, version 1.104.4 is the available remediation, alongside the company’s recommendation to review SSH access rules.