“In Windisch's own tests, forwarding to the Docker control socket produced a root shell and read the system password file, /etc/shadow, with no administrator rights.”
How the bug worked: privileged forwarding and a timing swap
The underlying flaw targeted how Tailscale’s SSH implementation handled socket forwarding. The Tailscale background process performs network forwarding with root privileges; when a permitted SSH session requested forwarding to a Unix socket on the server, the process performed a path check and then continued operating as root. A timing trick could let an attacker swap the socket path after the check but before use, defeating the path-based safeguard and letting the session reach sockets that only root should access.
What Tailscale changed in version 1.104.4
Tailscale released version 1.104.4 to address the issues. The company changed the server so forwarding is carried out as the logged-in user rather than as root, and it now relies on the operating system’s file permissions instead of the earlier path check. The release bundled four security bulletins: TS-2026-014 (SSH socket-forwarding flaws), TS-2026-015 (memory exhaustion leading to process crash and loss of Tailscale networking on a node), TS-2026-016 (a tailscale serve forward to a Unix socket that could reach the tailscaled local API plus a related socket-swap issue), and TS-2026-017 (TLS serve with two or more mounts where one request could receive another mount’s permission headers).
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleThe Tailworm report and disclosure timeline
The findings came in a report called Tailworm, published by Erica Windisch of Cyberdione Labs just days before the fix. Windisch tested released versions of the Tailscale client and the self-hosted headscale control server in a lab. Tailscale said it received the report on the morning of Saturday, October 24, about two hours before Windisch published it, and that its engineers were already examining the same parts of the code. Windisch described her disclosure as “reported but not coordinated.”
Headscale, device keys, and persistence risks
The report flagged worse conditions on headscale, the self-hosted control server: SSH forwarding is granted on every accepted session and cannot be turned off in the policy, so Windisch’s report says “every SSH grant there should be treated as giving root.” The newest headscale release cited in the report, version 0.29.5 from October 13, does not fix the reported issues. Windisch’s report also notes that a stolen device key remains valid until the device is deleted at the control plane; reimaging a machine does not revoke its existing device key, a reality the report says the fix alone does not mitigate. Tailscale’s public notices do not cover that stolen-key scenario.
Immediate actions: update, disable forwarding, review rules
Tailscale’s guidance is straightforward: update Tailscale SSH to version 1.104.4 or later. If updating a server is not immediately possible, operators can disable SSH forwarding on the server by setting TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restarting the service; Tailscale says this turns off forwarding without disabling Tailscale SSH and blocks several of the more serious findings. The company also recommends reviewing SSH access rules so only required users and devices retain access, and suggests using SSH check mode on sensitive systems, observing that check mode “does not stop these forwarding flaws” because it guards session start while the forwarding occurs inside an already-approved session.
Where this leaves different operators and defenders
- Technologists and security teams: Patch to 1.104.4 promptly, consider disabling forwarding where patching is delayed, and audit SSH access rules to reduce the set of devices and users that can open forwarded sessions.
- Headscale operators and self-hosted admins: Treat every SSH grant as potentially granting root under the conditions described, since headscale’s policy model in the tested release grants forwarding on every accepted session and cannot disable it in policy.
- Incident responders and recovery teams: If a server may already be compromised, Windisch’s report warns that applying the patch alone is insufficient because device keys remain valid until removed at the control plane; the report says reimaging does not revoke keys.
Tailscale characterized the findings as “serious security issues,” said it reproduced the main ones, and noted it is still determining which configurations are affected. Windisch described the chain as “wormable” in lab tests — one compromised device could spread to every device the policy allowed in under a second per step — a characterization Tailscale rejected as describing self-replicating malware, calling the behavior lateral movement limited to policy-allowed connections. Neither Tailscale nor the report says the flaws have been used in the wild; proof-of-concept code is not public and, according to Windisch, was given only to Tailscale’s security team.
The record also notes prior work in this area: in June, Tailscale fixed a separate Unix-socket forwarding flaw in Tailscale SSH in version 1.98.9.
Link to original story: https://thehackernews.com/2026/10/tailscale-patches-ssh-flaws-that-could.html
