Tailscale SSH Vulnerability: How One Hacked Device Could Reach Root on Other Servers

The Tailscale SSH vulnerability reported in the Tailworm research lets an attacker who already controls one device in a tailnet reach root on other servers that device is allowed to SSH into. It works by abusing SSH port forwarding. As of October 26, 2026, Tailscale has released no patch, CVE or security bulletin, so the fix today is tightening your configuration.

Tailscale is one of the most popular ways for developers and companies to connect servers, laptops and cloud machines privately. Its built-in SSH feature is popular because it removes the pain of managing SSH keys. That convenience is exactly why the Tailscale SSH vulnerability matters: a feature designed to make access simpler may, according to the researcher, make one compromised device much more dangerous.

Here's what was found, who is exposed, what Tailscale has said, and the steps you can take today. This article is based on the original Tailworm report, Tailscale's own documentation and Tailscale's public statements.

What is Tailscale SSH and how is it different from normal SSH?

Tailscale builds a private network, called a tailnet, between your devices using WireGuard encryption. Tailscale SSH is an optional feature that lets Tailscale handle SSH logins between those devices.

With normal SSH, the server checks the user's password or private key. Tailscale SSH works differently. According to Tailscale's documentation:

• Tailscale takes over port 22 for traffic coming from the tailnet, and routes it to an SSH server run by Tailscale instead of your usual sshd.

• The connection is authenticated using the device's Tailscale node key. During the SSH login phase, Tailscale "already knows who the remote party is" and uses the SSH authentication type none, so the client doesn't provide a password or key.

• Whether a connection is allowed is decided by SSH access rules in the tailnet policy file, which list a source, a destination and the allowed login users (which can include root).

• It is opt-in per device: a server only runs Tailscale SSH after an administrator enables it with tailscale set --ssh.

That design removes SSH key sprawl, which is a real security benefit. But it also means that, if the policy allows it, control of a permitted device is enough to open an SSH session. No stolen password or key is needed. That's the starting point for the Tailworm findings.

What did the Tailworm report find?

The report, titled Tailworm, was published on October 25, 2026 by security researcher Erica Windisch of Cyberdione Labs. She tested Tailscale v1.104.2 and headscale v0.29.5 (the open-source, self-hosted alternative to Tailscale's control server) in a lab between October 22 and 24, 2026.

The report lists 11 findings. The three that make up the Tailscale SSH vulnerability involve Tailscale SSH port forwarding, all rated High by the researcher:

1. Local socket forwarding runs as root. Using standard ssh -L forwarding to a Unix socket, an ordinary SSH session caused the root-level Tailscale process to connect to a system socket that only root should be able to reach. In the lab this gave root access and the ability to read the system password file, without sudo or admin rights.

2. Remote socket forwarding replaces root-owned sockets. Using ssh -R, the attacker could replace a root-owned socket with their own, allowing root-level command execution against certain services.

3. A race condition defeats the path allowlist. A safety check meant to limit which files forwarding can reach could be beaten by racing the system between when it checks a path and when it uses it, a classic TOCTOU (time-of-check to time-of-use) bug.

According to the report, the third chain went further in testing: it captured a key used to enroll new devices and used it to join an attacker-controlled machine to the tailnet as a trusted node.

What are the other findings in the report?

The remaining eight findings cover other parts of the Tailscale ecosystem:

• App connectors (conn25): in this experimental feature, a permitted user could send traffic to destinations the security team never approved, including a cloud provider's metadata service, which can hand out server credentials. Windisch told The Hacker News this "may be more impactful to some organizations" than the SSH issue.

• Memory exhaustion: one finding can exhaust memory in the root Tailscale process through an SSH session; another affects headscale.

• tailscale serve: several findings involve serve forwards to Unix sockets, Funnel permission checks and a configuration setting that exposes serve outside the tunnel.

Why is the Tailscale SSH vulnerability called "wormable"?

In the lab, Windisch showed that once one device reaches root on a target, that target can be used the same way against the next device the access rules allow, and so on. The report says this happened with no passwords, no stolen keys and no user action, in under a second per step. In its words, "the mesh converts one ordinary foothold into fleet-wide privileged access at machine speed."

Keep three things in mind about that claim:

• It was measured in a lab, not seen in attacks on real networks.

• Some researchers have publicly questioned the "wormable" label, while others called the root-access finding serious.

• The findings rest on one researcher's report. No one else has publicly reproduced them, the proof-of-concept code is not public, and Tailscale has not confirmed the specific technical claims.

That doesn't make the report safe to ignore. Lateral movement from one hacked machine to many is how most serious breaches grow, as we covered in our piece on AI agents as insider threats. It does mean you should act on facts, not headlines.

Who is affected by the Tailscale SSH vulnerability?

You are most likely exposed if all of these are true:

• You have Tailscale SSH enabled on Linux servers (or macOS devices running the open-source tailscaled). It is off unless someone turned it on.

• Your SSH access rules let one device connect to others, especially broad rules that grant access by group, tag or every member.

• Port forwarding is allowed in those SSH sessions.

• An attacker already controls one permitted device.

That last point matters. Tailscale doesn't create the first foothold. According to the report as summarised by The Hacker News, attackers would get it the usual ways: a vulnerable web application, a poisoned software package, phishing or stolen login details. This is a privilege-escalation and lateral-movement problem, not an internet-facing remote code execution bug.

Are headscale users at higher risk?

Yes. On Tailscale's hosted service, forwarding can be switched off per SSH rule. On headscale v0.29.5, the report says forwarding is granted on every accepted SSH session and cannot be disabled. The report's advice is to treat every SSH grant on headscale as giving root on the target until a fix ships.

Does Tailnet Lock stop the attack?

Partly. Tailnet Lock requires new devices to be signed by trusted nodes before they can join. The report says the full chain to enroll a rogue device worked only on tailnets without Tailnet Lock, which is the default. With Tailnet Lock enabled, the needed secrets were captured in transit, but the final step was not completed. The root access on reachable servers is a separate problem that Tailnet Lock doesn't prevent.

What has Tailscale said about the Tailworm findings?

As of October 26, 2026, Tailscale had published no security bulletin, no CVE and no fixed version for these findings. The latest bulletin on its security page at the time of the report, TS-2026-013, is unrelated.

Mike Shaver, Tailscale's vice president of engineering, wrote on Reddit, as reported by The Hacker News, that the company:

• had received the report;

• had already been looking at the same areas with outside security specialists, and had found issues it is working to fix;

• is still working out which setups are affected; and

• is "not recommending that everyone disable Tailscale SSH."

Tailscale also suggests enabling SSH check mode and automatic updates. Be aware that the Tailworm report states check mode does not mitigate the forwarding findings. Check mode makes a user sign in again with their identity provider before connecting. That adds a barrier in front of a session, but it doesn't fix what happens inside one.

Was the disclosure coordinated?

This is disputed. Windisch described the disclosure as "reported but not coordinated," and some commenters criticised publishing before a fix existed. She told The Hacker News she sent the report and proof-of-concept code to Tailscale's security contact on the Saturday before publication, and had earlier raised architecture concerns with the company's CEO. The report itself says the researchers believe "infrastructure is vulnerable today" and that rapid awareness speeds remediation.

Whatever you think of that choice, the practical outcome is the same: the details are public and there's no patch, so defenders need to act on configuration.

Has Tailscale SSH had similar bugs before?

Yes, which is part of why this Tailscale SSH vulnerability report got attention. Earlier in 2026, Tailscale fixed several Tailscale SSH and serve socket-handling issues. Its bulletin TS-2026-004 described Unix socket forwarding in Tailscale SSH that didn't properly enforce permissions on symlinks, letting unprivileged users reach privileged sockets; Tailscale lists the fix as version 1.98.9 or newer. Another bulletin, TS-2026-009, covered SSH accepting usernames that start with a dash.

If you're still running a version older than those fixes, update first. Those bugs do have patches.

How do you protect against the Tailscale SSH vulnerability today?

Until Tailscale ships a fix for the Tailscale SSH vulnerability, these steps from the Tailworm report and Tailscale's guidance reduce your risk. They're in rough priority order.

1. Find out where Tailscale SSH is enabled

List the devices that advertise Tailscale SSH in your admin console, and review the ssh section of your tailnet policy file. Many teams enabled it once for convenience and forgot about it.

2. Turn it off where you don't need it

On devices that don't need Tailscale SSH, disable it:

tailscale set --ssh=false

Tailscale's docs warn to make sure you have another way to reach the device first, such as your normal sshd with keys, or you may lock yourself out. Your existing sshd_config and authorized_keys are not changed by Tailscale SSH, so regular SSH keeps working.

3. Narrow your SSH access rules to single source-to-destination pairs

The report says rules written as one source and one destination stopped the spread on their own in testing. Replace broad rules (every member to every tagged server, or one tag to another wide tag) with narrow ones, and avoid allowing root as a target user. For example, using the rule format from Tailscale's docs:

"ssh": [
  {
    "action": "accept",
    "src": ["tag:deploy-runner"],
    "dst": ["tag:web-01"],
    "users": ["deploy"]
  }
]

This lets only the deploy runner reach one server, as one non-root user. Use SSH tests in the policy file to confirm rules behave as you expect.

4. Disable SSH port forwarding where you can

On Tailscale's hosted service, forwarding is a per-rule setting. Turn it off for any rule that doesn't need it. On headscale v0.29.5, you can't, so treat every SSH grant as root access and keep grants to an absolute minimum.

5. Clean up related features

• Remove app connector permissions from devices that don't need them, and add egress allowlists that block cloud metadata endpoints.

• Remove any tailscale serve forward that points at a Unix socket.

6. Limit how long stolen keys stay useful

• Turn on node-key expiry so a copied device key doesn't stay valid forever.

• Use hardware-backed device keys (TPM or Secure Enclave) where available. The report names this as a second control that held back the attack.

• Consider enabling Tailnet Lock, which blocked the final rogue-device step in testing.

7. If a device is compromised, delete it at the control plane

Reimaging a hacked machine is not enough. Keys an attacker copied off it stay valid until you remove the device in the Tailscale admin console (or headscale). If a Tailnet Lock signing node was compromised, rotate Tailnet Lock too.

8. Watch for the official fix

Enable automatic updates and watch Tailscale's security bulletins and changelog. When a bulletin is published, check which versions it covers and update promptly. Don't assume any version after 1.104.2 is fixed until Tailscale says so.

What does the Tailscale SSH vulnerability teach security teams?

The bigger lesson isn't about Tailscale specifically. Any system that turns device identity into access makes each device more valuable to an attacker. When a single policy rule can grant root across many servers, one compromised laptop or CI runner becomes a master key.

• Least privilege applies to network policy too. "Everyone in engineering can SSH to every server as root" is convenient and dangerous, whatever tool you use.

• Convenience features need review. Port forwarding, serve and app connectors each widen what one session can do.

• Plan for the first foothold. Assume a device will be compromised one day, and make sure the blast radius is small.

The same pattern shows up again and again: we saw it in the PHP2Shell response, where fast, careful configuration and patching decisions mattered more than headlines. And if you're preparing for security roles, lateral movement and least privilege are exactly the topics in our cybersecurity interview questions.

We'll update this article on the Tailscale SSH vulnerability when Tailscale publishes a security bulletin or fixed version.

Sources: Tailworm report (Cyberdione Labs) · Tailscale SSH documentation · The Hacker News · SC Media · Tailscale bulletin TS-2026-004 (via GCVE)