Tailworm: findings, access conditions and fix status

Tailworm is a security research report about Tailscale and Headscale. It isn't evidence of a company breach. Its main Secure Shell (SSH) findings describe how an already-authorized connection could let an ordinary user reach privileged resources. Tailscale's October 28 findings and fixes confirms fixes in v1.104.4.

In short:

• Access is required. The SSH findings need a permitted connection, with forwarding permission also required for the socket-forwarding paths.
• Lab results matter. The report demonstrates conditional failures, not a company breach or confirmed customer attack campaign.
• Update affected deployments. Tailscale's four bulletins identify v1.104.4 or newer as fixed. Check Headscale separately.

What the report shows and Tailscale confirms

The researcher tested Tailscale v1.104.2 and Headscale v0.29.5 on researcher-owned systems. The work covered embedded SSH, Serve/Funnel, relay components, the shared gliderssh library and the experimental conn25 connector.

Tailscale acknowledged SSH privilege-escalation issues on October 26. Its subsequent findings article and four security bulletins confirm specific SSH and Serve vulnerabilities. Keep each bulletin's conditions separate from the researcher's broader report; they aren't a blanket confirmation of every reproduction or severity rating.

How an approved SSH session can gain more power

Conditions reported in lab testing of Tailscale v1.104.2. This diagram describes the tested vulnerable implementation, not the patched v1.104.4 release or evidence of real-world exploitation.

SSH lets you open a remote command session. Root is the local administrator account, with broad access to the system. A Unix socket is a local communication endpoint that can be restricted to particular users.

These findings concern the embedded Tailscale SSH server tested in v1.104.2. They aren't findings about an ordinary SSH server whose traffic travels over Tailscale. Tailscale SSH requires policy rules permitting both network access and SSH access. The reported socket-forwarding paths also require the relevant forwarding permission.

In the tested version, a permitted non-root session could ask root-running tailscaled to connect to root-only sockets. Another reported path uses a timing race: the agent checks a path, but where that path leads changes before the socket operation happens. The later operation uses the changed destination. Permission to connect and permission to act with root's access are separate boundaries.

Which other components the report covers

The report separates network reach, service availability and web forwarding from SSH privilege escalation. In the table, mounts are separately configured web paths, and HTTP/2 means Hypertext Transfer Protocol version 2.

These rows distinguish the researcher's tested components from the vendor's later confirmation. A Tailscale client fix doesn't establish the status of a separate Headscale server.

Tailscale says Conn25 was pre-production and unreleased, and that stable app connectors are unaffected. The researcher's connector result is a reachability issue, not SSH privilege escalation. Its reported pivot reaches destinations available from the connector's own network position. Receiving nodes rejected the tested bridges to other tailnet nodes and destinations behind their approved routes.

Serve shares content within your Tailscale network, while Funnel publishes it to the internet. Public delivery still needs the ingress capability. The researcher reports that stock Headscale couldn't grant that capability, so it didn't deliver Funnel traffic in the test. That negative result matters when judging which configurations the public-facing findings cover.

Remediation status as of October 27, 2026

This earlier checkpoint established package availability. The vendor confirmation below supersedes the remaining uncertainty from that date.

Current remediation status

Checked November 2, 2026: Tailscale's changelog and security bulletins identify v1.104.4 as the fixed release for the confirmed issues below. Follow your platform's supported update instructions and verify the installed version; a published fix doesn't mean your devices have installed it.

The researcher's updated report also attributes relay-client changes to v1.104.4 and describes separate Headscale work. Check Headscale's own release notes and the component you run before treating it as fixed. Updating a Tailscale client doesn't update a Headscale control server.

Tailscale classifies two other Serve/Funnel observations as intended behavior: the Funnel attribute check requires local administrator access to bypass, and TS_SERVE_ALLOW_ALL_INTERFACES intentionally exposes Serve beyond the tailnet. Keep these configuration choices distinct from the confirmed bugs. The older eMudhra certificate guidance is a separate issue and isn't the Tailworm fix. This guide reviews published evidence; it is not an independent reproduction of the patched behavior.

What this doesn't prove about real attacks

The researcher reports automated spread in a lab, bounded by the device pairs that SSH policy allowed. That doesn't establish a customer attack campaign or a breach of Tailscale's corporate infrastructure. It also doesn't prove that real-world exploitation has never occurred.

The tested builds aren't a complete affected-version or platform list. Having Tailscale installed doesn't establish that its embedded SSH server is enabled. Tailscale says exploitation also depends on user or device permissions, system configuration and other conditions.

Match your response to the access you allow

Identify whether sensitive devices use the embedded Tailscale SSH server, then narrow access to the users and devices that need it. Before changing systems you own or administer, save the configuration and arrange another way to regain access. Restarting tailscaled ends existing Tailscale SSH sessions.

Update affected deployments to v1.104.4 or newer and verify the version on each relevant device. If you don't need forwarding, Tailscale also documents setting TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restarting the service. This disables forwarding without disabling Tailscale SSH and mitigates several serious findings, not the whole report. Turning forwarding off is not a replacement for the release's other fixes. Review SSH policy and consider check-mode reauthentication for sensitive systems. A check-mode approval doesn't replace correct privilege enforcement inside an established session.

Related guides

• Tailscale SSH: authentication, devices and recording
• How to disable Tailscale SSH without disconnecting Tailscale
• Tailscale SSH alternatives with separate host authentication