How Tailworm traced authority from authenticated devices through Unix privileges, local management interfaces, and network identity.
Vulnerability Research · Tailscale · Zero Trust · Authorization · SSH · Privilege Separation
Analysis based on public evidence available as of October 26, 2026.
Abstract
On October 25, 2026, security researcher Erica Windisch of Cyberdione Labs published Tailworm, an assessment of Tailscale v1.104.2 and headscale v0.29.5 that documented eleven findings involving SSH forwarding, Unix socket permissions, application connectors, local management interfaces, and HTTP/2 request handling. In laboratory tests, the researcher reported a path from an authorized Tailscale SSH connection to root-level operations on the destination host, along with paths to intercept local management traffic, acquire device-enrollment credentials, and register an attacker-controlled device under particular conditions. The Docker demonstrations had distinct prerequisites: one used a Docker socket already inside a permitted directory, while another won a pathname race to reach the standard /run/docker.sock. Neither describes root access from every authorized SSH connection. None of the tested paths required a break in WireGuard encryption or a bypass of initial network authentication; the failures arose after an authorized connection reached software whose operating-system privileges exceeded those of the connecting user.
That distinction matters because Tailscale decides which devices may communicate and which SSH sessions may be established, while Linux independently decides what each local user and process may do. Tailworm reported several ways in which an authorization could lose its original meaning as a request moved between those systems: an ordinary user’s forwarding request could be executed by a root process; access to a named application could become access to another destination; and capabilities attached to one HTTP request could influence another. Subsequent repair work also identified SSH operations that could continue after administrators revoked the permissions on which the connection had been accepted. These are distinct implementation failures, but each raises the same question: did the operation ultimately performed remain within the authority originally granted? This article reconstructs the reported paths and their repair history, then examines Tailscale’s shift from checking requested paths toward separating the privileges of the processes that carry requests out.
1. The Authorized Connection That Reached Root
1.1 How Tailscale SSH establishes authority
Tailscale provides private connectivity using WireGuard: its control plane manages device identities, network keys, and access policies, while WireGuard authenticates and encrypts traffic between permitted peers. Tailscale SSH extends that arrangement to remote access by letting administrators specify which identities or devices may reach a server and which local Unix accounts they may use. Unlike a conventional OpenSSH deployment that authenticates users through their own SSH credentials, it can complete the SSH user-authentication phase using the none method because the authenticated Tailscale device identity and the applicable SSH policy supply the authorization.
The server-side SSH functionality runs inside tailscaled, a daemon that commonly has root privileges on Linux. The SSH policy names the local user on whose behalf a session is accepted, but the kernel judges filesystem and socket operations by the credentials of the process that performs them. Ordinary shell commands are intended to run as the selected Unix user; forwarding raises a different question, because the server must open or create a socket in response to the user’s request. Whether that system call uses the user’s credentials or the daemon’s credentials determines which local resources the request can actually reach.
1.2 The Unix socket boundary
An SSH session can forward TCP connections and Unix domain sockets as well as carry an interactive shell. Local services such as Docker and systemd expose Unix sockets for administrative operations, often relying on filesystem permissions or peer credentials to decide who may use them. Establishing SSH access to a host should not itself confer permission to connect to those protected interfaces. Tailworm’s first three findings examined that separation in Tailscale v1.104.2: although forwarding requests went through permission checks and pathname validation, the root-privileged tailscaled process could still perform the underlying socket operation. Local Unix socket forwarding could therefore connect as root, while remote forwarding could create or replace a socket with the daemon’s privileges.
The report gives several laboratory examples with different entry conditions. In one configuration, an SSH user without sudo privileges or Docker-group membership reached a Docker daemon whose socket was already in an allowed directory, then ran a root-privileged container with access to host files. That demonstration depends on the socket’s placement; it does not describe the usual /run/docker.sock location. For the separate pathname race, the researcher ran an unprivileged process inside the admitted SSH session to repeatedly change a path on the destination host between validation and use. A successful race reached the standard Docker socket under /run and enabled container operations, although SELinux restricted subsequent host-file access in one tested environment. Against /run/systemd/private, systemd accepted a race-won connection as root, and a privileged operation succeeded when the researcher replayed its protocol bytes over that connection; delivering the whole sequence through the race remained intermittent. These were reported laboratory reproductions rather than independently confirmed production attacks. [1] Their common authorization mismatch is specific:
| Authorized operation | Actual operation | |
|---|---|---|
| Principal | SSH session mapped to an ordinary Unix user | Socket operation performed by root-privileged tailscaled |
| Resource | Socket pathname accepted by forwarding policy | Potentially different socket reached after path resolution |
| Time | Path examined during validation | Path used later by the kernel |
| Authority | Permissions of the selected Unix user | Permissions of the process performing the system call |
The network authentication remained intact, but the local operation could be carried out with authority greater than the SSH user’s permissions.
1.3 From host authority to network identity
Tailscale also maintains local state and exposes a LocalAPI through which client tools inspect and manage the daemon, so a protected socket can lead beyond administration of one Linux host. Tailworm reported that remote Unix socket forwarding, under certain race conditions, could replace a local management socket and divert traffic from authorized client software to an attacker-controlled endpoint. One test captured a LocalAPI request containing a device-enrollment auth key but stopped at interception. In a separate laboratory chain, a persistent socket replacement and HTTP-aware intermediary captured a live key that was then used from a test device to join a Tailnet without Tailnet Lock enabled. [1] The second test established enrollment under those conditions; the first did not.
The report also tested identity reuse by copying device-state material after host compromise and loading it on other hardware. That path depends on possession of an existing device’s state, whereas the enrollment experiment used an auth key to register a new device. Both concern the persistence of network identity, but they cross different boundaries and should be read as separate experiments.
Neither experiment establishes an unconditional route from one SSH connection to control of an entire Tailnet. Forwarding and the relevant socket operations must be available; enrollment credentials or device-state material must be usable; and Tailnet Lock, hardware-backed keys, key expiration, revocation, and network policies can restrict registration, persistence, or subsequent reachability. Under the report’s conditions, however, access meant to administer one server could reach the mechanisms that establish network identity. The initial grant concerned local SSH access, while the later operation concerned participation in the network as a recognized device.
2. Timeline of Repeated Boundary Failures
The October findings did not appear without precedent. Earlier Tailscale security bulletins had already described related problems in which one type of authorization was applied while a more privileged operation was executed.
| Date | Development | Significance |
|---|---|---|
| June 3, 2026 | TS-2026-004: Unix socket forwarding through symbolic links | Path authorization did not correspond to the protected target |
| June 3, 2026 | TS-2026-005: Serve proxy to privileged Unix sockets | Non-root operator permission could cause root-level proxy operations |
| June 11, 2026 | TS-2026-006: Numeric UID permitted root access despite SSH restrictions | Identity representation changed the meaning of a rule |
| July 10, 2026 | TS-2026-007: Services exposed loopback listeners beyond advertised ports | Service authorization covered less than the resulting reachability |
| October 8, 2026 | headscale PR #3517 corrected empty SSH policy handling | Policy removal could otherwise preserve old permissions |
| October 21, 2026 | Tailscale v1.104.2 released | Version subsequently examined in Tailworm |
| October 22–24, 2026 | Tailworm laboratory assessment | Multiple SSH, connector, and Serve findings reproduced |
| October 24, 2026 | Tailscale PR #21924 merged | A non-root SSH session’s root-execution fallback was rejected |
| October 25, 2026 | Tailworm published; Tailscale responded; PR #21931 merged | Vendor acknowledged related concerns and isolated Serve capabilities by request |
| October 26, 2026 | PR #21941 and #21942 merged; #21944 remained open | Forwarding was routed through user-credentialed children in source; connection-level policy reevaluation was still proposed |
Sources: Tailscale Security Bulletins, Tailworm, and the referenced repair pull requests.
2.1 The June repair
TS-2026-004 concerned symbolic links in SSH Unix socket forwarding. Before the June repair, a user could submit a pathname inside an allowed directory that resolved to a protected resource elsewhere: the permitted-directory check accepted the path even though the ensuing operation affected an object outside its intended scope. Tailscale added symbolic-link resolution and checked whether the resolved destination remained allowed, closing that reported escape route. The change still left the authorized SSH user distinct from the privileged process carrying out the socket operation.
Tailworm later reported a time-of-check/time-of-use race against the revised validation. The check examined a pathname at one instant, but the kernel resolved it again when the daemon acted, after an unprivileged process in the SSH session changed the path. Further path checks might narrow that interval without changing the credentials used for the final operation. June’s repair therefore left a second question for the October work: which principal performed the socket operation?
2.2 What Tailscale acknowledged in October
On October 25, Tailscale VP of Engineering Mike Shaver said the company had received the researcher’s report and was reviewing it with its engineering and security teams, assisted by external specialists. Its investigation had identified concerns after SSH access was authorized, particularly around Unix privileges and forwarding, and in some circumstances a session could do more than its configured local user should have been able to do. Tailscale did not confirm all eleven findings or their claimed impact, and it did not recommend that every customer disable Tailscale SSH. [2]
The public record consequently supports different levels of conclusion. Tailworm describes what its researcher reproduced under laboratory conditions; the cited source code supports several underlying mismatches, and Tailscale’s repair work addresses related execution and authorization paths. None of those sources establishes exploitation of the chains by an identified attacker in a production deployment.
3. Where Authorization Changed Meaning
Privileged services routinely act for less privileged callers, so the relevant question is whether each resulting operation remains within the caller’s authorization. In each case below, the decision was attached to one subject, resource, request, or moment, while the implementation used it for another. Naming both sides of that mismatch shows what additional authority the operation acquired and where it happened.
3.1 Principal: the SSH user became the root daemon
When Tailscale’s policy authorized an SSH connection as an ordinary Unix user, forwarding could still be performed by tailscaled running as root. The policy had selected user U as the subject of the SSH grant, but the kernel evaluated the socket operation against the daemon’s credentials. The mismatch is specific: a request justified by U’s limited access could connect to or create a socket using root’s filesystem authority unless the daemon independently kept the operation within U’s permissions.
3.2 Object: a permitted path or application became another destination
The Unix socket race concerned the identity of a filesystem object: a path accepted during validation could name another object when the operation occurred. At the network layer, the experimental conn25 application connector presented a related question about the destination of an authorized flow. An entitled user could specify a destination through the connector’s forwarding mechanism; according to Tailworm, that destination was not checked against the application’s sanctioned backends, while filtering took place before destination translation. In the researcher’s tests, traffic reached destinations outside the application’s authorized scope, including non-Tailnet internal services available from the connector’s network position. Direct access to other Tailnet devices, however, was constrained by WireGuard source-address and key validation. [1]
The two object mismatches occur at different points. For Unix sockets, validation accepted a path resolving to an allowed object, but a race could change what the kernel reached when the daemon performed the operation. For conn25, the grant concerned access to a named application, but the connector could translate traffic to a client-selected destination outside that application’s sanctioned backends. In each case, the resource used by the implementation differed from the resource the earlier decision had constrained.
3.3 Scope: one HTTP request borrowed another request’s capabilities
Tailscale Serve can pass a Tailscale-App-Capabilities header to a backend that uses the incoming request’s capabilities for its own authorization decisions. In the affected implementation, however, accepted capabilities were stored in a connection-scoped context even though HTTP/2 can process concurrent requests for different application mounts over the same TLS connection. Tailworm reported that a request to one mount could therefore be proxied with capabilities accepted for another. The capability belonged to the first request and its mount, but shared connection state let it travel with a different request to a backend that might trust the header. Tailscale’s merged PR #21931 describes this problem and moves capabilities into request-specific context. [3] Authentication, encryption, and HTTP/2 multiplexing could all function correctly while the application attached authorization state at the wrong scope.
3.4 Time: revoked access remained usable on an existing SSH connection
Tailscale’s October repair work identified a further issue in the lifetime of an SSH authorization. A client can open new shells, SFTP sessions, or forwarding channels over an established connection, but PR #21944 describes a previous validity check that canceled active session contexts without consistently closing the underlying connection. A user whose permission had been revoked could thus open new operations under the old policy action, local Unix user, or forwarding flags; forwarding-only connections escaped the earlier checks altogether. [4] The permission was valid when the connection began, but a later channel could still rely on that old decision after the policy had narrowed or revoked it. This connection-level revocation problem was described in the subsequent repair proposal, not among Tailworm’s original eleven findings.
Headscale had addressed a related distribution problem before the assessed version: its October 8 fix distinguished an absent SSH policy, which could leave old rules in place, from an explicitly empty policy that told the client to clear them. [5] The two defects were not the same, but together they show that revocation depends both on delivering the changed policy and on enforcing it against continuing connections.
3.5 The common failure
The corresponding decisions and operations differ in a specific way for each mechanism:
| Boundary | Authorization was for | Operation instead used |
|---|---|---|
| Principal | SSH forwarding by Unix user U | Root tailscaled credentials to open or create a socket |
| Object: Unix path | An allowed object resolved during validation | A different object reached when the kernel resolved the path later |
| Object: connector | Access to a named application | A client-selected destination outside that application’s backends |
| Scope | Capabilities accepted for one request and mount | A header on another concurrent HTTP/2 request |
| Time | A policy grant valid when the SSH connection began | A new channel opened after the grant was narrowed or revoked |
Across these mechanisms, the initial authorization could have been correct for its original principal, object, request, and time. The failure arose when that decision was reused after one of those conditions had changed.
4. Serve’s Independent Route to Local Administration
Tailworm’s seventh finding traced an independent route through Tailscale Serve, without Tailscale SSH. Serve can connect remote traffic to local backends through either an HTTP reverse proxy or raw TCP forwarding, including to Unix sockets. The HTTP proxy checked isTailscaledSocket() and rejected the daemon’s own management socket, while the raw TCP-to-Unix path lacked the corresponding restriction. With Serve configuration authority, a local operator could set a listener to target that socket; an ACL-permitted remote peer could then send requests through a connection opened by the privileged daemon. Tailworm reported successful laboratory LocalAPI reads and writes through this route. [1]
The prerequisite matters: a remote peer could use the forward only after an authorized operator configured it, and the report did not show arbitrary remote users creating that configuration. Once configured, however, the two forwarding paths treated the same protected service differently. The HTTP proxy rejected it, whereas raw TCP forwarding could use the daemon’s own authority to reach it, turning permitted network access into access to a local administrative interface.
5. Why the Earlier Fix Did Not Hold
5.1 Path validation protected a decision, not the operation
The June repair strengthened the check on a resolved pathname, but it still relied on that earlier decision to constrain a later operation by a privileged daemon. Tailworm’s race findings tested precisely that separation: a pathname could change after validation and before the kernel used it. The October changes instead moved the socket operation to a process with the SSH user’s credentials, making the kernel’s permission check apply at the point of use. The two approaches enforce different boundaries:
| Repair approach | Authority enforced at the socket operation | Remaining limit |
|---|---|---|
| June path validation | Root tailscaled acts after application code approves a resolved path | A later path change can put another object under root’s operation |
| October credentialed forwarding | A child with the selected Unix user’s credentials opens or creates the socket | The monitor and descriptor handoff still require their own checks |
5.2 The October repair changes the executing principal
Tailscale’s October implementation changed the executing principal. Merged PR #21941 added child processes able to perform forwarding operations under the authenticated local user’s credentials, but its own description said the main forwarding paths did not yet use them. Merged PR #21942 then routed those paths through the per-connection monitor: on Unix systems, user-credentialed children perform forwarded socket dials and binds instead of root tailscaled. [6] The daemon still checks the written pathname against an allowed set of directories as a coarse policy, while the kernel’s filesystem permissions govern whether the selected user can actually open or create the socket.
That difference also governs socket creation, ownership, and privileged TCP ports. The earlier design asked application code whether root could safely perform a requested operation for an ordinary user; the merged implementation has the user-credentialed child attempt it. A socket that user cannot open should then fail under the user’s credentials even while the surrounding daemon retains root privileges for its other duties. The merged code describes the repair’s design and tests; it does not by itself establish that every deployment has received a fixed release.
5.3 Privilege separation must cover the entire operation
Moving the socket operation into a user-credentialed child does not make the entire forwarding lifecycle unprivileged. A monitor may still create and supervise that child, pass file descriptors, relay data, and clean up, so each of those steps needs an appropriate boundary. Linux also distinguishes credentials associated with establishing a Unix socket connection from credentials that may accompany later messages. Passing a connected descriptor between processes can therefore matter to a service that inspects message credentials, although that observation alone does not demonstrate another exploitable Tailscale flaw.
To establish an additional impact, one would need an accessible service that bases authorization on the relevant message credentials and an unauthorized operation made possible by the descriptor transfer. The public material examined here does not establish that chain against the merged repair. User-credentialed socket opening can remove an important class of unauthorized connections, while the authority retained by the monitor and other forwarding components still warrants examination.
5.4 The repair also addresses authorization after connection establishment
PR #21944 addresses the lifetime of the SSH authorization. It proposes reevaluating changes at the connection level so that new sessions and forwarding operations reflect current policy rather than only the decision made when the transport was established. An administrator might revoke a local user, remove forwarding permission, shorten a session’s duration, or require recording while the connection remains alive; the proposed repair would make such changes govern later operations. [4] Taken together, the merged forwarding changes and the still-open revocation proposal address three parts of the correspondence between a grant and what the system eventually does:
- The executing process should not possess greater authority than the operation requires.
- The object being accessed must remain within the authorized scope.
- New operations should reflect authorization conditions still applicable when they execute.
5.5 Repair status on October 26
The distinction between development work and released protection remains important.
| Repair | Status on October 26 |
|---|---|
| PR #21924: reject a root-execution fallback for non-root SSH sessions | Merged |
| PR #21931: isolate Serve app capabilities by request | Merged |
| PR #21941: add credentialed forwarding children and monitor operations | Merged |
| PR #21942: route forwarding through the privilege-separated operations | Merged |
| PR #21944: enforce SSH policy revocation and narrowing at connection level | Open |
The latest stable Tailscale client version checked for this analysis was v1.104.2, released on October 21, and it did not contain a published complete correction for Tailworm’s findings. [7] The table records repository status as checked on October 26: merging #21942 changed the code on main, but does not show that the change had shipped to users; #21944 remained a proposal rather than deployed protection.
6. What the Evidence Establishes
The strongest evidence for the reported behavior remains the researcher’s laboratory reproductions: privileged Unix socket access, Docker and systemd operations, LocalAPI traffic interception, and credential-based network enrollment. The report also records prerequisites and negative results, including cases that required a successful pathname race, an available service, permission to forward, or particular registration settings. Public source code and security bulletins support several underlying authorization mismatches; the June bulletin describes privileged socket access through the root daemon, and the merged October forwarding changes move socket operations into user-credentialed children.
Tailscale separately acknowledged that its investigation had found concerns involving Unix privileges and SSH forwarding after authorized connections, while it was still validating the full set of eleven reported findings. The connection-level revocation issue discussed here came from a subsequent Tailscale repair proposal, and headscale’s empty-policy defect had already been repaired before the Tailworm assessment. Keeping these sources and dates distinct prevents laboratory results, vendor acknowledgment, historical fixes, and proposed repairs from being treated as equivalent confirmation of every reported attack.
6.1 The attack conditions are material
The principal SSH forwarding findings require Tailscale SSH to be enabled, an applicable policy to admit the peer, and the relevant forwarding permission. The pathname-race variants additionally require an unprivileged process running in that SSH session on the destination to change the path between validation and use. Conventional OpenSSH carried over an ordinary Tailscale network connection uses a different server implementation and does not automatically expose this path. The report examined both Tailscale and headscale configurations; in headscale v0.29.5, compiled SSH accept actions allowed local and remote forwarding, although exposure still depends on which users and devices can establish those sessions.
The other paths have separate requirements. The connector finding needs the experimental feature and an application entitlement; the Serve management-interface route needs local configuration authority plus a peer permitted to reach the listener. The HTTP/2 capability issue needs concurrent requests with differing capabilities and a backend that trusts the forwarded header, while network enrollment or identity reuse needs usable credentials or device state and permissive enough identity controls. Those conditions define the population and consequences of each finding rather than merely qualifying its severity.
6.2 Scope of compromise is not unlimited
The report describes automated movement only among devices that existing SSH policies allowed the attacker to reach, not universal access to every host in a deployment. Network policy still governs source-destination relationships, a host may lack the relevant socket or service, and operating-system confinement can limit what a privileged API permits. Hardware-backed credentials and device controls may also affect persistence after host compromise.
Tailscale’s interim guidance was to review SSH access policies, restrict unnecessary access, and disable forwarding where it was not needed. The daemon’s TS_SSH_DISABLE_FORWARDING=1 setting can disable forwarding while retaining Tailscale SSH when applied to its service environment and followed by a restart. [2][9] SSH check mode adds authentication before access, but it does not change the privileges used after a connection is established. These measures can reduce exposure to particular paths, while the receiving service still needs to enforce the authorization boundaries around the operations it performs.
7. Conclusion
In the principal Tailworm SSH findings, the network could authenticate the peer, policy could authorize the source device, and the destination could select the intended Unix account, yet the forwarding operation could still run with the root daemon’s authority. Path validation might approve one object before the kernel reached another; under additional conditions, local management traffic could expose material used to establish network identity. The connector, Serve, and HTTP/2 findings involved different mechanisms, while the later SSH revocation proposal concerned the lifetime of a grant. Together they show several ways that an accepted request can acquire a different principal, destination, scope, or effective permission as it moves through the system.
The repair history makes the principal boundary especially clear. June’s change strengthened validation of a requested Unix socket path before the privileged daemon acted, whereas October’s merged code routes the socket operation through a child bearing the authenticated Unix user’s credentials. That shift recognizes that permission to reach a server through the network does not itself authorize a local system call as root. Tailworm’s case-specific lesson lies in the translation between those authorities: an authenticated connection could cause an operation whose effective privileges had never been granted to the user who requested it.
The authentication was valid. The authorization did not survive the translation.
References
Original Assessment and Vendor Response
[1] Erica Windisch, Cyberdione Labs. Tailworm — Security Assessment Report: Tailscale v1.104.2 and headscale v0.29.5. October 25, 2026. Original findings, laboratory reproductions, negative results, and reported attack chains.
[2] Mike Shaver, VP of Engineering, Tailscale. Recent Tailscale Vulnerability Reports. October 25, 2026. Vendor response and interim mitigations.
Security History and Implementation
[3] Tailscale. PR #21931 — Fix Serve App Capabilities Leaking Across Mounts. Merged October 25, 2026.
[4] Tailscale. PR #21944 — Enforce Policy Changes, Rule Expiry, and Login Grace at the Connection Level. Open as of October 26, 2026.
[5] headscale. PR #3517 — Check SSHPolicy Nil vs Empty Against Captures. Merged October 8, 2026.
[6] Tailscale. PR #21941 — Add User-Credential Forwarding Children and Monitor Operations; PR #21942 — Route SSH Forwarding Through the Privileged Monitor. Both merged October 26, 2026.
[7] Tailscale. Client Changelog. Release status and v1.104.2 release notes, October 21, 2026.
[8] Tailscale. Security Bulletins. Particularly TS-2026-004, TS-2026-005, TS-2026-006, and TS-2026-007.
[9] Tailscale. ssh/tailssh/tailssh.go, v1.104.2. SSH authorization and forwarding handlers.
[10] Tailscale. ipn/ipnlocal/serve.go, v1.104.2. Serve request handling, proxy routing, and Unix socket backends.
[11] headscale. hscontrol/policy/v2/filter.go, v0.29.5. SSH accept actions and forwarding permissions.
Protocol and Authorization References
[12] IETF. RFC 4254 — The Secure Shell Connection Protocol. January 2006.
[13] IETF. RFC 9113 — HTTP/2. June 2022.
[14] Linux man-pages project. unix(7) — Unix Domain Sockets. Unix socket permissions, peer credentials, and ancillary data.
[15] NIST. SP 800-207 — Zero Trust Architecture. August 2020.
Evidentiary Note
This article distinguishes researcher-reported laboratory results, publicly inspectable implementation behavior, vendor acknowledgments, merged source changes, and proposals still under review. Not all Tailworm findings had been independently confirmed by Tailscale as of October 26, 2026, and the sources examined do not establish an identified production compromise resulting from the reported attack chains.
The comparison of these findings through the movement of authority is Zerot Security’s analytical interpretation. It does not claim that all findings share a single code-level root cause or have equivalent exploitation requirements.