Security Bulletins

Description: We resolved an information disclosure vulnerability in the hello.ts.net service.

What happened?

On January 15 2024, we became aware of a potential information disclosure vulnerability in the hello.ts.net service, which could show the identity of a different Tailscale user when loaded. The hello.ts.net service receives identity information and public keys of nodes tied to their IP address. On November 28 2023, we made a change to how IPs are assigned to Tailscale nodes, making them globally non-unique. When the Tailscale service assigned the same IP to multiple nodes, hello.ts.net would receive identity information for one of the nodes at random. We confirmed on January 26 2024 that, if one of the other nodes with that IP loaded hello.ts.net, they would see another user's name, email, and hostname.

The Tailscale Security Team immediately took hello.ts.net offline while the fix was in progress. The issue has been fixed and the hello.ts.net service was restored on January 29 2024.

Who was affected?

The incident was isolated to 10 users across 9 tailnets who could have had their information leaked to other Tailscale users. We notified the tailnet security contacts directly in accordance with our obligations under applicable data privacy laws. Due to the random nature of the vulnerability, we cannot confirm that all of those users were indeed affected.

Regular shared nodes always see unique node IPs and were not vulnerable in a manner similar to hello.ts.net.

What was the impact?

A small number of users had their name, email, and hostname potentially exposed to other Tailscale users that had nodes sharing the same IP.

In addition, the hello.ts.net service was offline between January 26-29 2024. Several users reported being negatively impacted by this.

What do I need to do?

No action is needed at this time.

If you have a dependency on hello.ts.net as a probing target for Tailscale connectivity, consider using a different probing mechanism.

Description: On Windows before Tailscale version 1.52 and on Linux before Tailscale 1.54, the tailscale serve and tailscale funnel features allowed users to serve the contents of directories that their user account could not access, but which the tailscaled service process could.

What happened?

A user could escalate their own file read access by running, for example, tailscale.exe serve http / C:\, and then browsing to the local HTTP endpoint.

The issue can also occur on Linux if the local administrator enabled an operator user ID with tailscale up --operator=$USER, as the $USER account could serve itself files that it could not normally read.

Who is affected?

Owners of Windows deployments for which the users of Tailscale nodes do not also have OS-level administrative access, and owners of Linux deployments where the administrator enabled non-root --operator access.

This issue can only be triggered by a local user and cannot be triggered remotely.

What is the impact?

This issue enables local privilege escalation (file read access). Access to certain system files (such as /etc/shadow on Linux) can then be used to obtain full administrative control over the host.

What do I need to do?

On Windows 10 and later, upgrade to Tailscale 1.52 (released 30 October 2023) or later, which resolves the issue.

On Windows 7 and 8, upgrade to Tailscale 1.44.3 (released 8 Jan 2024), which resolves the issue.

On Linux, upgrade to 1.54 (released 15 November 2023) or later, which resolves the issue.

The best practice is to run the latest stable version, which as of this writing is 1.56.1. Consider turning on automatic updates.

Use Tailscale ACLs to control the availability of Funnel.

Description: The OAuth implementation of Google Workspace allows for the creation of Google accounts associated with a given Workspace domain that are not actually controlled by that workspace, e.g. alice+foo@example.com. As a result, these accounts may be used to retain access to systems that use Google Workspace SSO login even after the original account has been deactivated or removed.

What happened?

Tailscale uses Google as one of the possible identity providers for creating and joining a tailnet. Users who have emails with the same domain name can automatically sign in using SSO and be added to the corresponding tailnet (unless user approval is turned on for the tailnet)​​. The OAuth vulnerability reported by Truffle Security means that it is possible for an attacker to create a new personal Google Account that is attached to an alias of their legitimate Workspace account. This new account will not register as being part of the domain's Workspace, and thus cannot be removed by its admins. However, if the attacker then uses the new, spoofed Google Account to log into Tailscale, we would have treated it as a legitimate user in the tailnet. Thus, users could remain connected to a tailnet using this spoofed account even if their primary Workspace account has been disabled, e.g. after employee termination.

We became aware of the vulnerability on 2023-12-21 when its disclosure by Truffle Security was circulated widely. We deployed a remediation that prevents personal Google accounts from logging into tailnets associated with Workspace accounts on 2023-12-21.

Who is affected?

Everyone who uses Google Workspace to sign in.

What is the impact?

Tailnets that use Google Workspace as their SSO provider may have Tailscale users that do not have a corresponding user in the Google Workspace. Prior to 2023-12-21, this would have made it possible for those users to retain access to Tailscale after their SSO account was deleted. Following the remediation, these users can no longer login to Tailscale.

What do I need to do?

Tailscale admins should visit the Users page of the Tailscale admin console and audit the list of users to see if there are unknown addresses that should not be there. Admins can also export this list of users as a CSV file to examine offline.

For extra security, you can turn on user approval for your Tailnet so that every new user of Tailscale has to be manually approved by an admin. Note: this does not mitigate against situations where the attacker is themselves an admin of Tailscale.

Description: Privilege escalation bugs in the Tailscale Kubernetes operator's API proxy allowed authenticated tailnet clients to send Kubernetes API requests as the operator's service account.

Tailscale Kubernetes operator version v1.53.37 fixes the issue and users of the operator who enable the API proxy functionality should update as described below.

What happened?

The Tailscale Kubernetes operator can optionally act as an API server proxy for the cluster's Kubernetes API. This proxy allows authenticated tailnet users to use their tailnet identity in Kubernetes authentication and RBAC rules. The API server proxy uses impersonation headers to translate tailnet identities to Kubernetes identities.

The operator prior to v1.53.37 has two bugs in the forwarding logic, which affects different modes of operation:

• In the default proxy mode that applies Tailscale identity to proxied requests, incorrect header sanitization allowed a request with a crafted Connection header to drop the impersonation headers from the proxied request. This caused the proxied request to be authenticated as the operator's service account, and inherit the operator's permissions.
• In the no-auth proxy mode, which does not apply Tailscale identity to forwarded requests, a specially crafted request could similarly cause the proxied request to use the operator's identity, with similar results.

The bug was reported by Mo Khan from Microsoft on 2023-11-01, and fixed on the same day.

Who is affected?

Tailnets using the API server proxy in Tailscale Kubernetes operator images with the following tags are affected:

• unstable-v1.53.20 or earlier
• unstable deployed before the tag was updated to 1.53.37, some time on 2023-11-01.

Operator users running in the default operator configuration are not affected, as the API proxy is not enabled by default.

What is the impact?

Authenticated tailnet users who have access to the operator's API proxy can make requests to the Kubernetes API with operator privileges. In the proxy mode that allows the operator to use impersonation, this can be used for further privilege escalation to other cluster identities.

External attackers cannot exploit this vulnerability without being a member of the tailnet.

What do I need to do?

Update the Tailscale Kubernetes operator image to version unstable-v1.53.37 or later.

If you used the official operator manifest file, download the new manifest file and run kubectl apply -f manifest.yaml.

If you used the Helm chart, set the operatorConfig.image.tag to unstable-v1.53.37 in the values.yaml file and run helm upgrade <path-to-chart-directory> -n tailscale -f <path-to-values-file>

If you wrote your own manifest or Helm chart, update the k8s-operator image tag to unstable-v1.53.37 and redeploy it.

Description: Microsoft Defender is flagging Tailscale 1.46.1 as malware. These classifications are false positives, and we are working with Microsoft to resolve the situation.

As of 2023-10-27 1:05 AM UTC, we have confirmed that Microsoft have addressed the false positive, meaning Defender no longer flags Tailscale 1.46.1 as malware. A rescan of tailscaled.exe 1.46.1 on VirusTotal confirms this.

What happened?

Microsoft Defender was flagging Tailscale 1.46.1 as malware. This caused Defender to quarantine the binaries, meaning they could not run.

We submitted Tailscale 1.46.1 to Microsoft to investigate the false positive, who then updated Defender to avoid flagging this release as malware at 2023-10-27 1:05 AM UTC.

Who is affected?

People using Defender and Tailscale 1.46.1.

What is the impact?

Tailscale will not run on affected machines.

What do I need to do?

To resolve this issue on your own tailnet, you can take either or both of 2 approaches:

1. Update to a newer version of Tailscale. Newer versions are not affected by this problem.
2. Create an exception in Microsoft Defender. Microsoft has published instructions explaining how to do this.
3. Update Microsoft Defender.

Description: An issue in the Tailscale client, combined with a behavior of the UPnP implementations in some routers, could expose all UDP ports of a node to external networks (usually the internet).

As of 2023-08-22 2:30 AM UTC, we have changed the Tailscale coordination server to advise nodes to stop using UPnP for port mapping. In some cases this can degrade NAT traversal and may cause some connections to route through DERP. This may increase node-to-node latency and decrease throughput. Version 1.48.1 resolves the issue and re-enables port mapping via UPnP.

What happened?

Tailscale nodes use UPnP as one of the mechanisms to open UDP port forwarding in routers to help with NAT traversal. Tailscale picks a node port and an external router port and requests forwarding between them. On first start Tailscale requested external port 0, which many routers interpret as a request to pick a random available port. However, some routers interpret this as a request to listen on all external ports and forward traffic to matching node ports.

Depending on the router's implementation of UPnP, a node could end up open to all UDP traffic from external networks. If some processes listen on UDP ports on the node, this could be used as a vector of attack against other software running on the node.

Any firewall software running on the node would be able to stop unwanted UDP packets, if configured to do so.

The bug was discovered and fixed on 2023-08-21, and the fix was published in the 1.48.1 release.

Who is affected?

The only known vulnerable routers are those running the miniupnpd server, versions 1.9 (2016) or earlier. Other UPnP server implementations may also be vulnerable, but Tailscale is not aware of any as of 2023-08-22.

A small percentage of nodes listened on router port 0 via UPnP before the mitigation was deployed. All nodes running vulnerable versions now have UPnP port mapping disabled.

What is the impact?

Any node service listening on UDP ports from any IP could receive traffic from external networks. This only applies to networks where the router implements UPnP wildcard port support.

If such a service does not implement authentication and/or authorization, allows packets to trigger sensitive actions, or has separate remotely-exploitable vulnerabilities, the node could be compromised by an attacker.

What do I need to do?

UPnP on vulnerable versions was disabled by the coordination server. Update Tailscale to version 1.48.1 or later to restore NAT traversal using UPnP for better node connectivity.

We do not recommend disabling UPnP or other port-mapping protocols on your router. These protocols greatly improve connectivity for Tailscale and other applications.

Description: An issue in the Tailscale coordination server in device reauthentication logic caused previously authenticated and tagged devices to lose their ACL tags upon reauthentication.

What happened?

The logic that handles the reauthentication to a new identity on an already-authenticated device with tags had a bug: instead of updating the device’s logged-in identity to the newly authenticated user, the device’s identity became that of the user who originally added it to the tailnet, without any tags.

The bug was introduced on 2022-10-26, and discovered and remediated on 2023-04-21. The bug was discovered when troubleshooting a user-reported issue.

Who is affected?

189 tailnets triggered this bug in the course of normal use of Tailscale, either directly by explicitly re-authenticating a device, or indirectly by using fast user switching to switch between multiple tailnets.

We have notified affected organizations where we have security contacts.

What is the impact?

Devices that encountered the bug had their tags removed, which reverted the device’s identity to that of the user who originally authenticated the device, or the owner of the auth key that was originally used to authenticate the device. In either case, this is the user listed as “Creator” in the Machines tab of the admin panel. Depending on access rules in the tailnet policy file, this could change the device’s network permissions.

We have analyzed the audit logs for affected tailnets, and found no evidence of deliberate exploitation. In most instances, device owners noticed the incorrect outcome of reauthentication, and corrected the device’s state themselves.

What do I need to do?

If you were not contacted by Tailscale, no action is required.  If you were contacted by Tailscale, reapply the desired tags to affected devices in the admin console, or by reauthenticating the devices. Tailscale has deployed a fix to the coordination server as of 2023-04-21, and notified affected organizations.

Description: An issue in the Tailscale coordination server allowed tailnets created by GitHub organizations which were subsequently renamed to be associated with a new GitHub organization with the previous name.

What happened?

Tailscale mapped tailnets created by GitHub organizations to their organization name, rather than to their organization ID. This meant that if a GitHub organization was renamed, and the previous name taken over by a new GitHub organization, the existing tailnet would be tied to the new GitHub organization instead of the original one.

Who is affected?

Up to 1,305 tailnets created by GitHub organizations may have been affected, if those GitHub organizations were renamed between 2021-06-18 and 2023-03-30 and fully relinquished the old GitHub organization name. Additional tailnets created by GitHub organizations could be verified to definitely not have been renamed in that time period based on organization membership.

No tailnets were definitively found to have been affected. If a tailnet created by a GitHub organization is affected, we can detect this the next time an unauthorized user logs in to the tailnet belonging to the renamed organization and block their access. We will contact the security contact for that tailnet if that happens.

What is the impact?

A renamed GitHub organization may have had their previous tailnet visible to a newly created GitHub organization with the same name. The new GitHub organization would be aware of the existence of the previous tailnet. Devices added to the new GitHub organization would be aware of the existence and some metadata of previous added devices, including: their host names, their OS and version, when the devices were last connected, and their public IP addresses. They would have been able to connect to these devices if allowed by ACLs. The new GitHub organization would not have had any admin access or be able to see or modify any setting in the admin console.

There is no evidence of this vulnerability being purposefully triggered or exploited.

What do I need to do?

No action is required. Tailscale has deployed a fix to the coordination server as of 2023-03-30.

GitHub organizations which were previously renamed and lost access to their tailnet should contact support. When renaming a GitHub organization, contact support to migrate the tailnet to the new GitHub organization.

Credits

We would like to thank Thomas Way for reporting this issue.

Reference: CVE-2023-28436

Severity: Medium

CVSS vector string: CVSS:3.0/AV:A/AC:L/PR:H/UI:R/S:C/C:H/I:N/A:N

Description: A vulnerability identified in the implementation of Tailscale SSH in FreeBSD allowed commands to be run with a higher privilege group ID than that specified by Tailscale SSH access rules.

Affected platforms: FreeBSD

Patched Tailscale client versions: v1.38.2 or later

What happened?

A difference in the behavior of the FreeBSD setgroups system call from POSIX meant that the Tailscale client running on a FreeBSD-based operating system did not appropriately restrict groups on the host when using Tailscale SSH. When accessing a FreeBSD host over Tailscale SSH, the egid of the tailscaled process was used instead of that of the user specified in Tailscale SSH access rules.

Who is affected?

9 tailnets with 22 FreeBSD nodes running Tailscale SSH since Tailscale v1.34 (released on 2022-12-04) may have had Tailscale SSH sessions with a higher privilege group ID than that specified in Tailscale SSH access rules.

We have notified affected organizations where we have security contacts.

What is the impact?

Tailscale SSH commands may have been run with a higher privilege group ID than that specified in Tailscale SSH access rules if they met all of the following criteria:

• The destination node was a FreeBSD device with Tailscale SSH enabled;
• Tailscale SSH access rules permitted access for non-root users; and
• A non-interactive SSH session was used.

What do I need to do?

If you are running Tailscale on FreeBSD, upgrade to v1.38.2 or later to remediate the issue. Admins of a tailnet can view FreeBSD nodes with unpatched versions in the admin console.

To update the local ports tree in advance of what's available upstream, you can:

1. cd /usr/ports/security/tailscale
2. edit the Makefile to set PORTVERSION to 1.38.2
3. make makesum
4. make install

Tailscale SSH on other platforms is not affected.

Credits

We would like to thank Ryan Belgrave for reporting this issue.

Description: An issue in the Tailscale coordination server allowed nodes with expired node keys to continue communicating with other nodes in a tailnet.

What happened?

There was a flaw in Tailscale’s logic for expiring node keys. If the set of nodes that can connect in a tailnet (the netmap) didn’t have any changes, then expired node keys were not immediately removed from the netmap. The longest delay in removal was 19 days, from 2022-12-20 to 2023-01-09.

Who is affected?

All tailnets with nodes whose node keys expired prior to 2023-01-12 may have been affected. Admins of a tailnet can view nodes with expired node keys in the admin console.

What is the impact?

Connections between nodes could continue after a node key expired, both when the expired node key was the source or when it was the destination of a connection. Connections to nodes with expired node keys would only be possible if they met all of the following criteria:

• The peer node was in the same tailnet as, or shared into a tailnet with the node with the expired node key;
• The peer node and the node with the expired node key were allowed to connect based on the access rules in the tailnet policy file at the time of expiry of the node key;
• The tailnet’s netmap, including access rules, nodes added or removed from the tailnet, or connectivity of nodes in the tailnet did not change since the node key expiry; and
• Tailscale had not deployed a change to the coordination server since the node key expiry.

What do I need to do?

No action is required. Tailscale has deployed a fix to the coordination server as of 2023-01-11.

Upgrade clients to v1.36 or later for an additional mitigation. In conjunction with the coordination server fix, this mitigation prevents nodes from connecting to nodes with expired node keys if the Tailscale coordination server is offline or unreachable.

Credits

We would like to thank Derek Ellis and Alex Eiser for reporting this issue.

Description: An issue in the Tailscale coordination server allowed a malicious individual to share nodes from other tailnets to themselves, if they knew the node ID of the target.

What happened?

A bug in Tailscale’s node sharing logic allowed the creation of sharing invitations by unauthorized users. A malicious individual who knew a target node’s database ID could generate and accept a sharing invite for that node without being an admin of the target node’s tailnet.

This was possible for any node in any tailnet, as long as the individual knew the target’s node ID. The node ID is an integer used in the admin panel’s database, and is not related to the node “StableID” that is visible to Tailscale clients. A node’s ID is only visible in the API or admin console, by admins of either the node’s tailnet or a tailnet to which that node has already been shared. IDs are random 64-bit numbers that are not sequential or otherwise easily guessable.

The bug was introduced on 2022-09-14, reported to us on 2023-01-11, and remediated on 2023-01-12.

Who is affected?

All tailnets with nodes are affected.

What is the impact?

This vulnerability was not triggered or exploited. Analysis of tailnet logs shows that no unauthorized shares were created or accepted while the vulnerability was present, except as part of the proof of concept from the individual who reported the vulnerability.

Admins of a tailnet can review nodes that are shared out of their tailnet in the admin console. Sharing invites are logged as events in configuration audit logs. Admins can also review invites created and accepted in their configuration audit logs in the admin console.

What do I need to do?

No action is required. Tailscale has deployed a fix to the coordination server as of 2023-01-12, and verified that the vulnerability was not exploited.

Credits

We would like to thank Benjamin Roberts (tsujamin) for reporting this issue.

Reference: CVE-2022-41924

Severity: Critical

CVSS vector string: CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:H

Description: A vulnerability identified in the Tailscale Windows client allows a malicious website to reconfigure the Tailscale daemon tailscaled, which can then be used to remotely execute code.

Affected platforms: Windows

Patched Tailscale client versions: v1.32.3 or later, v1.33.257 or later (unstable)

What happened?

In the Tailscale Windows client, the local API was bound to a local TCP socket, and communicated with the Windows client GUI in cleartext with no Host header verification. This allowed an attacker-controlled website visited by the node to rebind DNS to an attacker-controlled DNS server, and then make local API requests in the client, including changing the coordination server to an attacker-controlled coordination server.

Who is affected?

All Windows clients prior to version v1.32.3 are affected.

What is the impact?

An attacker-controlled coordination server can send malicious URL responses to the client, including pushing executables or installing an SMB share. These allow the attacker to remotely execute code on the node.

Reviewing all logs confirms this vulnerability was not triggered or exploited.

What do I need to do?

If you are running Tailscale on Windows, upgrade to v1.32.3 or later to remediate the issue.

Credits

We would like to thank Emily Trau and Jamie McClymont (CyberCX) for reporting this issue. Further detail is available in their blog post.

Reference: CVE-2022-41925

Severity: Low

CVSS vector string: CVSS:3.0/AV:A/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N

Description: A vulnerability identified in the Tailscale client allows a malicious website to access the peer API, which can then be used to access Tailscale environment variables.

Affected platforms: All

Patched Tailscale client versions: v1.32.3 or later, v1.33.257 or later (unstable)

What happened?

In the Tailscale client, the peer API was vulnerable to DNS rebinding. This allowed an attacker-controlled website visited by the node to rebind DNS for the peer API to an attacker-controlled DNS server, and then making peer API requests in the client, including accessing the node’s Tailscale environment variables.

Who is affected?

All Tailscale clients prior to version v1.32.3 are affected.

What is the impact?

An attacker with access to the peer API on a node could use that access to read the node’s environment variables, including any credentials or secrets stored in environment variables. This may include Tailscale authentication keys, which could then be used to add new nodes to the user’s tailnet. The peer API access could also be used to learn of other nodes in the tailnet or send files via Taildrop.

An attacker with access to the peer API who sent a malicious file via Taildrop which was accessed while it was loading could use this to gain access to the local API, and remotely execute code.

There is no evidence of this vulnerability being purposefully triggered or exploited.

What do I need to do?

Upgrade to v1.32.3 or later to remediate the issue.

Credits

We would like to thank Emily Trau and Jamie McClymont (CyberCX) for reporting this issue. Further detail is available in their blog post.

Description: An issue in Tailscale’s implementation of the OAuth authentication flow for GitHub allowed users who authenticate to Tailscale with their GitHub user identity to create a tailnet for a GitHub organization using SAML authentication in GitHub Enterprise Cloud, where Tailscale is not an authorized OAuth app for their organization.

What happened?

Tailscale silently ignored a 403 error to the GitHub API query for organizations for an authenticated user that was returned when a user authenticated to SAML, but the organization had not authorized Tailscale. This only applied to organizations using SAML on GitHub Enterprise Cloud with OAuth app authorization enabled, and where Tailscale was not authorized.

As a result, a user identity could bypass the organization’s OAuth app access restrictions, and create a tailnet for the GitHub organization.

Who is affected?

Up to 7 tailnets for GitHub organizations on GitHub Enterprise Cloud which use SAML for authentication may have been created between 2021-06-18 and 2022-06-03 without Tailscale being an authorized OAuth app for their GitHub organization, and could have used Tailscale to connect devices in that organization. An additional 10 tailnets were created with no or only one device, and so could not have used Tailscale to connect between devices.

We have notified the Tailscale admins for the affected organizations who we were able to identify. We do not have a way to notify the GitHub organization owners.

If you’re a GitHub organization owner, you can see if Tailscale is approved for your GitHub organization by going to the organization’s settings page and selecting “Third-party access” from the left-hand navigation. Or, for an organization $your-org, navigate to

https://github.com/organizations/$your-org/settings/oauth_application_policy

What is the impact?

A tailnet may have been created for a GitHub organization without their GitHub organization owner’s approval. In this case, the use of Tailscale and the creation of a tailnet could be perceived as being sanctioned by their organization when it might not have been.

What do I need to do?

If you are affected, you will need to re-authenticate to keep using your tailnet. Tailscale has expired all admin console sessions for potentially affected GitHub organizations as of 2022-06-13. As a result, users in a potentially affected tailnet will need to re-authenticate the next time they access the admin console, and will not be able to do so without Tailscale being an authorized OAuth app, which may first require getting approval from their GitHub organization owner. Nodes in a potentially affected tailnet will also need to re-authenticate when their node keys expire. If you’re a GitHub organization owner, you can approve Tailscale as an OAuth app by following GitHub’s instructions for Approving OAuth Apps for your organization.

Tailscale has deployed a fix to the coordination server as of 2022-06-03, so that no new tailnets can be created without a GitHub organization owner’s approval.

Credits

We would like to thank Aurelia for reporting the issue. Further detail is available in their blog post.

Description: An issue in the Tailscale coordination server allowed individuals creating a new Tailscale account with a gmail.com email address to join the same tailnet, rather than individual tailnets.

What happened?

There was a flaw in Tailscale’s logic for migrating accounts between identity providers, and a new gmail.com shared tailnet was accidentally created. Once created, any user who tried to create a new Tailscale account with a gmail.com email address joined the shared gmail.com tailnet.

Who is affected?

A total of 44 users with 59 devices who created accounts for their gmail.com email addresses on 2022-05-11 between 10:56 and 13:12 PT were affected. We have notified affected users.

What is the impact?

Six connections between devices belonging to different users were made, but no traffic of concern flowed between them. Four connections were pings, and two connections were UDP traffic on port 27036, likely automated broadcasting by a gaming platform to discover peers to play with. There is no evidence of malicious traffic.

Impacted users could see some metadata about other users and devices from their devices’ clients, including users’ names, devices’ host names, and devices’ Tailscale IP addresses. This information was viewed by at least one user, who reported it to us.

One user, the tailnet Admin, was able to see all users and devices added to the shared gmail.com tailnet. This includes users’ email addresses, names, and when they were last connected; and devices’ host names, their OS and version, when the devices were last connected, and their public IP addresses. This information was viewed by the user, who reported it to us.

What do I need to do?

No action is required. Tailscale has deployed a fix to the coordination server as of 2022-05-11 13:12 PT.

New users registering for a Tailscale account with a gmail.com email address will create a tailnet as normal.

Credits

We would like to thank David Swafford and George Constantinides for reporting the issue.

Description: An issue in the Tailscale coordination server allowed individuals using GitHub to authenticate to Tailscale to have their devices join a tailnet associated with an empty GitHub username.

What happened?

There was a flaw in Tailscale’s authorization logic for the GitHub identity provider. If a user tried to authenticate to Tailscale using their GitHub identity, and GitHub returned a 500 error, then in some cases, Tailscale interpreted that as authorization for an empty GitHub username, and connected these devices to the tailnet associated with the empty GitHub username.

Who is affected?

A total of five devices belonging to four users were affected between 2021-06-15 and 2022-02-04, when the issue was reported and remediated. We have contacted the two users we were able to identify.

You may be affected if you authenticated to Tailscale using a GitHub account, and after authorizing a connection using GitHub, you received a connection error. Without being asked to select which GitHub user or organization tailnet to connect to, your device would have connected to a tailnet.

What is the impact?

No device connected to another device in the tailnet. Other than the two devices which belonged to the same user, no two devices in the tailnet had valid node keys at the same time, and so did not and would not have been able to establish connections.

A device’s existence and some metadata was shared with devices added later in time. Devices added later in time were able to see previously added devices, including: their host names, their OS and version, when the devices were last connected, and their public IP addresses.

There is no evidence of this vulnerability being purposefully triggered or exploited.

Credits

We would like to thank Marvin Boothby (boothb) for reporting the issue.