Is your tailnet exposed to Tailworm?

• TW-01HighTailscale SSHNo fix published · checked 2026-10-29

  Tailscale SSH: local Unix-socket forwarding (ssh -L) dials as root

  If Tailscale SSH is on for a server and your policy lets another device SSH into it, anyone who takes over that other device can reach root-only services on the server through the SSH session. If Tailscale SSH is off everywhere, this does not apply to you.

• TW-02HighTailscale SSHNo fix published · checked 2026-10-29

  Tailscale SSH: remote Unix-socket forwarding (ssh -R) replaces root-owned sockets

  Same precondition as finding 1: Tailscale SSH on, plus a policy rule that lets a peer in. An attacker on that peer can impersonate root services on the server. Off everywhere means not affected.

• TW-03HighTailscale SSHNo fix published · checked 2026-10-29

  Tailscale SSH: a race (TOCTOU) defeats the socket-path allowlist

  This is why "only allow sockets in the user's own folders" does not protect you. Same precondition as findings 1 and 2. If an attacker gets this far on a tailnet without Tailnet Lock, the report shows they can add their own machine to your tailnet.

• TW-04HighApp connectorsNo fix published · checked 2026-10-29

  conn25 app connectors: a user entitlement allows any egress destination

  Only matters if you use the experimental conn25 app-connector feature. Classic app connectors are not this finding. If you do use conn25, every user you gave an app to can reach far more than that app.

• TW-05HighTailscale SSHNo fix published · checked 2026-10-29

  Tailscale SSH: session churn pins memory in the root daemon (OOM loop)

  Anyone your policy lets SSH into a node can knock that node's Tailscale offline. The report found no Tailscale-side workaround: the only levers are SSH off or fewer SSH rules.

• TW-06Medium-HighheadscaleNo fix published · checked 2026-10-29

  headscale: unauthenticated memory exhaustion and onboarding lockout; DERP client response bomb

  Only matters if you run your own headscale control server. On Tailscale's hosted control plane the headscale parts do not apply. The relay part (C3) needs your clients to be pointed at a relay an attacker controls.

• TW-07HighServe and FunnelNo fix published · checked 2026-10-29

  tailscale serve: a TCP forward to the tailscaled socket exposes the admin API

  Check every node that uses tailscale serve: a TCP forward to a Unix socket, and above all to tailscaled's own socket, must not exist. If you never forward to a Unix socket, this does not apply.

• TW-08MediumServe and FunnelNo fix published · checked 2026-10-29

  tailscale serve: the tailscaled-socket guard is checked only at config time

  If a serve backend on a node is a Unix socket in a folder other users can write to, that user can redirect it. Root-owned folders are safe; no Unix backends means not affected.

• TW-09MediumServe and FunnelNo fix published · checked 2026-10-29

  Funnel: the funnel node attribute is enforced only by the CLI

  A threat-model note: the "funnel" permission in your policy is checked by the tailscale command, not by the daemon. Treat any node with funnel on as internet-facing and know why it is on.

• TW-10NoteServe and FunnelNo fix published · checked 2026-10-29

  TS_SERVE_ALLOW_ALL_INTERFACES exposes serve outside the tunnel

  Off by default and set mainly by the Kubernetes operator's experimental ingress. If you never set it, this does not apply.

• TW-11MediumServe and FunnelNo fix published · checked 2026-10-29

  tailscale serve over HTTP/2: app-capability headers can bleed between mounts

  Only matters if one serve host:port has several paths that pass different Tailscale app capabilities to your app, and your app trusts that header for authorization.

As of 2026-10-25 Tailscale has published no security bulletin, release note or changelog entry that acknowledges or fixes the Tailworm findings. The latest client is 1.104.2, the version the report tested. Earlier bulletins TS-2026-004 and TS-2026-005 fixed related issues in 1.98; they do not reference Tailworm.

One POSIX shell script. It runs read-only tailscale commands on the node you choose, prints JSON and sends nothing unless you add --submit.

curl -fsS https://tailnet.geoa.io/cli/geoa-tailnet.sh | sh -s -- --json

curl -fsS https://tailnet.geoa.io/cli/geoa-tailnet.sh | sh -s -- --submit https://tailnet.geoa.io/api/node-report

Read it first: /cli/geoa-tailnet.sh. It never reads keys or debug output and never changes a setting. Paste its JSON into the node report box above.

The same audit as an MCP server: ask Claude Code, Cursor or Codex to check your tailnet and explain a finding with its source line.

claude mcp add --transport http geoa-tailnet https://tailnet.geoa.io/mcp

bash <(curl -s https://tailnet.geoa.io/plugin/install.sh)

{
  "mcpServers": {
    "geoa-tailnet": {
      "url": "https://tailnet.geoa.io/mcp"
    }
  }
}

[mcp_servers.geoa-tailnet]
url = "https://tailnet.geoa.io/mcp"

Set up the Geoa Tailnet Guard MCP server for me: name geoa-tailnet, transport Streamable HTTP, URL https://tailnet.geoa.io/mcp, no login. Confirm it lists the tools list_findings, explain_finding, audit_status_json, audit_policy, audit_node_report, propose_fix, patch_status, watch_tailnet, then explain finding TW-01 with its source citation.