Tailscale SSH Unix Socket Forwarding Privilege Escalation: Tailworm Report and Mitigations

TL;DR

---

On October 25, 2026, Erica Windisch of Cyberdione Labs released “Tailworm”, a security report detailing vulnerabilities in the Tailscale client (tailscaled) v1.104.2 and headscale v0.29.5, based on testing conducted between October 22 and 24, 2026.

The report was published without prior vendor coordination. Windisch confirmed on Hacker News that while she notified Tailscale, disclosure was not coordinated (Hacker News). Without an immediate upstream patch or CVE, users must protect their environments through configuration changes.

Tailscale SSH Runs as Root

Tailscale operates as a mesh VPN over WireGuard. On each node, the daemon tailscaled runs with root privileges to configure network interfaces and routing.

Tailscale SSH allows Tailscale itself to terminate SSH connections on port 22, enabled per node with tailscale set --ssh (Tailscale SSH). Instead of handing connections off to a standard sshd, incoming sessions are handled directly by Tailscale’s embedded SSH server (gliderssh, a modified fork of gliderlabs/ssh). This means the SSH server runs inside the root tailscaled process.

Access control relies on tailnet ACLs rather than local passwords or public keys. Because WireGuard validates the source node identity at the network layer, incoming sessions matching an ACL rule log in without additional SSH credentials. The vulnerability centers on what permitted sessions can do once connected: tailscaled processes socket forwarding requests with root privileges.

Root-Privileged Unix Socket Forwarding (Findings 1–3)

SSH supports forwarding ports and Unix sockets locally (ssh -L) and remotely (ssh -R). Unix domain sockets provide local inter-process communication; sensitive sockets such as Docker’s /run/docker.sock and systemd’s /run/systemd/private are restricted to root. Accessing the Docker socket, for instance, allows running privileged containers that yield root access on the host.

OpenSSH drops privileges to the authenticated user before processing forwarding requests, restricting the session to sockets that the user can open. Tailscale SSH, by contrast, handles forwarding inside tailscaled as root.

The v1.104.2 source code restricts forwarded socket paths to the user’s home directory, /tmp, and /run/user/<uid> (tailssh.go). Findings 1–3 demonstrate three paths to root sockets despite these restrictions:

1. Connection Origin Treated as Root (Finding 1)
   When connecting to a socket via ssh -L, the destination process sees the connection coming from root. The report demonstrated launching a container through a Docker socket placed in /tmp, obtaining uid=0 execution and extracting /etc/shadow.
2. Replacing Existing Sockets (Finding 2)
   When creating a listening socket via ssh -R, tailscaled unlinks and overwrites existing sockets at the specified path, even if owned by root. An attacker can impersonate local services and intercept commands or credentials sent to that socket.
3. TOCTOU Symlink Race (Finding 3)
   A time-of-check to time-of-use (TOCTOU) race between path validation and file operations lets symlinks point outside permitted directories. This bypasses the three-path restriction and connects to sockets under /run.

Path traversal via symlinks was previously addressed in bulletin TS-2026-004 on June 3, 2026 (Security Bulletins). Early Tailscale SSH versions checked only path strings, allowing symlinks in a home directory to reach /var/run/docker.sock. v1.98.9 added destination checks, but Finding 3 targets the window immediately following verification.
While a path may appear safe under /tmp during validation, swapping symlink targets before file creation bypasses the check. By switching paths at ~170,000 operations per second, the report demonstrated container execution via /run/docker.sock (uid=0) and root shell acquisition via /run/systemd/private.

Environmental constraints were noted during testing. Under SELinux enforcing mode, host filesystem reads via Docker were blocked by policy, which limited the outcome to container execution. The systemd race condition succeeded in 0–4% of attempts.

Worm-Like Lateral Movement

This socket hijacking enables rapid lateral movement across the network.

In Finding 2, replacing the tailscaled management socket via ssh -R allows intercepting CLI communications. The report extracted node authorization keys (authkeys) from these requests. This lets an attacker register an external machine as a legitimate node on the tailnet.

flowchart TD
  A["Initial compromise of single node<br/>(Web vulnerability or poisoned package)"] --> B["Tailscale SSH to target server<br/>permitted by tailnet ACL"]
  B --> C["Forward Unix socket<br/>via ssh -L / -R"]
  C --> D["tailscaled opens / replaces<br/>socket with root privileges"]
  D --> E["Obtain root access<br/>via Docker or systemd"]
  D --> F["Intercept authkey from<br/>management socket"]
  F --> G["Register attacker machine<br/>into tailnet"]
  E --> B

Once one node is compromised, an attacker can pivot to any server permitted by tailnet access rules with root privileges. In the researcher’s lab environment, lateral movement required no stolen SSH keys or passwords and completed in under one second per machine.

Regarding Tailnet Lock, which requires existing node signatures for new registrations, the report noted that unlock telemetry was extractable from transit traffic. However, actually unlocking the tailnet was not tested.

Findings Across Serve and App Connectors

Beyond SSH socket forwarding, Findings 4–11 involve specific features and experimental configurations.

Windisch ranked overall user impact in order: Tailscale SSH privilege escalation first, App Connector destination control second, and tailscale serve authorization bypass third (Hacker News). The remaining 8 findings include:

Finding	Target	Description	Severity
4	App Connectors (conn25, experimental)	Users permitted to use an connector can route traffic to arbitrary destinations, including cloud metadata services and internal Kubernetes cluster services	High
5	Tailscale SSH	Rapidly sending terminal resize events and environment variables causes unbounded memory allocation in tailscaled, holding ~536MB in 7 seconds that remained allocated for over 100 seconds	High
6	headscale, DERP client	Sending 1024 unauthenticated registration requests evicts pending node records. Malicious DERP relays can force clients to allocate 1.34GB of memory from a 10MB response	Medium-High
7	tailscale serve	serve --tcp accepts configurations that expose tailscaled’s own management socket to other nodes	High
8	tailscale serve	Forwarded socket targets are validated only during configuration; swapping with a symlink later connects to root sockets	Medium
9	Funnel	Internet exposure permissions are verified only by client-side tooling	Medium
10	tailscale serve	Setting TS_SERVE_ALLOW_ALL_INTERFACES exposes serve targets to external LAN interfaces. Disabled by default	Configuration
11	tailscale serve	Concurrent HTTP/2 requests over a single TLS connection can mix authorization headers across distinct paths. In testing, 8 of 4000 requests returned HTTP 200 on unauthorized paths	Medium

Tailscale Response and Patch Status

Mike Shaver, Tailscale VP of Engineering, issued a statement on Reddit on October 25, 2026 (Recent Tailscale vulnerability reports).

According to the statement, Tailscale was investigating similar issues with external security researchers prior to the report. Shaver noted that the core issues involve Unix permissions and SSH forwarding handling, which can allow sessions to perform actions beyond local user privileges.
However, because this is distinct from unauthenticated remote code execution, Tailscale does not recommend a blanket disablement of Tailscale SSH. Formal bulletins and fixes are planned. Shaver also confirmed that standard OpenSSH connections over Tailscale are not affected.

As of October 26, 2026, Tailscale’s Security Bulletins page lists TS-2026-013 (involving eMudhra intermediate CA keys) as the latest bulletin, with no entry yet for Tailworm. GitHub releases remain at v1.104.2.

Upstream commits have begun landing on the main branch.
Commit 566f89e0f on October 25 addresses the HTTP/2 concurrent request header mix-up (Finding 11) by scoping authorization data per request rather than across shared connection state. Commit afe142bc8 on the same day fixes a gliderssh timeout race. Both reference internal issue tailscale/corp#50380.

The primary issue (processing Unix socket forwarding as root) remains unpatched on main as of October 26, 2026 (tailssh.go). The report recommends dropping privileges prior to forwarding, citing Dropbear’s fix in CVE-2025-14282 (version 2025.89).

headscale Policy Forwarding Limitations

Environments using headscale face additional constraints compared to official Tailscale coordination servers.
In headscale v0.29.5, an SSH rule with action: accept automatically enables both local and remote forwarding in client configurations (filter.go, lines 306–308). Because ACL syntax cannot selectively disable forwarding, granting SSH access in headscale effectively grants root access.

headscale v0.29.6 was released on October 24, but addresses only eMudhra certificates and Go dependencies, without Tailworm fixes (v0.29.6).
Additionally, headscale sends the full node list to all connected machines, exposing potential attack targets upon initial breach. Tailscale staff noted on Hacker News that the official control plane filters unpermitted nodes from node maps.

Interim Mitigations

Nodes not running Tailscale SSH are unaffected by Findings 1–3 and 5. Verify status by running tailscale debug prefs on each host and checking that RunSSH is false.

Restricting SSH destination accounts to non-root users does not resolve the issue, as Findings 1–3 execute from unprivileged sessions.

While Tailscale and the report recommend disabling socket forwarding via policy, forward-control syntax was not documented in public policy guides as of October 26, 2026 (Tailscale SSH). In headscale, selective forwarding control is not supported.

To block forwarding directly on client nodes, tailscaled v1.104.2 includes an environment variable TS_SSH_DISABLE_FORWARDING (tailssh.go).
Setting this to true causes tailscaled to reject both TCP and Unix socket forwarding regardless of coordination server policies. While undocumented, this setting operates independently of server-side support, and remains effective under headscale.

On systemd-managed Linux systems, apply the configuration using sudo systemctl edit tailscaled:

[Service]
Environment=TS_SSH_DISABLE_FORWARDING=true

Restart the service with sudo systemctl restart tailscaled.

When Tailscale SSH is unneeded, disable it using tailscale set --ssh=false. If Tailscale SSH is the sole remote management path to a machine, configure alternative access (such as standard sshd) before disabling.

For features beyond SSH:

• Run tailscale serve status to ensure no TCP forwarding targets unix: sockets (especially tailscaled.sock).
• Remove App Connector access from unneeded clients and enforce egress restrictions via Kubernetes NetworkPolicy.
• Avoid exposing headscale registration endpoints directly to the public internet and set MemoryMax in systemd.
• Enforce node key expiry even for tagged servers, as stolen state files can be reused from attacker machines until revoked in the coordination console.

While official bulletins and release tags remain pending, upstream commits show ongoing fixes for the surrounding issues. Users should follow official Tailscale channels for the upcoming security bulletin and privilege-separation patch.