Tailscale's October 2026 SSH and Serve Vulnerabilities: TS-2026-014 to TS-2026-017

#Overview

Tailscale released 1.104.4 on October 27 to fix four vulnerabilities, published as security bulletins TS-2026-014 through TS-2026-017. Two are in Tailscale SSH, the SSH server built into tailscaled, and two are in Tailscale Serve. The one the Tailworm report centers on, TS-2026-014, let an SSH session the tailnet policy already allowed reach root-only Unix sockets on the machine it connected to, such as the Docker socket or the tailscaled local API. The bulletins follow Tailworm, a public report by Erica Windisch of Cyberdione Labs, published October 24, three days before a fix existed. Tailscale hasn't assigned CVE IDs or severity ratings. In its write-up, the SSH issues "primarily concerned how permissions were enforced after a connection had been authorized, rather than the authentication and access policy checks that determine who can connect."

What Tailworm is: the name of a report, not of any malware. Tailworm is a security assessment of Tailscale's open-source client at 1.104.2 and of headscale 0.29.5, with 11 findings from three days of lab testing. The name comes from what the report calls the chain's "wormability." The disclosure wasn't coordinated. Tailscale says it received the report on the morning of October 24 and "the researcher published it two hours later," leaving no time for a fix; it had started investigating the day before, after concerns surfaced on social media. Windisch describes the disclosure as "reported but not coordinated." She told The Hacker News that she sent the report and her proof of concept to Tailscale's security contact before publishing, and had earlier raised concerns about Tailscale's architecture with its chief executive. The report argues that the infrastructure was vulnerable already and that public awareness would speed up remediation.

Why it's urgent: the report, including the commands its authors ran in their lab, was public for three days before the fix shipped. TS-2026-014 turns that one foothold into access to root-only sockets on every server the device may SSH to, and on a Docker host that means root: Docker's documentation says the group that exists to grant access to its socket "grants root-level privileges to the user." Tailscale's official container images hadn't been rebuilt as of 11:45 AM CDT, October 28, and headscale's policy has no switch to turn SSH forwarding off. No exploitation in the wild has been reported, and none of the four is in CISA's Known Exploited Vulnerabilities (KEV) catalog (timeline).

#Tailworm's claims

Our assessment of the report's main claims, checked against Tailscale's bulletins, the source code, and the report's own text. Most of it holds up, and Tailscale disputes one finding. Where the report overreaches, it's on scope: which machines, which configurations, and what counts as a worm.

True:

• Unix socket forwarding in Tailscale SSH reaches root-only sockets. Confirmed and fixed as TS-2026-014.
• SSH sessions can exhaust tailscaled's memory, Serve can expose the local API, and Serve can mix up capabilities across mounts. Confirmed and fixed as TS-2026-015, TS-2026-016, and TS-2026-017.
• headscale can't turn SSH forwarding off. It's hard-coded in headscale 0.29.6 (details).
• headscale servers can be exhausted, and lose pending device approvals, without authentication. headscale's maintainer cites Tailworm in a draft fix, #3586, which no release includes yet.
• Conn25 app connectors allow arbitrary egress. But Conn25 "hasn't been released," and Tailscale says today's app connectors aren't affected.

Partly true:

• One compromised device gets root on other servers. Only on servers the policy lets that device SSH to, with forwarding allowed, and root takes a socket like Docker's on the target. Tailscale: "an attacker could reach only machines the tailnet policy file already permitted SSH connections to."
• The chain is wormable, spreading in under a second per hop. That was measured only in the researcher's lab, and it's bounded by policy: the report says per-pair grants stopped it. Tailscale says the findings "don't describe self-replicating malware," and no spread has been reported outside a lab.
• A captured auth key joins an attacker's machine "as a legitimate tagged server with routes auto-approved" in default configurations. The lab captured a key and stopped there: "enrollment not executed." A key grants only what it was created with, and subnet routes need an admin's approval unless the policy's autoApprovers allow them.
• The fix is small, as OpenSSH and Dropbear show. The approach matches: forwarding now runs as the session user. But it wasn't small. The six forwarding commits add over 11,000 lines, about 4,000 of them outside tests.

Disputed:

• Funnel's entitlement is enforced only by the CLI. Tailscale says it works as designed: bypassing it "requires local admin access."

#Key facts

#Who is affected

Every Tailscale client below 1.104.4 is in range, but each bulletin needs a feature turned on: the Tailscale SSH server for TS-2026-014 and TS-2026-015, and Tailscale Serve for TS-2026-016 and TS-2026-017. Which configurations are exposed maps them out.

The Tailscale SSH server runs only on Linux and on the open-source tailscaled build for macOS. In Tailscale's docs: "You can currently use Tailscale SSH to connect to only Linux devices and macOS open source tailscale + tailscaled CLI version devices." The macOS apps, Windows, iOS, and Android don't serve SSH, so the two SSH bulletins don't apply to them. Update them anyway: the Serve fixes apply wherever Serve runs.

#Where to get 1.104.4

Tailscale shipped the fix only as 1.104.4, on the 1.104.x line. There's no patch for the 1.102.x or 1.98.x lines, so a node on either has to move to 1.104.

#How far back the bugs go

The bulletins say only that 1.104.4 fixes each issue, and Tailscale doesn't state the oldest affected version. Our reading of the source at release tags:

• TS-2026-014: Tailscale SSH gained Unix socket forwarding in the 1.98 line, released in May 2026. 1.96.5 and earlier forward only TCP ports. In June, TS-2026-004 fixed an earlier flaw in the same feature by resolving symlinks before checking paths; TS-2026-014's race works in the gap between that check and the use.
• TS-2026-016: Serve gained Unix socket backends in the 1.94 line, from January 2026. In June, TS-2026-005 restricted them to root.
• TS-2026-015: the report says the session-handling flaw is "inherited from upstream gliderlabs/ssh v0.3.8," the SSH library Tailscale's fork builds on, which suggests it's older than both.

Lacking a feature doesn't make an older version safe: it misses every fix since, including TS-2026-004 and TS-2026-005.

#headscale tailnets

headscale is an open-source, self-hosted replacement for Tailscale's control server. The SSH bugs are in the Tailscale client, so headscale users fix them the same way: update every node to 1.104.4. Two things differ.

• SSH forwarding can't be turned off in headscale's policy. In headscale 0.29.6, every SSH accept rule grants agent, local, and remote forwarding. The three flags are hard-coded to true in filter.go, and the policy format has no field to change them. The report's advice: "treat every headscale SSH grant as root-equivalent" until clients are patched. On an unpatched node, TS_SSH_DISABLE_FORWARDING=1 is the only off switch. A feature request for per-rule controls, #3601, was opened on October 28; a pull request implementing it, #3599, was closed unmerged 18 seconds after it was opened.
• The server-side findings have no fix. The report describes unauthenticated memory exhaustion on internet-reachable headscale servers, and a way to evict pending device approvals that blocks new devices from joining. headscale 0.29.6, released October 24, is a security release for the eMudhra certificate compromise and library updates. It predates the report and doesn't address it. Kristoffer Dalby's draft pull request #3586, "hscontrol: bound pending authentication without evicting sessions," is open. A separate issue, #3602, notes that headscale's pinned Tailscale library predates the DERP client fix in 1.104.4.

#How the vulnerability works

Tailscale SSH takes the place of a standard SSH server. tailscaled accepts the connection, checks the tailnet policy, and starts the session as the local user the policy names. tailscaled runs as root, because starting sessions as other users needs root, and OpenSSH has the same requirement. In Tailscale's words, "The challenge is ensuring those privileges don't extend to the connected user's session, where commands and features such as SSH forwarding must remain within the permissions granted to that user."

TS-2026-014 is where that failed. SSH can forward Unix sockets as well as TCP ports. Tailscale SSH checked each requested socket path against an allowlist, then opened or replaced the socket as root. The bulletin lists three ways that check fell short, including a race between the check and the use, which "combined to remove the path allowlist as a security boundary." A session with forwarding allowed could reach sockets only root should touch: the Docker socket, or tailscaled's own local API.

No password or SSH key is involved. Tailscale SSH authorizes the device, not a credential, so the attacker needs control of a device the policy lets SSH to the target, and nothing else. TS-2026-015 needs the same access and crashes tailscaled instead. The Serve bugs need local configuration rights or write access (TS-2026-016), or a specific multi-mount setup (TS-2026-017).

What an attack gets depends on the sockets on the target. Through the Docker socket, it's root on the host. Through the local API, it's control of the node: Tailscale's words for the same reach through Serve, in TS-2026-016, are "full node takeover." The report says its lab demonstrations yielded root code execution and the capture of an auth key that enrolls new devices.

#The fix

Rather than patch the path checks again, 1.104.4 stops doing forwarding as root. A privileged monitor in tailscaled hands each forwarding operation to a child process running with the session user's credentials, so the kernel's own permission checks apply. In the bulletin's words: "Tailscale now performs Unix socket forwarding on behalf of the authenticated user rather than as root." TCP forwards are dialed as the session user too. Most of the added lines are tests.

The other three bulletins have small, targeted fixes. TS-2026-015's are in Tailscale's fork of the SSH library, which 1.104.4 pulls in through go.mod. TS-2026-016's two parts land separately: refusing TCP forwards to the tailscaled socket, and re-checking the target on every dial instead of only when the configuration loads.

The 42 commits between 1.104.2 and 1.104.4 also harden Tailscale SSH beyond the bulletins. Among them, by title: "enforce SSH policy at the connection level," "extend dangerous env var denylist, re-check child-side," "validate accepted env values, deny GLIBC_TUNABLES, cap names," "refuse direct-exec fallback for non-root users as root," and "write private host keys with 0600 permissions."

#Which configurations are exposed

What follows is our reading of the bulletins' conditions, not confirmed exploit paths. Bulletins are listed by their last three digits: 014 is TS-2026-014.

Tailscale's basis for each, from the bulletins:

• TS-2026-014: "users with Tailscale SSH enabled who also allow local or remote forwarding in their access policies."
• TS-2026-015: "An authenticated SSH session permitted by policy is required to trigger the condition."
• TS-2026-016: "nodes where a local operator has the ability to write serve configurations or where local users have write access to configured backend paths."
• TS-2026-017: "nodes with serve TLS enabled and at least two mounts with different capability requirements on the same node. The issue requires concurrent streams multiplexed on a single connection."

Is forwarding allowed in your policy? TS-2026-014 depends on it, but Tailscale's policy file reference doesn't document a forwarding setting for SSH rules as of 11:45 AM CDT, October 28. We found no documented way to read it from a policy, so unless a node has the environment variable set, assume forwarding is allowed.

Patch these first:

• Servers that accept Tailscale SSH from many devices, through rules for whole groups, tags, or autogroup:member. The report calls per-pair access grants "the single control that stopped" the spread in its lab.
• SSH targets with privileged sockets: Docker, containerd, or a kubelet.
• Internet-reachable headscale servers, for the unauthenticated findings above.
• Nodes that serve Unix sockets through Tailscale Serve.

#How to check your systems

Checking one machine tells you about one machine. Tailscale runs on servers, NAS boxes, and laptops, in containers, and as Kubernetes proxies, and each one updates through its own channel.

#Check a node

1tailscale version --daemon2# Daemon: 1.104.4-t938213198-gd38c96d6a   ← the running daemon: what counts34# Is the Tailscale SSH server on?5sudo tailscale debug prefs | grep RunSSH      # "RunSSH": true → yes67# Is the forwarding mitigation active in the running daemon? (Linux)8sudo tr '\0' '\n' < /proc/$(pidof tailscaled)/environ \9  | grep TS_SSH_DISABLE_FORWARDING1011# Does Serve use Unix sockets, or forward app capabilities?12sudo tailscale serve status --json | grep -n '"unix:'          # TS-2026-01613sudo tailscale serve status --json | grep -n '"AcceptAppCaps"' # TS-2026-017

tailscale version alone describes the CLI, and the CLI updates before the daemon restarts. In our test, a Debian 12 container upgraded from 1.104.2 to 1.104.4 printed a mismatch warning and Daemon: 1.104.2-… until tailscaled restarted. When the mitigation is active, tailscaled also logs envknob: TS_SSH_DISABLE_FORWARDING="1" as it starts.

We ran these against the official 1.104.2 and 1.104.4 Linux builds in containers. We ran the Serve patterns, with GNU grep 3.8, against a logged-out node and against a configuration fixture built from Tailscale's ServeConfig fields, because Serve can't be configured without a tailnet.

#Check the whole tailnet

On Tailscale's hosted control plane, the admin console's Machines page shows each device's version, and the API returns it as clientVersion. This lists every device below 1.104.4, using an API access token from the admin console's Keys page:

1curl -sS -u "$TS_API_KEY:" https://api.tailscale.com/api/v2/tailnet/-/devices \2  | jq -r '.devices[] | select(.clientVersion != "")3      | (.clientVersion | ltrimstr("v") | split("-")[0]4         | split(".") | map(tonumber)) as $v5      | select($v < [1, 104, 4])6      | [.hostname, .os, .clientVersion] | @tsv'

We tested the filter with jq 1.6 against device records shaped like the API's schema, including versions with and without a v prefix and a device shared in from another tailnet, which has an empty clientVersion. We didn't run it against a live tailnet.

On headscale, neither headscale nodes list nor headscale's API reports client versions, and tailscale status doesn't show peers' versions. Check each node with tailscale version --daemon.

#Check images and running containers

1docker ps --format '{{.Names}}\t{{.Image}}' | grep -i tailscale2docker exec <container> tailscale version --daemon

The official images haven't been rebuilt. As of 11:45 AM CDT, October 28, Docker Hub's stable, latest, and v1.104 tags point to 1.104.2, pushed October 20 at 10:07 PM CDT. On GHCR, stable and latest point to 1.104.2 and v1.104 still to 1.104.1. Neither registry has a v1.104.4 tag. The Kubernetes operator's images are at 1.104.2 too. Rebuilding with --pull won't help until Tailscale pushes a new image; until then, use the mitigation in any container that runs Tailscale SSH. For operator-managed proxies, run the same tailscale version --daemon inside each proxy pod.

#Check distribution packages

1dpkg-query -W tailscale    # Debian and Ubuntu2rpm -q tailscale           # Fedora, RHEL, and other RPM-based distros

Tailscale's own apt and yum repositories have 1.104.4. Distribution packages lag. As of 11:45 AM CDT, October 28:

• Have 1.104.4: FreeBSD ports, nixpkgs master, and Fedora Rawhide.
• Don't yet: Arch (1.104.2-1), nixos-unstable (1.104.2), NixOS 26.05 (1.98.10), and Alpine edge (1.102.5-r0) and 3.24 (1.98.10-r1). Fedora 43, 44, and 45 have pending 1.102.5 updates, which predate the fix.

If a host can't wait for its distribution, switch it to Tailscale's repository or to the static binaries from pkgs.tailscale.com.

#How to fix

#Update to Tailscale 1.104.4

1sudo tailscale update      # Tailscale's built-in updater23# Or, if the node uses Tailscale's apt or yum repository:4sudo apt-get update && sudo apt-get install --only-upgrade tailscale5sudo dnf upgrade tailscale67tailscale version --daemon # confirm the daemon, not just the CLI

In our tests, tailscale update --dry-run reported Current: 1.104.2, Latest: 1.104.4 on Debian 12, and the apt-get and dnf lines took Debian 12 and Fedora 42 from 1.104.2 to 1.104.4. The 1.104.4 .deb restarts tailscaled itself. Whatever the install method, confirm the daemon's version afterwards. A restart ends the SSH sessions tailscaled is serving, so update over a connection that doesn't depend on that node's Tailscale SSH, or expect to reconnect.

• macOS: update the open-source tailscaled the way you installed it; Homebrew's tailscale formula is at 1.104.4. The standalone 1.104.4 app package is on pkgs.tailscale.com.
• Synology and QNAP: 1.104.4 packages are on pkgs.tailscale.com.
• Containers and the Kubernetes operator: bump the image tag once Tailscale publishes 1.104.4 images. Until then, use the mitigation below.
• headscale: update every client. There's no server release to install yet.

#Check for signs of compromise

The report's commands were public for three days before the fix. If someone could have controlled any device in your tailnet in that window, or at any point since you moved to the 1.98 line, check the machines that device was allowed to SSH to. These are Atlas's recommendations:

1. Devices and keys. In the admin console's configuration audit logs, look for auth keys you didn't create and devices you didn't add, especially tagged ones. The report describes joining an attacker's machine "as a legitimate tagged server with routes auto-approved" with a captured key. On headscale, compare its node and pre-auth key lists against what you expect.
2. Containers nobody launched on SSH targets that run Docker, especially any that mount the host's root filesystem. The command below lists those.
3. Serve configuration. Run the Serve checks above and look for unix: targets nobody configured.

1# Containers that mount the host's root filesystem, with their creation times2F='{{.Created}} {{.Name}}{{range .Mounts}}{{if eq .Source "/"}} ROOT{{end}}{{end}}'3docker ps -aq | xargs -r docker inspect --format "$F" | grep ' ROOT$'

We tested it with Docker 27.5.1 against two fixture containers, one with / mounted; it listed only that one.

If anything turns up, delete the device in the admin console or in headscale, rotate auth keys, and rotate every credential reachable from the affected host, such as registry logins and cloud keys. Report it to IC3 if you're in the US. Reimaging isn't enough on its own. In the report's words: "A node's identity is key material stored in its state file; an attacker with root on the host can have copied that file off-box." Deleting the device invalidates the copy.

#If you can't patch immediately

Tailscale's interim guidance was to review SSH access policies, consider "temporarily tightening your Tailscale SSH access policies," and disable forwarding: "Set TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restart the service. This disables SSH forwarding without disabling Tailscale SSH entirely, and mitigates several of the more serious findings."

On Linux, the tailscaled service from Tailscale's .deb and .rpm packages reads /etc/default/tailscaled:

1echo 'TS_SSH_DISABLE_FORWARDING=1' | sudo tee -a /etc/default/tailscaled2sudo systemctl restart tailscaled

In containers, add -e TS_SSH_DISABLE_FORWARDING=1 to docker run; the official image's entrypoint passes its environment to tailscaled. We confirmed that the .deb and .rpm units both read that file, that systemd 252 passes the line through, and that the variable reaches tailscaled in the official tailscale/tailscale:v1.104.2 image. Then run the check to confirm it's active.

Atlas's interim recommendations, none of which is a fix:

• Narrow SSH rules to the pairs that need them. Tailscale recommends reviewing SSH policies and using check mode for sensitive systems, and per-pair grants are what the report found contained its lab spread.
• Turn off Tailscale SSH where nobody uses it: sudo tailscale set --ssh=false removes both SSH bulletins on that node. Tailscale says it's "not recommending that everyone disable Tailscale SSH."
• Remove Serve Unix socket backends you don't need, and don't rely on Tailscale-App-Capabilities headers across mounts until you update.
• For headscale servers, the report advises a memory limit, a rate-limiting proxy, and restricted exposure. If only your own devices need to reach the server, don't expose it to the whole internet.

#Tailworm findings without a bulletin

The report lists 11 findings. The four bulletins cover the confirmed ones that, in Tailscale's words, "warrant separate disclosures." As of 11:45 AM CDT, October 28, the rest stand as follows:

1.104.2, released a week earlier, fixed TS-2026-013, Tailscale's bulletin for the leaked eMudhra intermediate certificate keys, by moving to Go 1.27.3. It's the same compromise behind the root-certificate update in Node.js's October release. Updating to 1.104.4 covers both.

#Timeline and exploitation status

Dates and times come from Tailscale's and headscale's GitHub releases and commits, Tailscale's own accounts, the Wayback Machine's first captures, and Docker Hub. All times are CDT (UTC−5).

Exploitation status. No exploitation in the wild has been reported. None of the four bulletins has a CVE, and no Tailscale vulnerability is in CISA's KEV catalog as of 11:45 AM CDT, October 28. Per The Hacker News, "The proof-of-concept code is not public, and Windisch said she gave it only to Tailscale's security team." The report itself includes the commands its authors ran in their lab. Windisch has described the disclosure as "reported but not coordinated," per the same article. Tailscale's earliest SSH commits in 1.104.4 are author-dated the evening before it says it received the report, which fits its account that it was already investigating. We haven't tested any proof of concept.

#Updates to this post

We'll revise this post and mark it updated when any of these change: CVE IDs or severity ratings for the bulletins; rebuilt Tailscale container or Kubernetes operator images; a headscale release that addresses the report; distribution packages reaching 1.104.4; a KEV listing or any report of exploitation.

#Get help

If you'd rather not do this alone, our advisors can help: the node inventory, the SSH policy review, or a check of what each device can reach.

Tailworm starts from a foothold on a device you already trust, and the first way in the report lists is an exploited web application. Our free external audit checks the domains and public IPs you verify for open services, publicly visible software versions with known CVEs, TLS, email security, DNS, and HTTP headers. An internet-reachable headscale server shows up there as an open service.

#Sources

• Tailscale: security bulletins TS-2026-014, TS-2026-015, TS-2026-016, TS-2026-017, TS-2026-013, TS-2026-005, and TS-2026-004 · Tailscale SSH: Findings and fixes · SSH investigation update · changelog
• Tailscale code: v1.104.4 release · v1.104.2…v1.104.4 · the forwarding switch in tailssh.go at 1.104.2 · gliderssh commits · pull requests #21931, #21966, #21980, and #22003
• Tailscale docs: Tailscale SSH · policy file reference · API
• Research: Tailworm, by Erica Windisch, Cyberdione Labs
• headscale: v0.29.6 release · filter.go at v0.29.6 · pull requests #3586, #3599, and #3600 · issues #3601 and #3602
• CVE records and agencies: CISA KEV catalog · GitHub advisories for tailscale.com · CVE-2023-28436
• Packages: pkgs.tailscale.com · Docker Hub: tailscale/tailscale · Homebrew · Arch · Alpine · nixpkgs · FreeBSD ports · Fedora
• Reporting: The Hacker News, October 25 and October 28
• Docs: Docker: Linux post-installation steps