TS-2026-009: Insecure argument handling in Tailscale SSH permitted root access
Description : Tailnets using shared public email providers
On May 22, 2025 our Reddit community gave us the necessary kick to address an issue with handling shared public email provider domains ("shared domains"). We mitigated the risk for new tailnets being created on previously unknown shared domains by enabling user approval by default. This issue affects only a small portion of our user base, and this bulletin provides some background, mitigation steps, and our future plans.
Tailscale users are mapped to tailnets by their email address domain (with a few exceptions*). This means that user1@example.com and user2@example.com can both log in to tailnet example.com . We chose this default behavior because it reduces onboarding friction for new users and tailnet admins.
The downside of this default behavior is that if a user's email address comes from a shared domain, multiple unrelated users may be able to join the same tailnet without realizing that others are in their tailnet too.
Tailscale has a workaround for this scenario: we flag known shared domains in our database. For example, when user@gmail.com logs in for the first time, we create a personal tailnet named user@gmail.com for them instead of adding them to one giant gmail.com tailnet. If there is an existing shared domain tailnet, we "decompose" it - break it up into new personal tailnets for each user with only their nodes. Very popular email providers, like Gmail or Yahoo, have been decomposed from the very beginning.
This workaround has an obvious flaw: we can't flag all shared domains in our database proactively, because there is no authoritative list of such domains and new providers can show up at any time. So far we have patched over this flaw by retroactively flagging new shared domains when users report them to us. This has been convenient for ease of onboarding new users, especially users on corporate domains.