Skip to content

Response, New York. Noah Park: Check Point Patches Actively Exploited Management Server Path Traversal. Detection, Dallas. Ava Okello: Report Finds Nearly Half of Deployed Detections Need Attention Before SOCs Can Trust Them.

SOCtember

Always First. Fast SOC News.

Tailscale title card for its Oct. 28, 2026, blog post "Tailscale SSH: Findings and fixes," white text on a dark navy background.
Image: Tailscale, "Tailscale SSH: Findings and fixes," Oct. 28, 2026 (fair use).

Response

Tailscale Ships 1.104.4 to Close Tailworm SSH Forwarding Flaws That Let a Permitted Session Reach Root-Only Sockets, and the Researcher Says Reimaging a Compromised Node Does Not Revoke Its Stolen Keys

Tailscale's four new bulletins say an attacker who already controls a device allowed to open Tailscale SSH sessions could use socket forwarding to reach the Docker socket or the tailscaled local API on the server. Updating closes the holes. For a node that may already be compromised, the Tailworm report says to delete it at the control plane and rotate keys, because a copied node identity survives a rebuild.

Noah Park, ResponseNew York6 min read

NEW YORK - Tailscale has released version 1.104.4 of its client with fixes for flaws in its built-in SSH server that let an already permitted SSH session reach sockets on the server that only root should be able to touch, the company said in a write-up published Wednesday. The fixes answer "Tailworm," a report that independent researcher Erica Windisch of Cyberdione Labs published on Saturday, Oct. 24, about two hours after Tailscale says it received it.

The company has published four security bulletins, TS-2026-014 through TS-2026-017, covering the confirmed findings, and recommends that anyone using Tailscale SSH update to 1.104.4 or later. The bulletins do not list CVE identifiers. Tailscale's write-up does not describe any exploitation outside the researcher's lab.

The precondition matters for triage. The flaws "don't allow an unauthenticated attacker to connect to arbitrary Tailscale SSH servers," Tailscale wrote. Exploitation requires a foothold on a device in the tailnet that the policy file already allows to open an SSH session to the target. What the bugs broke was what happened after that session was authorized.

What the bulletins cover

The most serious bulletin, TS-2026-014, concerns Unix socket forwarding. Tailscale SSH runs inside tailscaled, which holds root privileges, and the server checked requested socket paths as text but then carried out the operation as root. Tailscale says that produced three problems: privileged dials through local forwarding with ssh -L, replacement of root-owned sockets through remote forwarding with ssh -R, and a race condition that defeated the path allowlist because the kernel resolves the path again after the check. An attacker could reach root-only sockets such as the Docker socket or the tailscaled local API. The fix performs forwarding as the authenticated user instead of as root.

Tailscale security bulletin TS-2026-014, describing Unix socket forwarding in Tailscale SSH that could grant peers access to root-only sockets, the fix in version 1.104.4 and the TS_SSH_DISABLE_FORWARDING mitigation.
Screenshot: Tailscale security bulletins, TS-2026-014 (fair use).The bulletin lists the forwarding mitigation for servers that cannot update yet.

The other three are narrower. TS-2026-015 lets an authenticated SSH session drive memory use in tailscaled up through repeated window-change messages and environment variable appends until the process is killed, which disrupts every Tailscale connection on that node. TS-2026-016 covers tailscale serve: TCP forwards to Unix sockets lacked a guard and dialed as root, which Tailscale says allowed full node takeover through the local API, and a symlink check ran only when the configuration was reloaded rather than on each connection. TS-2026-017 is a race in HTTP/2 serve with TLS in which one mount's capability headers could bleed into requests for another.

For servers that cannot be updated right away, Tailscale says setting TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restarting the service turns off SSH forwarding without disabling Tailscale SSH.

A dispute over the word worm

Windisch tested Tailscale 1.104.2 and the self-hosted headscale control server 0.29.5 between Oct. 22 and Oct. 24 and described the chain as one that could carry an attacker from one compromised device to others in the tailnet. Tailscale rejected the worm label, saying the findings describe "lateral movement limited to connections allowed by a tailnet policy file," not self-replicating malware, and that an attacker could reach only machines the policy already permitted SSH connections to.

For defenders, that makes the policy file the blast radius. The report's first recommendation is to rewrite Tailscale SSH policy as grants between specific pairs of devices, never identity-wide or tag-wide accept rules and never privileged target accounts. The report says that on headscale, forwarding is granted on every accepted session, and advises treating every SSH grant there as equivalent to root.

Tailscale also suggests SSH check mode, which requires a fresh sign-in before a session starts, for sensitive systems. The Tailworm report cautions that check mode gates only the start of a session and does not stop the forwarding findings, which take place inside a session that has already been approved.

Of the report's five findings in Tailscale Serve and Funnel, Tailscale says three were bugs fixed in 1.104.4 and two describe behavior that works as designed. A finding in the app-connector feature known as Conn25 applies to software that has not been released, the company said, and the stable app connectors are not affected. The report's own mitigation matrix, updated Wednesday, still marks the Conn25 fix as partial, with an open pull request, number 22003.

What to hunt for, and how to contain

The Tailworm report includes sensors for hosts that are still unpatched. It recommends auditd rules on Unix socket unlink, bind and chmod operations in directories where forwarding is allowed, such as /tmp, home directories and /run/user, and on the agent's own socket paths. It suggests alerting when one network endpoint begins serving a second node identity, or when a machine key appears from a new network or autonomous system. The race depends on sustained directory rename loops, so the report recommends rate alerts on candidate directories, and it calls a socket with mode 0755 at a path that should be 0600 a forensic signature of a race-won bind. It also advises alerting on auth key issuance outside change windows and treating an unrequested Tailscale sign-in prompt reported by a user as an incident.

Tailworm report section "Detection while unpatched," listing socket-lifecycle auditing, cross-identity endpoint analytics, rename-storm detection, enrollment and key monitoring, and control-plane health checks.
Screenshot: Erica Windisch, Cyberdione Labs, Tailworm report (fair use).The report's detection list for nodes that have not yet been updated.

The containment advice is the part most likely to change a response playbook. A Tailscale node's identity is key material stored in its state file, and the report says an attacker with root on a host can copy that file off the machine and recreate the node's identity on other hardware, which the control plane will accept. Reimaging wipes only the compromised host's copy. In the report's words, "reimaging alone is not containment."

Tailworm report section "Containment on suspicion or incident," advising responders to delete the device at the control plane, rotate auth keys and credentials, rotate Tailnet Lock if a signing node was compromised and review policy history.
Screenshot: Erica Windisch, Cyberdione Labs, Tailworm report (fair use).The containment steps for a node that may have been compromised.

The report tells responders to assume exfiltration after any root compromise, delete the device at the control plane, which invalidates both its machine and node keys, and then rotate any auth keys and credentials reachable from the host. If a Tailnet Lock signing node was compromised, it says to rotate the lock, and it recommends reviewing policy history for unauthorized changes to routes, relay maps, approvers and key scopes.

Sources:


Noah Park covers incident response and blue-team operations for SOCtember from New York.

Related stories

Response desk