A leading dash, a forgotten guard, a root shell

The "untrusted string crossed a CLI boundary" class of bug — the Tailscale bulletin describes the specific mechanism but does not explicitly frame TS-2026-009 as an instance of that broader class; that framing is the reporter's synthesis — has its latest quiet exhibit. The pattern is the same every time: a program takes a username, a filename, or a hostname from somewhere it does not control, hands it to another program as a CLI argument, and forgets the leading-dash guard. The inner program sees a flag, not a value, and the rest is the shell's rulebook.

Tailscale's bulletin on TS-2026-009 shows the shape cleanly. On Linux, a username starting with - was passed straight to getent(1). A username of -i was interpreted as --no-idn, which made getent print the entire passwd file starting with root; Tailscale SSH then opened an interactive root session, in violation of the configured ACLs. The fix in 1.98.9 is the canonical defense: reject usernames with leading dashes, and pass arguments as arrays so the shell never re-parses them.

Read the bulletin as a portable checklist. The same shape hides in sudo wrappers that accept usernames, in chsh/usermod helpers, in image pipelines that take a filename from a URL, and in any code that concatenates a network-supplied string into a command line. The portable test is one question: does any string from the network reach a CLI without a leading-dash check or argv-style separation? If yes, this is the same bug, waiting for a different name.

Tailscale's fix is one release. The class outlives the patch.