One Leading Dash Turned Tailscale SSH Access Into a Root Session

SSH access is often wider than a security policy intends. Tailscale SSH manages authentication and authorization for connections over a private Tailscale network. Its identity-based rules can restrict an authorized person to a non-root Unix account.

The local root account is the Linux superuser, so excluding it is the most important boundary in a policy such as autogroup:nonroot. Administrators using that rule expected a permitted user to reach the host without receiving unrestricted control. Tailscale's July 2026 disclosure showed that one flag-shaped username could break that guarantee after authentication had already succeeded.

Tailscale disclosed a small parsing bug with a large result: an authorized Tailscale SSH user could turn the username -i into an interactive root session. The July 13 security bulletin says this violated an access-control policy that allowed non-root users and explicitly excluded root.

The Policy Said Non-Root

Tailscale SSH manages authentication and authorization for SSH connections inside a tailnet, Tailscale's encrypted network between your devices. A tailnet policy controls who may connect to a node and which existing local Unix accounts they may use. The built-in autogroup:nonroot selector means any local user except root. On an affected Linux host, someone already allowed to connect as a non-root user could cross that final privilege boundary anyway.

The failure happened after the remote identity had been authenticated. To find the local account on Linux, Tailscale passed the requested username as an argument to getent(1), the standard tool used to query databases such as passwd. A username is data to the SSH policy, while a command-line parser can treat the same string as an option when it begins with a dash.

Authorization and account lookup are separate decisions. Tailscale had already established who the remote user was and that a non-root login was allowed. The failure occurred when the approved local username crossed into the argument syntax of another program. At that point, a value that looked like an identity to the policy engine could be interpreted as an instruction by getent.

How getent Returned Root

According to Tailscale, getent interpreted -i as its --no-idn flag instead of an account name. With no specific account selected, it printed the complete passwd database beginning with the root entry. Tailscale consumed that first result and opened the session as root.

The policy layer and the account-lookup layer had assigned different meanings to the same bytes. Authorization was supposed to limit the session to a non-root identity, but the adapter that converted that identity into a process argument introduced a second language with its own control syntax. A correct policy cannot make that later translation safe.

What to Patch and Test

Tailscale's documented fix is narrow and direct: reject usernames with leading dashes. The company says the issue is fixed in version 1.98.9 or newer, and the July 14 changelog lists that rejection among the v1.98.9 security fixes. Users of Tailscale SSH should upgrade. Tailscale credits Anthropic and Ada Logics with reporting the flaw.

The affected scope begins with a user who already had Tailscale SSH access. Tailscale says the vulnerable configuration was a Linux host relying on autogroup:nonroot; the bulletin does not extend the claim to conventional SSH, every platform, or every ACL. It also does not report exploitation in the wild, assign a CVE, give a complete affected-version range, or say when the bug first appeared.

A security review needs to cover the full path from remote identity to launched process. Any system that turns an approved username, filename, repository name, or tenant identifier into a command argument creates another security boundary at the invocation site. That boundary needs domain-specific validation, option termination where the called program supports it, and tests with flag-shaped values at the final lookup and launch path.

A regression test for this class of bug should exercise the actual lookup and launch boundary, not a mock that assumes every username remains plain data. Tailscale's leading-dash case belongs beside other boundary values such as numeric identifiers because both can gain a second meaning in another parser. The test should assert that the Unix account finally selected is still the account the policy authorized.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com