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: 26 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 has not confirmed the findings, and as of 26 October 2026 its security bulletins list nothing for them.
Tailscale’s public code repository does show movement. Between 23 and 26 October it received three changes in the areas the report covers.
- A change that routes SSH forwarding through a privileged monitor.
- A serve fix for capabilities leaking across mounts.
- A library update for resource exhaustion.
None is in a release, and Tailscale has not linked them to the report. A merged commit is not a shipped fix.
| Question | What the evidence shows | Status on 26 Oct 2026 |
|---|---|---|
| Are the findings real? | The report gives lab results on unmodified releases | Not confirmed by Tailscale |
| Is there a fix? | Three commits in the areas the report covers sit in the public repository | None in a release or bulletin |
| 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. 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 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
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 statusA 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.
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": ["[email protected]"],
"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. Watch the bulletins page for guidance.
Lock the rules in with the documented sshTests section. Tailscale rejects a policy change that breaks a test.
"sshTests": [
{
"src": "[email protected]",
"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.
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), so also check funnel status on each node. Finally, check that the environment variable TS_SERVE_ALLOW_ALL_INTERFACES is not set. The report says it exposes serve listeners outside the tunnel.
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.
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.
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
You cannot patch what is not released, 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.