A newly published research report is raising uncomfortable questions about how much trust Tailscale’s SSH feature places in devices that are supposed to be fully locked down. The report, named Tailworm, was released on October 25, 2026, by independent researcher Erica Windisch of Cyberdione Labs. It documents eleven distinct findings across Tailscale SSH, the “serve” and app-connector features, the DERP relay client, and headscale, the open-source server many organizations use to self-host their own Tailscale-style coordination layer.

Tailscale builds a private mesh network out of devices that have been authorized to talk to one another, and its SSH feature is meant to let those approved machines log into each other without juggling separate SSH keys. Windisch’s testing, carried out between October 22 and October 24, 2026 against tailscale 1.104.2 and headscale 0.29.5, suggests that trust model has more soft spots than administrators might assume. As of the report’s publication, Tailscale had not confirmed the findings, issued a security bulletin, or assigned any CVE identifiers.

From a Routine SSH Session to Root

The most severe issues center on port forwarding, a feature most admins treat as a convenience rather than a privilege boundary. According to the report, local socket forwarding (ssh -L) inside a Tailscale SSH session can run with root privileges and reach sockets that are supposed to be restricted to the root user — in Windisch’s lab, this path was enough to read the system’s shadow password file. A companion flaw affecting remote forwarding (ssh -R) goes further: by replacing a root-owned socket, a session can reportedly trigger root-level code execution through a command daemon. Both are rated High severity and require nothing more exotic than an SSH rule that permits forwarding in the first place.

A third high-severity finding describes a timing window — a race condition — that can defeat a path-validation check before the corresponding file action completes, which in testing allowed a rogue node to join the network it shouldn’t have had access to. A separate issue affecting Tailscale’s session-handling let an attacker trigger memory exhaustion in the root daemon simply by churning sessions; the report says roughly 536 MB of memory was consumed in just seven seconds, enough to threaten availability on constrained hosts.

App Connectors, Relays, and Configuration Traps

Tailscale’s app connector feature, which lets a device route specific destinations through the network on a user’s behalf, has its own problem: a standard entitlement reportedly allows outbound traffic to effectively any destination, which in testing reached cloud metadata endpoints and internal Kubernetes services — exactly the kind of internal infrastructure that app connectors are supposed to help compartmentalize, not expose.

On the headscale side, the report describes a pair of medium-to-high severity issues: unauthenticated device registration attempts can evict other devices that are legitimately waiting for admin approval, and a malicious relay server can force a connecting client to read as much as 1.34 GB of data it didn’t ask for. The “serve” feature, which exposes local services to other nodes, picked up several additional findings, including a scenario where a TCP forward to the local API socket let a remote peer silently push configuration changes — in the lab, a settings change reported success despite not coming from an authorized operator, amounting to a path toward full node takeover. A related flaw involves swapping a symlink after setup to slip past a socket-access guard, letting a local user dial into root-only sockets despite the intended restriction.

Two further items are flagged more as design and configuration concerns than outright bugs: Funnel’s public-exposure behavior depends heavily on peer capability and local settings in ways the report argues deserve a harder look, and the TS_SERVE_ALLOW_ALL_INTERFACES environment variable can quietly expose a served port outside the private tunnel if an operator sets it without fully understanding the consequence.

What Tailscale Administrators Should Do Now

Because no vendor fix or official advisory exists yet, mitigation currently falls on operators who rely on Tailscale SSH and headscale in production. Security teams should consider:

• Auditing SSH access rules to identify where local and remote port forwarding are permitted, and restricting forwarding wherever it isn’t strictly necessary.
• Reviewing app-connector entitlements for destinations that could expose cloud metadata services or internal cluster APIs.
• Avoiding the TS_SERVE_ALLOW_ALL_INTERFACES setting unless its exposure is fully understood and intended.
• Monitoring headscale instances for unusual registration attempts, particularly ones that coincide with pending-approval evictions.
• Watching for an official response from Tailscale and applying any patched release as soon as one becomes available.

Mesh VPN tools like Tailscale are popular precisely because they make internal networking simple — but as this report underscores, that simplicity can mask a surprisingly large attack surface once SSH, relaying, and connector features are combined. Organizations that have treated Tailscale as a drop-in replacement for a hardened bastion host may want to revisit that assumption until the vendor weighs in.