Is Tailscale Safe? Six Checks to Run on Your Own Tailnet Today

Whether Tailscale is safe for you depends on which optional features you switched on. The Tailworm report, made public in late October 2026, makes this the week to check. Our news post on the Tailworm report and what Tailscale has said so far holds the story. This post is the checklist.

Last checked: 28 October 2026. We update this page when Tailscale publishes a bulletin or a fix.

Every command and policy snippet below comes from Tailscale’s own documentation, the headscale documentation or the report’s mitigation section. Where the documentation does not cover something, we say so instead of guessing.

What Does the Evidence on Tailscale Security Say?

Researcher Erica Windisch of Cyberdione Labs published 11 findings in Tailscale and headscale. She tested tailscale 1.104.2 and headscale 0.29.5 in a lab. Tailscale’s security bulletins page lists four bulletins, TS-2026-014 to TS-2026-017, dated 26 October 2026, and names version 1.104.4 as the fixed version.

Version 1.104.4 appeared on GitHub on 28 October 2026. Tailscale’s blog post of that day says an attacker needs an existing foothold on an authorized device, and it calls the pattern lateral movement within what the policy file allows. It says three of the five Serve and Funnel findings were bugs fixed in 1.104.4 and two work as designed. The connector finding concerns Conn25, which is not released.

Question	What the evidence shows	Status on 28 Oct 2026
Are the findings real?	The report gives lab results on unmodified releases, and Tailscale’s bulletins cover most of them	Confirmed by Tailscale where it published a bulletin
Is there a fix?	Tailscale 1.104.4 fixes the issues in bulletins TS-2026-014 to 017	Fixed in 1.104.4; Conn25 and the headscale side of finding 6 are still open
Can it be used from the internet?	The SSH chain starts from one approved device that is already hacked; the headscale finding needs only internet reach to the server	SSH: not without a foothold, as Tailscale also says. Self-hosted headscale: yes, for denial of service
Is my default install affected?	SSH needs a per-device opt in and Funnel is off by default	Mostly only if you turned the features on; the relay-client finding applies to every agent but needs a hostile relay. The researchers list the client-side fix in 1.104.4

The SSH chain starts with a foothold, not with a break in from outside. The report says an attacker who holds one device can spread to every device your policy allows, which is lateral movement inside the tailnet. The headscale finding is different, because the report says it needs only network access to the control server.

What stays true: both areas had fixes before. Bulletins TS-2026-004 (SSH) and TS-2026-005 (Serve), both dated 3 June 2026, covered earlier Unix socket flaws in these areas and name version 1.98.9 as the fix. Tailscale’s changelog lists the Serve fix in 1.98.9 (14 July 2026) and the SSH fix in 1.98.10 (28 July 2026). Your exposure depends on your configuration, so the audit starts there.

1. Find Out Which Features Are On

Update first. Tailscale’s bulletins name 1.104.4 as the fixed version, so run tailscale version on each device and update any that run Tailscale SSH or serve. If you cannot update yet, Tailscale says setting TS_SSH_DISABLE_FORWARDING=1 in the tailscaled service environment and restarting the service turns off SSH forwarding without turning off Tailscale SSH.

We go from the most powerful feature, SSH, to the rarest. Run these on each server and workstation that runs Tailscale. The CLI reference says tailscale get shows the settings that tailscale set changes, under the same flag names.

tailscale version
tailscale get ssh
tailscale get advertise-connector
tailscale serve status
tailscale funnel status

A bad result is any device where SSH or the connector role is on without a reason. Another is any server that serve status lists and you do not recognise. A third is any device on a version older than 1.104.4.

Treat anything that funnel status lists as a risk, because Funnel makes a port public. Give each one a named owner. Write the results down. This list is your attack surface inside the tailnet.

2. Read Your SSH Rules for Risky Patterns

Open the access controls page of the admin console and find the ssh section. The Tailscale SSH documentation lists the broadest allowed rule. If yours looks like this, it is the pattern to remove:

{
  "action": "accept",
  "src": ["autogroup:member"],
  "dst": ["tag:prod"],
  "users": ["root", "autogroup:nonroot"]
}

The report advises per-pair rules, from one named source to one named destination, and no privileged target accounts. Here is a narrow rule built from the documented fields:

{
  "action": "check",
  "checkPeriod": "1h",
  "src": ["alice@example.com"],
  "dst": ["tag:prod"],
  "users": ["ubuntu"]
}

Two warnings from the documentation. If you change dst from autogroup:self to a tag, replace autogroup:nonroot too, or anyone in src can sign in as any non-root user. A new tailnet’s default rule lets people reach their own devices in check mode.

The report also says check mode does not limit forwarding inside a session that was already approved. It points to per-rule forwarding flags on Tailscale’s service. Tailscale’s SSH documentation and policy file reference do not name those fields, so this post leaves them out. For forwarding, bulletin TS-2026-014 documents the TS_SSH_DISABLE_FORWARDING=1 setting instead.

Lock the rules in with the documented sshTests section. Tailscale rejects a policy change that breaks a test.

"sshTests": [
  {
    "src": "dave@example.com",
    "dst": ["example-host-1"],
    "accept": ["dave"],
    "check": ["admin"],
    "deny": ["root"]
  }
]

To switch SSH off on a device that does not need it, run tailscale set --ssh=false. The documentation warns that you may lose access, so confirm another way in first.

3. Check Serve, Funnel and the Operator

The Tailscale documentation says tailscale serve status lists the servers running on the device. The report asks you to look for TCP forwards that point at Unix sockets, written as serve --tcp <port> unix:<path>. Remove any that target the Tailscale agent’s own socket or a privileged path. Bulletin TS-2026-005 uses /var/run/docker.sock as its example, and TS-2026-016 of 26 October fixed a further serve Unix backend issue in 1.104.4.

To clear the configuration, the serve reference gives tailscale serve reset, and the funnel equivalent is tailscale funnel reset. Also run tailscale get operator. The bulletin says a non-root operator could write serve configuration.

For Funnel, the documentation says a funnel node attribute decides who may use it. By default it covers every member:

"nodeAttrs": [
  {
    "target": ["autogroup:member"],
    "attr":   ["funnel"],
  },
],

Narrow the target to the people who need it. The report says the funnel attribute is enforced only by the command-line tool (finding 9), which Tailscale calls behavior that works as designed. So also check funnel status on each node, and check that the environment variable TS_SERVE_ALLOW_ALL_INTERFACES is not set. The report says it exposes serve listeners outside the tunnel, and Tailscale calls it an opt-in setting meant to do that.

4. Review App Connectors

List your app connectors in the admin console, and check each device with tailscale get advertise-connector. The app connector documentation says additions and removals appear in the configuration audit logs. The report rates the experimental connector class High. Tailscale says that finding concerns Conn25, the unreleased next generation, and that the stable app connectors available today are not affected.

Two actions follow from the report. Remove the connector capability from devices that do not need it, and enforce a destination allowlist on the connector host. In Kubernetes, use a default-deny egress policy for the connector namespace. A bad result is a connector host that can still reach cloud metadata or internal ranges you never meant to expose.

5. Give Identities a Clock, and Harden headscale

The key expiry documentation says new domains default to 180 days, but tagged devices start with expiry disabled. Servers are usually tagged, so they often never expire. The report asks for expiry on server fleets. Plan the sign-in, because an expired app connector stops carrying traffic.

Next, run tailscale lock status on each node. The Tailnet Lock documentation says every node should report the same signing keys.

The report says tailnets without the lock accepted a rogue node enrolled with a stolen key. Enabling it creates disablement secrets. If you lose them and gave none to Tailscale support, the tailnet cannot be recovered.

If you run headscale, update to 0.29.6 and follow the upgrade guide: back up the database first. The notes do not mention the report. It is still the newest headscale release on 28 October 2026.

They do carry security updates for a compromised certificate chain and for HTTP/2 denial of service in dependencies. The report says headscale 0.29.5 grants forwarding on every accepted SSH session, so treat each headscale SSH rule as root-equivalent. Set a systemd MemoryMax, supervise restarts, put a rate-limiting proxy in front and keep the server off the open internet.

6. Decide What to Monitor

Patching is only part of it, so watch for abuse. The checklist below is the minimum.

• Policy changesRead the configuration audit log, which keeps 90 days and shows a full diff of each policy change.
• New nodes and connectorsLook for unknown devices and for connectors added or removed.
• Sign-in promptsTreat a Tailscale sign-in prompt nobody asked for as an incident.
• Serve and funnelSave the status output each week and compare it.
• Logs off the boxKeep security logs where a hacked server cannot reach them.

If a device may be compromised, delete it in the admin console. The report says reimaging does not revoke copied keys. Rotate any auth keys that device could reach. Then run tailscale version --upstream after each Tailscale release, and fold the result into your vulnerability management routine.