Security Assessment Report – Tailscale v1.104.2 and headscale v0.29.5

Updated 2026-10-27. The researchers thank Tailscale Inc. for a rapid and substantive response to this report. The fixes below have landed in the project's public git repositories (tailscale/tailscale and tailscale/gliderssh, branch main). None had shipped in a numbered release at the time of writing.

Tailscale has published an SSH investigation and remediation update describing its assessment of the findings — most concerning escalation beyond the permissions of the configured local user — and targeting a patched client release by the end of 2026-10-27, subject to testing. The company also responded publicly on Reddit — Mike Shaver, VP of Engineering, acknowledging the report and describing fixes in progress — and the report received press coverage, including The Hacker News (2026-10-25).

Findings 1–3 (privileged unix-socket forwarding): SSH forwarding was re-architected onto a per-connection monitor with unprivileged, credentialed children — dial, bind, and unlink for forwarded sockets now run with the authenticated session user's credentials, and payload peer credentials identify that user rather than the root daemon (PRs #21941–#21944, #21959, #21963; internal tracking corp#50380). The lexical path re-validation that finding 3's race defeated was removed in favor of the kernel's discretionary access controls as the boundary — the privilege-drop fix family this report recommended.

Finding 5 (session memory exhaustion): fixed in gliderssh — window-change sends are non-blocking and keep-latest, and environment churn is bounded (landed via tailscale PRs #21945 and #21953). The upstream commit message publicly credits this audit's measurements, which the researchers appreciate.

Finding 7 (serve --tcp to the localapi socket): refused at both configuration time and per dial (#21966, merged 2026-10-27).

Finding 11 (cross-mount capability bleed): fixed — per-request capability handling instead of the shared connection context (#21931).

Finding 8 (serve unix-socket guard TOCTOU): the guard now rechecks on every serve unix dial, including the web reverse-proxy path; on Linux ≥ 5.6 the dialed socket inode is pinned with openat2(2) so a later path swap cannot retarget the connection, with a post-connect peer re-check on all platforms (open PRs #21992 / #21999 at the time of writing).

Finding 6, client relay component (C3): the non-101 response body read is now bounded (#21980, merged 2026-10-27).

The broader community has responded as well; in particular, a pending rework of the headscale registration cache (juanfont/headscale PR #3586) adopts admission control over eviction and cites this report.

Because none of these fixes had reached a numbered release at the time of writing, the interim mitigations and detection guidance in this report remain the operative guidance for deployed versions (tailscale ≤ v1.104.2, headscale ≤ v0.29.6).

The design choices of the open source tailscale and headscale software have created an environment ripe for risk, while marketing security as its design and purpose. Choices have been made to move away from security-in-depth, removing layers of authentication, and replacing daemons such as OpenSSH which employ privilege-separation with a highly-privileged process. Other findings include broader-than-advertised network security boundaries, which seems to be legitimate bugs, but the missing security and isolation is precisely what users are advertised by these tools.

Regarding disclosure timelines, it is of the researcher's opinion that infrastructure is vulnerable today. This report strictly audits the open source software provided to users under no condition of warranty per the BSD-3 license. As such, the researchers, and the users, are effectively developers of said software per its open source nature.

The software in question has a corporate sponsor. Tailscale Inc., is a for-profit organization employing developers to build secure software. The researchers are not associated with the Tailscale corporation, are not employed by said organization, and have not been contracted or paid to conduct or report this research. All research was performed against open source software on the systems and devices of the researchers.

It is the opinion of the researchers that rapid awareness of these flaws will expediate remediation across impacted devices. These vulnerabilities were not introduced by the researchers, but were discovered, and discovered with low effort.

-- Erica Windisch, Cyberdione Labs Corporation

Testing window: 2026-10-22 to 2026-10-24. All findings were verified by reproduction in a lab environment on unmodified, released software (tailscale v1.104.2, headscale v0.29.5). Lab and organizational identifiers are redacted. Finding identifiers: T1–T3, C1–C4, and F-1–F-5 are internal audit labels, retained so the reproduction kits can be cross-referenced.

What was audited. Tailscale client agent v1.104.2 (tailscaled, its embedded Tailscale SSH server, its serve/funnel feature, and its DERP relay client), the headscale v0.29.5 self-hosted control server, the gliderssh library both build on, and the experimental conn25 app-connector feature. Findings fall into five classes; each names the component it affects.

How initial intrusion plausibly occurs. Class 1 assumes the attacker already holds a foothold on one device — which happens the ordinary ways: an exploited web application (a vulnerable PHP page or CMS plugin), a malicious build dependency (npm/PyPI package, Docker base image, GitHub Action), a phishing implant, a supply-chain compromise, or stolen identity credentials. Tailscale does not create the foothold; the finding is that the mesh converts one ordinary foothold into fleet-wide privileged access at machine speed, because inter-device paths are granted by policy that assumes trusted endpoints while the agent's privileged operations are reachable from unprivileged sessions.

Practical risk in default deployments. With Tailscale SSH enabled (opt-in per node, often fleet-wide): one compromised account reaches root on other servers (class 1) and, in default (Tailnet-Lock-disabled) configurations, joins an attacker machine as a legitimate tagged server with routes auto-approved. With app connectors configured: policy-invisible reach into cloud credentials and Kubernetes services (class 2). With a self-hosted, internet-reachable headscale: unauthenticated crash loop and onboarding lockout (class 3). Any client pointed at a hostile relay: agent exhaustion (class 4). Any node with the serve forward configured: remote admin-API exposure (class 5).

Wormability. Measured in a lab: policy-granted Tailscale SSH plus class-1 findings allow automated spread to every device the policy permits — no passwords, no stolen keys, no user interaction, under a second per hop. Two structural limits held: per-pair access grants bound the spread (the single control that stopped it), and hardware-bound device credentials (TPM/Secure Enclave) prevent the identity theft that makes compromise persist. All other controls changed visibility speed, not spread.

Mitigations, in order of effect. (1) Per-pair SSH grants — never identity-wide or tag-wide accept rules. (2) Disable SSH forwarding: on SaaS, set the per-rule forwarding fields to false; on headscale v0.29.5 forwarding cannot be disabled — it is granted unconditionally on every accepted session, so until fixed, treat every headscale SSH grant as root-equivalent. Restricting SSH to non-privileged accounts is defense-in-depth only — it does not mitigate these findings, which operate from fully unprivileged accounts. (3) Node-key expiry on server fleets; TPM/Secure-Enclave-bound agent state. (4) Keep security telemetry on infrastructure a compromised server cannot reach — self-tested, with coverage reporting. (5) Restrict connector entitlements; destination allowlists or Kubernetes default-deny egress on the connector namespace. (6) Incident response built on device deletion at the control plane: a node's keys live in a file an attacker with root can copy, and reimaging the host does not revoke an already-stolen copy — only control-plane deletion (or key expiry) does. (7) Self-hosted control planes: memory limits, restart supervision, registration-rate throttling. Vendor fixes are small and precedented (OpenSSH, Dropbear); the above protects you before and after they ship.

Tailscale SSH performs no user-level authentication. The SSH protocol's authentication phase completes with method none: the WireGuard layer has already cryptographically identified the device, and that device identity — not a password, key pair, or user credential — is what the SSH policy evaluates. Authorization is therefore exactly one policy rule (source device to target device, with target accounts named in the rule), and a session established under this model carries the forwarding capabilities of findings 1–3 for its lifetime. Two consequences for threat modeling: an attacker needs no credential material beyond a foothold on any policy-permitted device; and device compromise is user-agnostic — the malware of any user on an entitled device speaks with the device's full authorization. This model is also what makes the wormability measured below possible: propagation required no passwords and no stolen keys.

Two design properties give an attacker complete targeting knowledge at zero risk of detection:

Together these mean an attacker's targeting is not discovery-limited: the mesh hands them the target list, and a quiet sweep hands them the policy map. Findings 1–4 then convert that map into access.

Tailscale's app-connector facility lets an organization route traffic to external SaaS services (or internal applications) through designated gateway devices, so that access to those services appears to come from the organization's addresses and can be governed in one place. Administrators designate connector devices, define the apps (named service definitions, typically domains), and grant selected devices an entitlement to use a given app through the connector. In intended operation, a client resolves an app's domain, is directed to a connector, and the connector forwards the flow to the app's real destination.

conn25 is a redesigned connector mechanism (present but experimental in v1.104.2) built on per-flow mappings: an entitled client registers a mapping with the connector over the tailnet's peer API — "when I send traffic to transit address X, translate it to real destination Y" — and the connector installs packet-filter rules and performs the translation in its data path. Two implementation properties matter to finding 4: the client-supplied destination Y is validated only for address family (never against the app's configured destinations), and the connector's ingress rules accept transit-pool traffic before the tailnet's access-control evaluation runs. In production the mechanism is deployed principally through the Kubernetes operator, which runs connector pods with full container privileges positioned across the cluster's service and pod networks.

For threat modeling: the entitlement an administrator grants is "this device may use app X through the connector" — but nothing in the implementation binds translated destinations to app X. The reader should assess finding 4 with that gap in mind: the feature delegates routing decisions to the client while the authorization decision was made about the app.

Affected component / version: Tailscale SSH server in tailscaled v1.104.2 (gliderssh streamlocal local forwarding). Prerequisites: an SSH policy rule accepting the attacker's connection to the target, with local forwarding permitted. No sudo, docker-group membership, or victim-side daemon access is required.

An authenticated peer with an SSH policy rule permitting local forwarding can cause the root-privileged tailscaled process to connect, on the peer's behalf, to unix sockets restricted to root:

ssh -fNT -L /tmp/rela