A critical Tailscale SSH vulnerability (TS-2026-009) lets any user with SSH access to a Linux node escalate to root by connecting with a username starting with a dash. The flaw was disclosed today alongside five other Tailscale SSH vulnerabilities in version 1.98.9. If you use Tailscale SSH with autogroup:nonroot ACLs, you need to update immediately.

Vulnerability Details (CVE Pending)

Identifier: TS-2026-009 (CVE assignment pending) CVSS Score: Not yet assigned -- expected 8.8-9.8 (Privilege Escalation) Affected Versions: Tailscale < 1.98.9 on Linux Fixed Version: 1.98.9 (released July 14, 2026) Attack Vector: Local/Network (requires valid SSH access to a tailnet node) Impact: Full root shell access in violation of ACL policy

Root Cause: getent Argument Injection via Leading Dash

Tailscale SSH resolves usernames to system accounts by calling getent passwd <username> on the target host. The vulnerability stems from how Linux getent handles arguments that begin with a hyphen.

When a user connects via Tailscale SSH with the username -i, the following occurs:

1. Tailscale passes -i directly to getent passwd -i
2. The getent utility interprets -i as the flag --no-idn (disable Internationalized Domain Names)
3. With this flag, getent prints the entire /etc/passwd file starting from the first entry
4. The first entry in /etc/passwd is almost always root
5. Tailscale reads this output, sees root as the resolved user, and spawns a root shell

This bypasses Tailscale ACLs entirely -- even if your policy restricts a user to autogroup:nonroot, the -i username tricks the resolver into returning root.

The fix in 1.98.9 is straightforward: Tailscale SSH now rejects any username that begins with a - character before passing it to getent.

Impact Assessment: What's at Risk

Who Is Affected

You are vulnerable if all of these are true:

• You run Tailscale on Linux hosts
• You use Tailscale SSH for remote access
• Your ACLs rely on autogroup:nonroot to prevent root access
• You have not upgraded to 1.98.9 or later

What an Attacker Gains

With a successful exploit, an attacker obtains:

• Full root shell on the target Linux host
• Ability to read/modify any file, install kernel modules, modify firewall rules
• Persistence via SSH keys, cron jobs, or systemd services
• Lateral movement to other tailnet nodes (if SSH keys or credentials are present)
• Access to Tailscale's local API (/localapi/v0/) for tailnet manipulation

Real-World Exposure

Tailscale SSH is widely used for:

• Developer access to production/staging servers
• CI/CD runners connecting to build hosts
• Homelab and self-hosted infrastructure management
• Kubernetes node debugging via tailscale ssh

Any of these scenarios with autogroup:nonroot ACLs are at risk until patched.

Affected Systems: Who Needs to Act

Environment	Affected?	Notes
Linux servers with Tailscale SSH	YES	Primary target
macOS/Windows Tailscale SSH	No	getent behavior differs
Tailscale SSH with autogroup:root allowed	YES	ACL bypass still works, but root was already permitted
Tailscale SSH without autogroup:nonroot	YES	Escalation to root still possible
Containerized tailscaled (Docker/K8s)	YES	If running on Linux host
Tailscale Funnel/Serve only (no SSH)	No	Different vulns (TS-2026-005/007/008)

Check your version now:

Mitigation & Patching: Step-by-Step Fix

Immediate Action (Do This First)

Upgrade to 1.98.9 or later on ALL Linux nodes running tailscaled:

Verify the fix:

ACL Hardening (Defense in Depth)

Even after patching, review your ACLs:

Key principles:

• Use explicit autogroup:nonroot for developer access
• Deny autogroup:root for all non-admin groups
• Audit ssh grants in your policy regularly

Container/Kubernetes Specifics

If you run Tailscale in containers:

For Kubernetes Operator:

Detection: How to Tell If You Were Compromised

Check Authentication Logs

Look for SSH sessions with usernames starting with -:

Audit Tailscale SSH Sessions

Tailscale logs SSH connections to its own audit log:

Check for Unexpected Root Sessions

Indicators of Compromise

Signal	Likelihood
SSH login with username -i, -u, --help, etc.	Definite exploit attempt
New root SSH keys appearing	High confidence
Unexpected sudo usage by non-admin users	Medium
Modified /etc/passwd, /etc/shadow, /etc/sudoers	High
New systemd services or cron jobs as root	High

Frequently Asked Questions

Does this affect Tailscale on macOS or Windows?

No. The vulnerability is specific to Linux getent argument parsing. macOS and Windows use different user resolution mechanisms.

Is there a CVE number yet?

As of publication, CVE assignment is pending. Track Tailscale's security bulletins for updates.

Can this be exploited remotely without tailnet access?

No. The attacker must already have:

1. A valid tailnet identity (authenticated to your tailnet)
2. SSH access to at least one Linux node (granted via ACLs) This is a privilege escalation within the tailnet, not a remote unauthenticated RCE.

What if I don't use autogroup:nonroot?

You are still vulnerable. Any user with SSH access can escalate to root. The autogroup:nonroot restriction is what makes this a policy bypass -- without it, root access via SSH might be intended behavior for some users.

Are there other SSH-related vulns in this release?

Yes. TS-2026-009 is one of six Tailscale SSH vulnerabilities fixed in 1.98.9:

• TS-2026-004: Unix socket forwarding symlink bypass
• TS-2026-005: Non-root operator proxying privileged Unix sockets
• TS-2026-006: Numeric UID 0 bypasses root restrictions
• TS-2026-007: Services loopback port exposure
• TS-2026-008: CPU pinning DoS via malformed HTTP paths
• TS-2026-009: Leading-dash username to root (this article)

All are fixed in 1.98.9. Upgrade once, fix all six.

How do I know if my ACLs use autogroup:nonroot?

Check your tailnet policy file in the admin console (Settings -> Access Controls) or via CLI:

Search for autogroup:nonroot in the output.

Key Takeaways

1. Update to 1.98.9 immediately -- This fixes TS-2026-009 plus five other SSH vulnerabilities
2. The exploit is trivial -- ssh -i@node is all it takes; no special tools or payloads needed
3. ACLs are bypassed -- autogroup:nonroot provides no protection on vulnerable versions
4. Check your logs -- Search for usernames starting with - in SSH auth logs and Tailscale audit logs
5. Harden ACLs -- Explicitly deny autogroup:root for non-admin groups as defense in depth
6. All six SSH vulns ship together -- One upgrade fixes the entire class

Conclusion

TS-2026-009 is a textbook example of how a tiny input validation gap (accepting leading dashes in usernames) becomes a critical privilege escalation when combined with Unix command-line conventions (getent flag parsing). The fix is simple, but the window of exposure is significant -- any tailnet running Tailscale SSH on Linux before 1.98.9 should assume compromise is possible and audit accordingly.

Tailscale's disclosure is commendable: clear technical details, credit to reporters (Anthropic and Ada Logics), and a single version fixing six related issues. If you operate a tailnet, upgrade today.

---

Sources: Tailscale Security Bulletins | HN Discussion | Tailscale Changelog v1.98.9