TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access

Original Article ↗ Hacker News Discussion ↗

A recently disclosed vulnerability in Tailscale’s SSH feature allowed authenticated users on a tailnet to gain root access by passing a specially crafted username (e.g., one starting with `-i`), exposing long-known risks around unsafe command-line argument handling. Commenters debate the adequacy of Tailscale’s fix (rejecting leading-dash and numeric usernames) versus more robust solutions like using system APIs directly, and compare the security posture of Tailscale SSH with OpenSSH, self-hosted WireGuard, and alternatives such as Headscale and Netbird. The incident also raises wider concerns about Tailscale’s security auditing, reliance on extra features beyond core VPN functionality, and the trade-offs between convenience, self-hosting, and formal assurance.

Nature of the vulnerability and impact

  • Classic argument-parsing bug: Tailscale SSH passed user-supplied usernames as arguments to getent(1); a username starting with - could be interpreted as a flag (e.g., -i) and lead to root login.
  • Commenters note this class of bug is very old and well-known, comparable to shell-escaping / SQL injection mistakes.
  • Exploit requires prior access to the tailnet and to a host permitted by ACLs; it breaks SSH authorization/ACL boundaries but does not expose hosts directly to the public internet.

Quality of the fix

  • Tailscale’s immediate fix is to reject usernames with leading dashes, and also disallow numeric-only usernames/UIDs via SSH.
  • Some see this as a pragmatic, future-proof policy: weird usernames are rare, and input restrictions permanently block the class of issue.
  • Others call it a “dirty” or partial fix and argue the real solution is:
    • Never shell out to getent with untrusted args.
    • Use proper system APIs like getpwnam(3) or language wrappers (os/user) instead.
    • Or call getent passwd without user arguments and parse output.
  • There is debate about practical difficulties with libc/NSS, static linking, and portability, but several participants insist those are solvable.

Tailscale SSH vs OpenSSH

  • Multiple people avoid Tailscale SSH and stick to OpenSSH, citing its long security track record.
  • Others value Tailscale SSH for convenience (browser access, centralized SSH ACLs, managing many intermittently connected boxes).
  • Some note Tailscale SSH only affects port 22 on the Tailscale interface, but this can still conflict with existing SSH setups.

Tailscale vs self-hosted WireGuard and alternatives

  • A camp prefers self-hosted WireGuard (simple, stable, no third party, “Toyota Corolla” reliability).
  • Pro‑Tailscale comments emphasize:
    • Automatic NAT traversal and mesh networking.
    • Centralized identity, ACLs, 2FA/expiring keys, DNS-based routing.
    • Ease of use for non-experts and quick homelab/remote setups.
  • Others mention headscale and Netbird as self‑hosted or open alternatives, with some complaints about mobile battery drain.

Security process, trust, and deployment patterns

  • Some express distrust of Tailscale: large open issue backlog, perceived lack of public formal security audits, and the presence of such a basic bug.
  • Others respond that:
    • All software has undiscovered vulnerabilities; defense-in-depth is key.
    • Tailscale reportedly uses external security firms, and its core VPN functionality generally “just works.”
  • Several organizations mitigate risk by:
    • Running Tailscale only on hardened bastion hosts, not every server.
    • Using features like tailnet lock, though its design/usability is criticized.
  • There is debate over Tailscale’s custom vulnerability IDs vs CVEs; motivations cited include control over timing/narrative and CVE bureaucracy.