Tailscale SSH Flaws Turn a Single Foothold Into Root Access on Target Servers
Tailworm reports high-severity Tailscale SSH issues on version 1.104.2 where Unix-socket forwarding can run as root inside tailscaled, including TOCTOU races on path checks. A policy-approved device may escalate on reachable hosts. Tailscale is reviewing the report and working on fixes. Interim steps center on tighter SSH policy and disabling forwarding.
Summary
The
Tailworm
assessment by Erica Windisch of Cyberdione Labs, published 25 October 2026, describes high-severity issues in Tailscale SSH on Tailscale 1.104.2. Unix-socket forwarding handled inside root-level tailscaled can allow a policy-approved session to reach privileged local sockets and escalate beyond the intended local user.
The path requires a foothold on one device that SSH policy already allows to connect to the target. It is not unauthenticated internet access to arbitrary machines. As of late October 2026, no CVE and no Tailscale bulletin for this set had been published. Tailscale stated that it received the report, is working on fixes, and is not recommending that everyone disable Tailscale SSH.
Vulnerability Details
Tailworm’s Tailscale SSH findings were reported against unmodified client version 1.104.2 (testing window 22–24 October 2026). Related SSH grant behavior was also examined on headscale 0.29.5. No CVE identifiers were assigned in the report or in Tailscale’s published bulletins at disclosure. This issue is tracked in our feed as SVE-110171.
The researcher rates the main SSH privilege findings High. Internal labels identify related scenarios under the same Tailscale SSH surface, not separate product versions. Proof-of-concept material was described as provided to Tailscale’s security contact and not published as a public exploit kit. Findings 1–3 listed in below section share one root cause and remediation path in the report.
Technical Information
Authentication model
Tailscale SSH authorizes by device identity on the WireGuard mesh. The SSH authentication phase completes with method none. A tailnet policy rule decides whether that device may open a session to a target. There is no separate password or key check at the SSH layer for that device identity. The attack path needs control of a device that policy already permits.
Why privilege matters
The SSH server runs inside tailscaled with full system privilege. Tailworm reports that Unix-socket forwarding path checks and file operations run in that privileged context, without a post-auth privilege drop of the kind used by designs such as OpenSSH before forwarding work. That shared design underpins Findings 1–3 below.
Finding 1 — Local Unix-socket forwarding (ssh -L)
Affected component is the Tailscale SSH server in tailscaled 1.104.2 (gliderssh streamlocal local forwarding).
Prerequisites: an SSH policy rule that accepts the attacker’s connection to the target, with local forwarding permitted. No sudo, docker-group membership, or victim-side daemon access is required on the target.
An authenticated peer with that rule can cause the root-privileged tailscaled process to connect, on the peer’s behalf, to Unix sockets restricted to root. In lab reproduction, local forwarding was used to reach a privileged service socket (for example a Docker socket under an allowlisted directory path). The verified result was root-equivalent impact on the target, including reading protected system credential files, with no sudo, docker group, or victim daemon involved. A static path allowlist of home, /tmp, and /run/user is bypassed when Finding 3 is available.
Finding 2 — Remote Unix-socket forwarding (ssh -R)
Affected component is the Tailscale SSH server in tailscaled 1.104.2 (gliderssh streamlocal remote forwarding, including BindUnlink behavior).
Prerequisites: as Finding 1, with remote forwarding permitted.
The root-privileged tailscaled can unlink a sticky-directory-protected, root-owned socket and bind the attacker’s forwarding listener at that path, impersonating the service. For command-channel daemons, the report describes this as direct root code execution in lab conditions. For Docker, the report describes cleartext registry-credential capture and control over pulls of unpinned tags, with host root requiring a further engagement step such as tag poisoning using captured credentials.
Finding 3 — TOCTOU on path allowlists
Affected component is path validation in the Tailscale SSH server in tailscaled 1.104.2 (validateAndResolve{Listen,Socket}Path in gliderssh).
Prerequisites: as Findings 1–2 (an SSH accept rule with forwarding permitted). The race runs unprivileged inside the attacker’s SSH session.
Path validation checks the lexical path at check time. Unlink, bind, and dial occur later, when the kernel re-resolves the path. A rename race in the session can win that check-to-use gap on both the bind and dial sides. On the bind side, the report describes the root agent unlinking a live root-owned control socket under the race. Lab chains built on this position included holding a rebind, capturing live enrollment material in transit, and joining a rogue node under the victim’s identity when Tailnet Lock was not enforcing stronger admission. With Tailnet Lock enabled, enrollment secrets could still be observed in transit, but the final join step was not completed. A related gliderssh sub-variant leaves a forensic signature around socket mode during Listen and Chmod, and can apply a root chmod to a live daemon socket, extending impact to permission-removal denial of service on arbitrary paths.
Enrollment capture and lab spread
Policy-granted Tailscale SSH plus Findings 1–3 allowed automated spread in the lab to every device the policy permits, with no passwords, no stolen host keys, and no user interaction, measured at under a second per hop. Two limits held: per-pair access grants bounded or stopped spread, and hardware-bound device credentials (TPM / Secure Enclave) hinder durable identity theft. The report describes measured lab behavior, not confirmed in-the-wild worming.
Finding 5 — Session handling and memory pressure
Affected component is the Tailscale SSH server in tailscaled 1.104.2, inherited from upstream gliderlabs/ssh v0.3.8.
Prerequisites: an authenticated SSH session allowed by policy.
A window-change blocking send parks a goroutine per session channel, and environment appends are unbounded. The report measured on the order of hundreds of megabytes allocated within seconds, with memory persisting after disconnect, producing a memory-exhaustion condition in the root-privileged daemon. Impact is availability of the agent and host under session abuse, not the same socket-to-root path as Findings 1–3.
headscale and check mode
On Tailscale’s hosted control plane, forwarding can be denied per SSH rule. On headscale 0.29.5, the report states forwarding is granted on every accepted SSH session and cannot be disabled, so every SSH grant should be treated as high risk until fixed.
SSH check mode (action: check) requires re-authentication before a session starts and grants access for a time window. Tailworm and Tailscale both state that check mode does not fix privilege escalation. It only adds a barrier before the session is established.
These findings apply to Tailscale SSH. Tailscale has distinguished them from ordinary SSH carried over a Tailscale connection. They are not unauthenticated remote code execution from the open internet to every node.
Impact
- Root-equivalent access on reachable Tailscale SSH targets via privileged socket operations
- Lateral movement limited by SSH policy breadth. Wide grants expand reach. Per-pair grants shrink it
- Enrollment material theft and possible rogue node join when Tailnet Lock is not enforced
- Host or agent availability loss from session-driven memory exhaustion
Affected Configurations
- Tailscale 1.104.2 with Tailscale SSH enabled
- SSH rules that allow the attacker-controlled device to reach the target, with Unix-socket forwarding available to the session
- headscale 0.29.5 where every SSH grant includes forwarding, per the report
Nodes without Tailscale SSH are outside this class. Tailscale stated it is still validating which configurations are affected. Earlier 2026 Tailscale bulletins, including the TS-2026-004 class fixed in 1.98.9, already addressed related socket-forwarding problems. Tailworm argues residual privilege-boundary issues remain in the tested 1.104.2 build.
Vendor Status
Mike Shaver, Tailscale VP of Engineering, wrote on r/Tailscale that Tailscale received the report, had already been reviewing related areas with external specialists, identified issues it is fixing, and is still validating scope. Issues identified so far are mainly post-authorization behavior around Unix privileges and SSH forwarding. In some cases a session may do more than the configured local user should be allowed to do. Tailscale is not recommending a fleet-wide disable of Tailscale SSH and plans a security advisory covering confirmed findings, affected configurations, recommended actions, and patches. As of late October 2026, no matching bulletin, CVE, or fixed client release for this set had been published.
Mitigation and Recommendations
- Tighten SSH policy. Limit access to devices and users that need it. Prefer per-pair source-to-destination grants. On sensitive systems, restrict further while investigation continues.
-
Disable SSH forwarding if unused. Deny forwarding in hosted SSH rules. On the agent, set
TS_SSH_DISABLE_FORWARDING=1in thetailscaledenvironment and restart the service so forwarding is off without disabling Tailscale SSH. On headscale 0.29.5, treat every SSH grant as high risk. -
Disable Tailscale SSH only where it is not needed (
tailscale set --ssh=false), after confirming another admin path. A blanket disable is not Tailscale’s current recommendation. - Optional check mode adds a pre-session auth step only. It does not remediate privilege escalation.
- Enable automatic updates, node-key expiry, and Tailnet Lock where appropriate.
- If compromise is suspected, delete the device at the control plane. Reimaging alone does not revoke copied keys.
- Apply Tailscale’s advisory and fixed builds when published, then re-check SSH policy.
Instantly Fix Risks with Saner Patch Management
Saner patch management is a continuous, automated, and integrated solution that helps you quickly remediate risks, including critical third-party application updates. It supports Windows, Linux, macOS, and 550+ third-party applications.
It also allows you to set up a safe testing area to test patches before deploying them in a primary production environment. Saner patch management additionally supports a patch rollback feature in case of patch failure or a system malfunction.
Experience the fastest and most accurate patching software here.
