tailscale - ts-2025-004

ts-2025-004

Vulnerability from tailscale

Description: Tailnets using shared public email providers

What happened?

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.

Background

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.

* We use special OIDC claims to map logins to tailnets on Google Workspace (hd claim) and Microsoft Entra (tid claim).

What changed

On May 22, 2025 a post on Reddit made the severity of this issue more obvious. The poster was using a previously unknown shared domain. We flagged the new shared domain and decomposed the tailnet.

To mitigate the potential risk for tailnets on shared domains, we enabled user approval by default for all new tailnets. This way, even if unexpected users log in using a shared domain that is not decomposed yet, an administrator will have to approve them first. We did not change the setting for any existing tailnets to avoid breaking any workflows.

Since May 22nd, we also decomposed 130 additional tailnets based on signals like: number of users, payment plan, recent activity, whether they have a Google Workspace or a Microsoft Entra tenant, and basic online research. Before May 22nd, we had already flagged and decomposed 534 shared domains, many proactively, but some in response to support tickets.

What we're doing next

We have certainly dug ourselves into a hole here. There are various public lists of shared domains, but it is tricky to figure out which existing tailnets are meant to be single-user and which are not. There are shared email hosting providers, customer emails created by ISPs, university emails, disposable email providers, etc. In all cases a tailnet could be a legitimate corporate tailnet for the company or university, and decomposing the tailnet could break their setup.

There are several planned actions and projects that should improve the situation:

Short-term
1. Proactively flag more shared domains that don't have tailnets yet, using public email provider lists and the Public Suffix List.
2. Reach out to admins of tailnets that are potentially on shared domains, but where we can't be certain, with advice on how to protect and audit their tailnets.
Medium-term
1. Mark any new domain coming through a Google or Microsoft login as shared if it's not associated with Google Workspace or a private Microsoft Entra tenant.
2. Prompt owners of existing tailnets like the above to enable User Approval on next login. Today this is ~1.7% of all tailnets.
3. Create a process for unflagging a shared domain through a support ticket and DNS ownership verification in case of false positives.
4. We are discussing changing the default ACL in new tailnets, but no decision has been made yet.
Long-term: a large identity model change has been in the works for roughly a year that, among other things, will make all new user registrations create a personal tailnet instead of a domain-wide tailnet by default.

What was the impact?

There are two potentially risky scenarios with shared domains: malicious users and malicious admins.

Malicious users could join a tailnet of an unsuspecting user and access exposed ports on that user's nodes. Tailnet ACLs could limit that impact, but default ACLs allow access to all ports on all nodes. Note that Tailscale SSH is not allowed between nodes of different users, so a malicious user would need to exploit some other software on a victim's node to gain access or information. Also note that the free plan of Tailscale is limited to 3 users.

Malicious admins could create a tailnet on a shared domain and wait, or social-engineer victims to join it. Once victims join the tailnet, a malicious admin could access all open ports on victims' nodes, and set up a subnet router to intercept their traffic. A malicious admin could also set up their own DNS server for the tailnet to record and spoof DNS responses.

We are not aware of any instances of either of these scenarios happening.

Who was affected?

Users of 664 known shared domains out of a total 166,488 unique domains we've seen across all tailnets may have had their nodes exposed to other users with the same email domain. 534 of these shared domains have been been decomposed throughout Tailscale's history and not recently.

There may be other tailnets using shared domains that we haven't discovered yet.

Who was not affected?

The following categories of users are not affected:

Users with custom email domains (corporate or personal)
Users with custom OIDC providers
GitHub users, including personal and org tailnets
Owners of tailnets with User Approval or Device Approval enabled
Owners of tailnets with Tailnet Lock enabled
Users of very popular email providers, like gmail.com, outlook.com, yahoo.com, protonmail.com, and others
Users with custom restrictive ACLs that avoid autogroup:member and other broad selectors in src clauses

What do I need to do?

If your tailnet name in the top-left corner of the Admin Console is an email address rather than a bare domain, no action is needed.

If you are in a tailnet on a shared domain:

Contact support to request your tailnet to be decomposed.
If you're the tailnet owner, review the list of users in your tailnet and audit logs for evidence of any suspicious activity.
If you're the tailnet owner and don't want to decompose your tailnet, enable user and/or device approval.

If you are in a tailnet on a domain that was wrongfully decomposed, contact support to reset your tailnet.

Timeline

March 2019: Tailscale started, Google and Azure AD (now Entra) authentication implemented
December 2019
- decision to maintain a list of shared domains was made
- first shared domain hardcoded - gmail.com
- Tailscale launched to a small set of users
November 2020: Node sharing released
January 2021: the hardcoded list of shared domains moved into a database table, tools created for the support team to decompose new shared domains
June 2021: GitHub authentication added
March 2023: Custom OIDC authentication added
April 2023: Passkey authentication added
April 2023: Apple authentication added
May 2023: External user invites added
- This was primarily the point at which creating a tailnet for email domains stopped being necessary. Multiple users could join a shared tailnet by an invitation to access each other's nodes, even on personal accounts from shared domains.
May 2025:
- May 22nd: Reddit user posted about an unexpected member of their tailnet
- May 22nd: User approval enabled by default for new tailnets
- May 23rd-27th: 130 shared domain tailnets identified and decomposed

Show details on source website

JSON

To clipboard

{
  "guidislink": false,
  "id": "https://tailscale.com/security-bulletins/#ts-2025-004",
  "link": "https://tailscale.com/security-bulletins/#ts-2025-004",
  "links": [
    {
      "href": "https://tailscale.com/security-bulletins/#ts-2025-004",
      "rel": "alternate",
      "type": "text/html"
    }
  ],
  "published": "Tue, 27 May 2025 00:00:00 GMT",
  "summary": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: Tailnets using shared public email providers\u003c/p\u003e\n\u003ch4\u003eWhat happened?\u003c/h4\u003e\n\u003cp\u003eOn May 22, 2025 our Reddit community gave us \u003ca href=\"https://www.reddit.com/r/Tailscale/comments/1ksy3xy/someone_just_randomly_joined_my_tailnet/\"\u003ethe necessary kick\u003c/a\u003e\nto address an issue with handling shared public email provider domains (\"shared\ndomains\"). We mitigated the risk for new tailnets being created on previously\nunknown shared domains by enabling \u003ca href=\"https://tailscale.com/kb/1239/user-approval\"\u003euser approval\u003c/a\u003e by\ndefault. This issue affects only a small portion of our user base, and this\nbulletin provides some background, mitigation steps, and our future plans.\u003c/p\u003e\n\u003ch5\u003eBackground\u003c/h5\u003e\n\u003cp\u003eTailscale users are mapped to tailnets by their email address domain (with a\nfew exceptions*). This means that \u003ccode\u003euser1@example.com\u003c/code\u003e and \u003ccode\u003euser2@example.com\u003c/code\u003e\ncan both log in to tailnet \u003ccode\u003eexample.com\u003c/code\u003e. We chose this default behavior because\nit reduces onboarding friction for new users and tailnet admins.\u003c/p\u003e\n\u003cp\u003eThe downside of this default behavior is that if a user\u0027s email address comes\nfrom a shared domain, multiple unrelated users may be able to join the same\ntailnet without realizing that others are in their tailnet too.\u003c/p\u003e\n\u003cp\u003eTailscale has a workaround for this scenario: we flag known shared domains in\nour database. For example, when \u003ccode\u003euser@gmail.com\u003c/code\u003e logs in for the first time, we\ncreate a personal tailnet named \u003ccode\u003euser@gmail.com\u003c/code\u003e for them instead of adding\nthem to one giant \u003ccode\u003egmail.com\u003c/code\u003e tailnet. If there is an existing shared domain\ntailnet, we \"decompose\" it - break it up into new personal tailnets for each\nuser with only their nodes. Very popular email providers, like Gmail or Yahoo,\nhave been decomposed from the very beginning.\u003c/p\u003e\n\u003cp\u003eThis workaround has an obvious flaw: we can\u0027t flag all shared domains in our\ndatabase proactively, because there is no authoritative list of such domains\nand new providers can show up at any time. So far we have patched over this\nflaw by retroactively flagging new shared domains when users report them to us.\nThis has been convenient for ease of onboarding new users, especially users on\ncorporate domains.\u003c/p\u003e\n\u003cp\u003e* We use special OIDC claims to map logins to tailnets on Google Workspace\n(\u003ccode\u003ehd\u003c/code\u003e claim) and Microsoft Entra (\u003ccode\u003etid\u003c/code\u003e claim).\u003c/p\u003e\n\u003ch5\u003eWhat changed\u003c/h5\u003e\n\u003cp\u003eOn May 22, 2025 a post on Reddit made the severity of this issue more obvious.\nThe poster was using a previously unknown shared domain. We flagged the new\nshared domain and decomposed the tailnet.\u003c/p\u003e\n\u003cp\u003eTo mitigate the potential risk for tailnets on shared domains, we enabled \u003ca href=\"https://tailscale.com/kb/1239/user-approval\"\u003euser\napproval\u003c/a\u003e by default for all new tailnets. This way, even if\nunexpected users log in using a shared domain that is not decomposed yet, an\nadministrator will have to approve them first. We did not change the setting\nfor any existing tailnets to avoid breaking any workflows.\u003c/p\u003e\n\u003cp\u003eSince May 22nd, we also decomposed 130 additional tailnets based on signals\nlike: number of users, payment plan, recent activity, whether they have a\nGoogle Workspace or a Microsoft Entra tenant, and basic online research. Before\nMay 22nd, we had already flagged and decomposed 534 shared domains, many\nproactively, but some in response to support tickets.\u003c/p\u003e\n\u003ch5\u003eWhat we\u0027re doing next\u003c/h5\u003e\n\u003cp\u003eWe have certainly dug ourselves into a hole here. There are various public\nlists of shared domains, but it is tricky to figure out which existing tailnets\nare meant to be single-user and which are not. There are shared email\nhosting providers, customer emails created by ISPs, university emails,\ndisposable email providers, etc. In all cases a tailnet could be a legitimate\ncorporate tailnet for the company or university, and decomposing the tailnet\ncould break their setup.\u003c/p\u003e\n\u003cp\u003eThere are several planned actions and projects that should improve the\nsituation:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eShort-term\n\u003col\u003e\n\u003cli\u003eProactively flag more shared domains that don\u0027t have tailnets yet, using\npublic email provider lists and the \u003ca href=\"https://publicsuffix.org\"\u003ePublic Suffix List\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eReach out to admins of tailnets that are potentially on shared domains,\nbut where we can\u0027t be certain, with advice on how to protect and audit their\ntailnets.\u003c/li\u003e\n\u003c/ol\u003e\n\u003c/li\u003e\n\u003cli\u003eMedium-term\n\u003col\u003e\n\u003cli\u003eMark any new domain coming through a Google or Microsoft login as shared\nif it\u0027s not associated with Google Workspace or a private Microsoft Entra\ntenant.\u003c/li\u003e\n\u003cli\u003ePrompt owners of existing tailnets like the above to enable User\nApproval on next login. Today this is ~1.7% of all tailnets.\u003c/li\u003e\n\u003cli\u003eCreate a process for unflagging a shared domain through a support ticket\nand DNS ownership verification in case of false positives.\u003c/li\u003e\n\u003cli\u003eWe are discussing changing the default ACL in new tailnets, but no\ndecision has been made yet.\u003c/li\u003e\n\u003c/ol\u003e\n\u003c/li\u003e\n\u003cli\u003eLong-term: a large identity model change has been in the works for roughly a\nyear that, among other things, will make all new user registrations create a\npersonal tailnet instead of a domain-wide tailnet by default.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch4\u003eWhat was the impact?\u003c/h4\u003e\n\u003cp\u003eThere are two potentially risky scenarios with shared domains: malicious users\nand malicious admins.\u003c/p\u003e\n\u003cp\u003eMalicious users could join a tailnet of an unsuspecting user and access exposed\nports on that user\u0027s nodes. Tailnet ACLs could limit that impact, but default\nACLs allow access to all ports on all nodes. Note that \u003ca href=\"https://tailscale.com/kb/1193/tailscale-ssh\"\u003eTailscale SSH\u003c/a\u003e\nis not allowed between nodes of different users, so a malicious user would need\nto exploit some other software on a victim\u0027s node to gain access or\ninformation. Also note that the free plan of Tailscale is limited to 3 users.\u003c/p\u003e\n\u003cp\u003eMalicious admins could create a tailnet on a shared domain and wait, or\nsocial-engineer victims to join it. Once victims join the tailnet, a malicious\nadmin could access all open ports on victims\u0027 nodes, and set up a \u003ca href=\"https://tailscale.com/kb/1019/subnets\"\u003esubnet\nrouter\u003c/a\u003e to intercept their traffic. A malicious admin could\nalso set up their own \u003ca href=\"https://tailscale.com/kb/1054/dns#override-dns-servers\"\u003eDNS server\u003c/a\u003e for the tailnet to record\nand spoof DNS responses.\u003c/p\u003e\n\u003cp\u003eWe are not aware of any instances of either of these scenarios happening.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eUsers of 664 known shared domains out of a total 166,488 unique domains we\u0027ve\nseen across all tailnets may have had their nodes exposed to other users with\nthe same email domain. 534 of these shared domains have been been decomposed\nthroughout Tailscale\u0027s history and not recently.\u003c/p\u003e\n\u003cp\u003eThere may be other tailnets using shared domains that we haven\u0027t discovered\nyet.\u003c/p\u003e\n\u003ch5\u003eWho was not affected?\u003c/h5\u003e\n\u003cp\u003eThe following categories of users are not affected:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eUsers with custom email domains (corporate or personal)\u003c/li\u003e\n\u003cli\u003eUsers with \u003ca href=\"https://tailscale.com/kb/1240/sso-custom-oidc\"\u003ecustom OIDC providers\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eGitHub users, including personal and org tailnets\u003c/li\u003e\n\u003cli\u003eOwners of tailnets with \u003ca href=\"https://tailscale.com/kb/1239/user-approval\"\u003eUser Approval\u003c/a\u003e or \u003ca href=\"https://tailscale.com/kb/1099/device-approval\"\u003eDevice\nApproval\u003c/a\u003e enabled\u003c/li\u003e\n\u003cli\u003eOwners of tailnets with \u003ca href=\"https://tailscale.com/kb/1226/tailnet-lock\"\u003eTailnet Lock\u003c/a\u003e enabled\u003c/li\u003e\n\u003cli\u003eUsers of very popular email providers, like \u003ccode\u003egmail.com\u003c/code\u003e, \u003ccode\u003eoutlook.com\u003c/code\u003e,\n\u003ccode\u003eyahoo.com\u003c/code\u003e, \u003ccode\u003eprotonmail.com\u003c/code\u003e, and others\u003c/li\u003e\n\u003cli\u003eUsers with custom restrictive \u003ca href=\"https://tailscale.com/kb/1018/acls\"\u003eACLs\u003c/a\u003e that avoid \u003ccode\u003eautogroup:member\u003c/code\u003e\nand other broad selectors in \u003ccode\u003esrc\u003c/code\u003e clauses\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003eIf your tailnet name in the top-left corner of the \u003ca href=\"https://login.tailscale.com/\"\u003eAdmin\nConsole\u003c/a\u003e is an email address rather than a bare domain, no\naction is needed.\u003c/p\u003e\n\u003cp\u003eIf you are in a tailnet on a shared domain:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003ca href=\"https://tailscale.com/contact/support\"\u003eContact support\u003c/a\u003e to request your tailnet to be decomposed.\u003c/li\u003e\n\u003cli\u003eIf you\u0027re the tailnet owner, review the \u003ca href=\"https://login.tailscale.com/admin/users\"\u003elist of users\u003c/a\u003e in your\ntailnet and \u003ca href=\"https://tailscale.com/kb/1203/audit-logging\"\u003eaudit logs\u003c/a\u003e for evidence of any suspicious\nactivity.\u003c/li\u003e\n\u003cli\u003eIf you\u0027re the tailnet owner and don\u0027t want to decompose your tailnet, enable\n\u003ca href=\"https://tailscale.com/kb/1239/user-approval\"\u003euser\u003c/a\u003e and/or \u003ca href=\"https://tailscale.com/kb/1099/device-approval\"\u003edevice\u003c/a\u003e approval.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eIf you are in a tailnet on a domain that was wrongfully decomposed, \u003ca href=\"https://tailscale.com/contact/support\"\u003econtact\nsupport\u003c/a\u003e to reset your tailnet.\u003c/p\u003e\n\u003ch4\u003eTimeline\u003c/h4\u003e\n\u003cul\u003e\n\u003cli\u003eMarch 2019: Tailscale started, Google and Azure AD (now Entra) authentication\nimplemented\u003c/li\u003e\n\u003cli\u003eDecember 2019\n\u003cul\u003e\n\u003cli\u003edecision to maintain a list of shared domains was made\u003c/li\u003e\n\u003cli\u003efirst shared domain hardcoded - \u003ccode\u003egmail.com\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003eTailscale launched to a small set of users\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003eNovember 2020: \u003ca href=\"https://tailscale.com/kb/1084/sharing\"\u003eNode sharing\u003c/a\u003e released\u003c/li\u003e\n\u003cli\u003eJanuary 2021: the hardcoded list of shared domains moved into a database\ntable, tools created for the support team to decompose new shared domains\u003c/li\u003e\n\u003cli\u003eJune 2021: GitHub authentication added\u003c/li\u003e\n\u003cli\u003eMarch 2023: Custom OIDC authentication added\u003c/li\u003e\n\u003cli\u003eApril 2023: Passkey authentication added\u003c/li\u003e\n\u003cli\u003eApril 2023: Apple authentication added\u003c/li\u003e\n\u003cli\u003eMay 2023: \u003ca href=\"https://tailscale.com/kb/1271/invite-any-user\"\u003eExternal user invites\u003c/a\u003e added\n\u003cul\u003e\n\u003cli\u003eThis was primarily the point at which creating a tailnet for email domains\nstopped being necessary. Multiple users could join a shared tailnet by\nan invitation to access each other\u0027s nodes, even on personal accounts from\nshared domains.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003eMay 2025:\n\u003cul\u003e\n\u003cli\u003eMay 22nd: Reddit user posted about an unexpected member of their tailnet\u003c/li\u003e\n\u003cli\u003eMay 22nd: User approval enabled by default for new tailnets\u003c/li\u003e\n\u003cli\u003eMay 23rd-27th: 130 shared domain tailnets identified and decomposed\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e",
  "summary_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/html",
    "value": "\u003cp\u003e\u003cstrong\u003e\u003cem\u003eDescription\u003c/em\u003e\u003c/strong\u003e: Tailnets using shared public email providers\u003c/p\u003e\n\u003ch4\u003eWhat happened?\u003c/h4\u003e\n\u003cp\u003eOn May 22, 2025 our Reddit community gave us \u003ca href=\"https://www.reddit.com/r/Tailscale/comments/1ksy3xy/someone_just_randomly_joined_my_tailnet/\"\u003ethe necessary kick\u003c/a\u003e\nto address an issue with handling shared public email provider domains (\"shared\ndomains\"). We mitigated the risk for new tailnets being created on previously\nunknown shared domains by enabling \u003ca href=\"https://tailscale.com/kb/1239/user-approval\"\u003euser approval\u003c/a\u003e by\ndefault. This issue affects only a small portion of our user base, and this\nbulletin provides some background, mitigation steps, and our future plans.\u003c/p\u003e\n\u003ch5\u003eBackground\u003c/h5\u003e\n\u003cp\u003eTailscale users are mapped to tailnets by their email address domain (with a\nfew exceptions*). This means that \u003ccode\u003euser1@example.com\u003c/code\u003e and \u003ccode\u003euser2@example.com\u003c/code\u003e\ncan both log in to tailnet \u003ccode\u003eexample.com\u003c/code\u003e. We chose this default behavior because\nit reduces onboarding friction for new users and tailnet admins.\u003c/p\u003e\n\u003cp\u003eThe downside of this default behavior is that if a user\u0027s email address comes\nfrom a shared domain, multiple unrelated users may be able to join the same\ntailnet without realizing that others are in their tailnet too.\u003c/p\u003e\n\u003cp\u003eTailscale has a workaround for this scenario: we flag known shared domains in\nour database. For example, when \u003ccode\u003euser@gmail.com\u003c/code\u003e logs in for the first time, we\ncreate a personal tailnet named \u003ccode\u003euser@gmail.com\u003c/code\u003e for them instead of adding\nthem to one giant \u003ccode\u003egmail.com\u003c/code\u003e tailnet. If there is an existing shared domain\ntailnet, we \"decompose\" it - break it up into new personal tailnets for each\nuser with only their nodes. Very popular email providers, like Gmail or Yahoo,\nhave been decomposed from the very beginning.\u003c/p\u003e\n\u003cp\u003eThis workaround has an obvious flaw: we can\u0027t flag all shared domains in our\ndatabase proactively, because there is no authoritative list of such domains\nand new providers can show up at any time. So far we have patched over this\nflaw by retroactively flagging new shared domains when users report them to us.\nThis has been convenient for ease of onboarding new users, especially users on\ncorporate domains.\u003c/p\u003e\n\u003cp\u003e* We use special OIDC claims to map logins to tailnets on Google Workspace\n(\u003ccode\u003ehd\u003c/code\u003e claim) and Microsoft Entra (\u003ccode\u003etid\u003c/code\u003e claim).\u003c/p\u003e\n\u003ch5\u003eWhat changed\u003c/h5\u003e\n\u003cp\u003eOn May 22, 2025 a post on Reddit made the severity of this issue more obvious.\nThe poster was using a previously unknown shared domain. We flagged the new\nshared domain and decomposed the tailnet.\u003c/p\u003e\n\u003cp\u003eTo mitigate the potential risk for tailnets on shared domains, we enabled \u003ca href=\"https://tailscale.com/kb/1239/user-approval\"\u003euser\napproval\u003c/a\u003e by default for all new tailnets. This way, even if\nunexpected users log in using a shared domain that is not decomposed yet, an\nadministrator will have to approve them first. We did not change the setting\nfor any existing tailnets to avoid breaking any workflows.\u003c/p\u003e\n\u003cp\u003eSince May 22nd, we also decomposed 130 additional tailnets based on signals\nlike: number of users, payment plan, recent activity, whether they have a\nGoogle Workspace or a Microsoft Entra tenant, and basic online research. Before\nMay 22nd, we had already flagged and decomposed 534 shared domains, many\nproactively, but some in response to support tickets.\u003c/p\u003e\n\u003ch5\u003eWhat we\u0027re doing next\u003c/h5\u003e\n\u003cp\u003eWe have certainly dug ourselves into a hole here. There are various public\nlists of shared domains, but it is tricky to figure out which existing tailnets\nare meant to be single-user and which are not. There are shared email\nhosting providers, customer emails created by ISPs, university emails,\ndisposable email providers, etc. In all cases a tailnet could be a legitimate\ncorporate tailnet for the company or university, and decomposing the tailnet\ncould break their setup.\u003c/p\u003e\n\u003cp\u003eThere are several planned actions and projects that should improve the\nsituation:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eShort-term\n\u003col\u003e\n\u003cli\u003eProactively flag more shared domains that don\u0027t have tailnets yet, using\npublic email provider lists and the \u003ca href=\"https://publicsuffix.org\"\u003ePublic Suffix List\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eReach out to admins of tailnets that are potentially on shared domains,\nbut where we can\u0027t be certain, with advice on how to protect and audit their\ntailnets.\u003c/li\u003e\n\u003c/ol\u003e\n\u003c/li\u003e\n\u003cli\u003eMedium-term\n\u003col\u003e\n\u003cli\u003eMark any new domain coming through a Google or Microsoft login as shared\nif it\u0027s not associated with Google Workspace or a private Microsoft Entra\ntenant.\u003c/li\u003e\n\u003cli\u003ePrompt owners of existing tailnets like the above to enable User\nApproval on next login. Today this is ~1.7% of all tailnets.\u003c/li\u003e\n\u003cli\u003eCreate a process for unflagging a shared domain through a support ticket\nand DNS ownership verification in case of false positives.\u003c/li\u003e\n\u003cli\u003eWe are discussing changing the default ACL in new tailnets, but no\ndecision has been made yet.\u003c/li\u003e\n\u003c/ol\u003e\n\u003c/li\u003e\n\u003cli\u003eLong-term: a large identity model change has been in the works for roughly a\nyear that, among other things, will make all new user registrations create a\npersonal tailnet instead of a domain-wide tailnet by default.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch4\u003eWhat was the impact?\u003c/h4\u003e\n\u003cp\u003eThere are two potentially risky scenarios with shared domains: malicious users\nand malicious admins.\u003c/p\u003e\n\u003cp\u003eMalicious users could join a tailnet of an unsuspecting user and access exposed\nports on that user\u0027s nodes. Tailnet ACLs could limit that impact, but default\nACLs allow access to all ports on all nodes. Note that \u003ca href=\"https://tailscale.com/kb/1193/tailscale-ssh\"\u003eTailscale SSH\u003c/a\u003e\nis not allowed between nodes of different users, so a malicious user would need\nto exploit some other software on a victim\u0027s node to gain access or\ninformation. Also note that the free plan of Tailscale is limited to 3 users.\u003c/p\u003e\n\u003cp\u003eMalicious admins could create a tailnet on a shared domain and wait, or\nsocial-engineer victims to join it. Once victims join the tailnet, a malicious\nadmin could access all open ports on victims\u0027 nodes, and set up a \u003ca href=\"https://tailscale.com/kb/1019/subnets\"\u003esubnet\nrouter\u003c/a\u003e to intercept their traffic. A malicious admin could\nalso set up their own \u003ca href=\"https://tailscale.com/kb/1054/dns#override-dns-servers\"\u003eDNS server\u003c/a\u003e for the tailnet to record\nand spoof DNS responses.\u003c/p\u003e\n\u003cp\u003eWe are not aware of any instances of either of these scenarios happening.\u003c/p\u003e\n\u003ch4\u003eWho was affected?\u003c/h4\u003e\n\u003cp\u003eUsers of 664 known shared domains out of a total 166,488 unique domains we\u0027ve\nseen across all tailnets may have had their nodes exposed to other users with\nthe same email domain. 534 of these shared domains have been been decomposed\nthroughout Tailscale\u0027s history and not recently.\u003c/p\u003e\n\u003cp\u003eThere may be other tailnets using shared domains that we haven\u0027t discovered\nyet.\u003c/p\u003e\n\u003ch5\u003eWho was not affected?\u003c/h5\u003e\n\u003cp\u003eThe following categories of users are not affected:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eUsers with custom email domains (corporate or personal)\u003c/li\u003e\n\u003cli\u003eUsers with \u003ca href=\"https://tailscale.com/kb/1240/sso-custom-oidc\"\u003ecustom OIDC providers\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003eGitHub users, including personal and org tailnets\u003c/li\u003e\n\u003cli\u003eOwners of tailnets with \u003ca href=\"https://tailscale.com/kb/1239/user-approval\"\u003eUser Approval\u003c/a\u003e or \u003ca href=\"https://tailscale.com/kb/1099/device-approval\"\u003eDevice\nApproval\u003c/a\u003e enabled\u003c/li\u003e\n\u003cli\u003eOwners of tailnets with \u003ca href=\"https://tailscale.com/kb/1226/tailnet-lock\"\u003eTailnet Lock\u003c/a\u003e enabled\u003c/li\u003e\n\u003cli\u003eUsers of very popular email providers, like \u003ccode\u003egmail.com\u003c/code\u003e, \u003ccode\u003eoutlook.com\u003c/code\u003e,\n\u003ccode\u003eyahoo.com\u003c/code\u003e, \u003ccode\u003eprotonmail.com\u003c/code\u003e, and others\u003c/li\u003e\n\u003cli\u003eUsers with custom restrictive \u003ca href=\"https://tailscale.com/kb/1018/acls\"\u003eACLs\u003c/a\u003e that avoid \u003ccode\u003eautogroup:member\u003c/code\u003e\nand other broad selectors in \u003ccode\u003esrc\u003c/code\u003e clauses\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch4\u003eWhat do I need to do?\u003c/h4\u003e\n\u003cp\u003eIf your tailnet name in the top-left corner of the \u003ca href=\"https://login.tailscale.com/\"\u003eAdmin\nConsole\u003c/a\u003e is an email address rather than a bare domain, no\naction is needed.\u003c/p\u003e\n\u003cp\u003eIf you are in a tailnet on a shared domain:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003ca href=\"https://tailscale.com/contact/support\"\u003eContact support\u003c/a\u003e to request your tailnet to be decomposed.\u003c/li\u003e\n\u003cli\u003eIf you\u0027re the tailnet owner, review the \u003ca href=\"https://login.tailscale.com/admin/users\"\u003elist of users\u003c/a\u003e in your\ntailnet and \u003ca href=\"https://tailscale.com/kb/1203/audit-logging\"\u003eaudit logs\u003c/a\u003e for evidence of any suspicious\nactivity.\u003c/li\u003e\n\u003cli\u003eIf you\u0027re the tailnet owner and don\u0027t want to decompose your tailnet, enable\n\u003ca href=\"https://tailscale.com/kb/1239/user-approval\"\u003euser\u003c/a\u003e and/or \u003ca href=\"https://tailscale.com/kb/1099/device-approval\"\u003edevice\u003c/a\u003e approval.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eIf you are in a tailnet on a domain that was wrongfully decomposed, \u003ca href=\"https://tailscale.com/contact/support\"\u003econtact\nsupport\u003c/a\u003e to reset your tailnet.\u003c/p\u003e\n\u003ch4\u003eTimeline\u003c/h4\u003e\n\u003cul\u003e\n\u003cli\u003eMarch 2019: Tailscale started, Google and Azure AD (now Entra) authentication\nimplemented\u003c/li\u003e\n\u003cli\u003eDecember 2019\n\u003cul\u003e\n\u003cli\u003edecision to maintain a list of shared domains was made\u003c/li\u003e\n\u003cli\u003efirst shared domain hardcoded - \u003ccode\u003egmail.com\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003eTailscale launched to a small set of users\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003eNovember 2020: \u003ca href=\"https://tailscale.com/kb/1084/sharing\"\u003eNode sharing\u003c/a\u003e released\u003c/li\u003e\n\u003cli\u003eJanuary 2021: the hardcoded list of shared domains moved into a database\ntable, tools created for the support team to decompose new shared domains\u003c/li\u003e\n\u003cli\u003eJune 2021: GitHub authentication added\u003c/li\u003e\n\u003cli\u003eMarch 2023: Custom OIDC authentication added\u003c/li\u003e\n\u003cli\u003eApril 2023: Passkey authentication added\u003c/li\u003e\n\u003cli\u003eApril 2023: Apple authentication added\u003c/li\u003e\n\u003cli\u003eMay 2023: \u003ca href=\"https://tailscale.com/kb/1271/invite-any-user\"\u003eExternal user invites\u003c/a\u003e added\n\u003cul\u003e\n\u003cli\u003eThis was primarily the point at which creating a tailnet for email domains\nstopped being necessary. Multiple users could join a shared tailnet by\nan invitation to access each other\u0027s nodes, even on personal accounts from\nshared domains.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003eMay 2025:\n\u003cul\u003e\n\u003cli\u003eMay 22nd: Reddit user posted about an unexpected member of their tailnet\u003c/li\u003e\n\u003cli\u003eMay 22nd: User approval enabled by default for new tailnets\u003c/li\u003e\n\u003cli\u003eMay 23rd-27th: 130 shared domain tailnets identified and decomposed\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ul\u003e"
  },
  "title": "TS-2025-004",
  "title_detail": {
    "base": "https://tailscale.com/security-bulletins/index.xml",
    "language": null,
    "type": "text/plain",
    "value": "TS-2025-004"
  }
}

Action not permitted