Update Oct 25, afternoon: Tailscale has responded. Its VP of Engineering, Mike Shaver, wrote (as quoted by The Hacker News) that Tailscale received the report, had already been looking at the same areas with outside security specialists, has found issues it is working to fix, and is still working out which setups are affected. He said Tailscale is "not recommending that everyone disable Tailscale SSH." A Tailscale engineer added on Hacker News that the hosted control plane trims each device's network map, so two devices with no access rule between them don't see each other; some enumeration concerns in the report may apply mainly to headscale. Per the report, the step that enrolled an attacker's own machine as a trusted node only completed on tailnets without Tailnet Lock. Still no bulletin, CVE or fixed release, and no independent reproduction.

Erica Windisch of Cyberdione Labs published a security assessment of Tailscale v1.104.2 and the self-hosted headscale v0.29.5 control server, tested Oct 22-24 in a lab. The researcher chose to publish before a vendor fix, arguing that deployments are exposed now.

• Tailscale SSH (findings 1-3, High): the built-in SSH server runs as root, and unix-socket forwarding (ssh -L/-R) does its path checks and file operations as root, with races that defeat the path allowlist. An ordinary session can write to, replace or delete root-owned sockets, which the report says leads to root on the target.
• What an attacker needs: a foothold on one approved device plus an SSH policy rule that reaches the target. This is lateral movement inside a tailnet, not an internet-facing remote exploit. On headscale, forwarding is granted on every accepted SSH session and cannot be turned off; on Tailscale's hosted service it is set per rule.
• Other findings: the experimental app connector (conn25) forwards to destinations the client picks without checking network ACLs (cloud metadata, internal LANs, Kubernetes services); unauthenticated memory exhaustion in headscale; unbounded reads from a hostile DERP relay; and tailscale serve issues, including a TCP forward to the agent's own socket and a race that leaks capabilities across mounts.
• Spread: in the lab, policy-granted SSH plus findings 1-3 spread automatically to every device the policy allowed. Per-pair SSH grants were the one control that stopped it.

Vendor status: Tailscale has not published a bulletin or CVE. Its main branch received commits on Oct 24-25 that look related (serve app capabilities leaking across mounts, a gliderssh timeout race, several Tailscale SSH hardening changes), but no release has shipped and Tailscale has not tied them to the report. Until it does: list every SSH rule, rewrite broad tag- or group-wide rules as specific source-to-destination grants, turn off forwarding in SSH rules where you can, and remove the app-connector capability from clients that don't need it.