A newly disclosed Google OAuth vulnerability allows former employees to retain access to corporate resources like Slack and Zoom, even after suspending their corporate Google accounts. Here’s what it means for your SaaS security posture and how Nudge Security can help.
Refreshed and updated on August 4, 2025.
‍
OAuth is supposed to simplify security, not bypass it. But under the surface of every "Sign in with Google" button lies a little-known vulnerability that’s giving attackers and ex-employees a free pass into your corporate SaaS apps.Â
‍
No phishing and no malware are required. Just a clever use of Google’s own aliasing system to stay logged in long after they’ve left the building.
‍
It’s not hypothetical. It’s happening today, and most IT teams have no idea it’s going on. If you’ve ever offboarded an employee, revoked their access, and assumed the door was shut, you may want to double-check. Because shadow Google accounts could be keeping that door wide open.
‍
‍
It’s a well-known work email hack: add “+string” to your work email address (e.g., [email protected]) and you can easily filter any unwanted marketing emails or create multiple different signups for a single app using your work email address.
‍
However, this same trick can be used to create an entirely new Google account—one that looks like a corporate email address and forwards messages to it, but isn’t actually managed or even visible within your corporate Google organization.
‍
This creates a big problem when it comes to offboarding employees. If a given “shadow Google account” were used to sign up for corporate SaaS accounts like Slack or Zoom using Google OAuth (i.e., “Sign in with Google”), that access could persist even after suspending the employee’s corporate Google account. Effectively, there’s no way for a Google administrator to see or suspend the shadow Google account from their admin console. This could leave a back door for unauthorized access by a former employee or threat actor by compromising the shadow account.
‍
That’s the TL;DR of a Google OAuth vulnerability publicly disclosed by Truffle Security Co on Saturday, December 16, 2023.
‍
While I won’t re-hash all of the details from Truffle Security’s excellent blog post (def. read it), it’s important to understand how this vulnerability could impact your SaaS security posture, which of your SaaS providers may have been affected, including Nudge Security, and how you can use Nudge Security to detect and respond to activities related to this vulnerability.
‍
This vulnerability relates to how SaaS providers implement Google OAuth, which isn’t exactly obvious or intuitive. Buried in Google’s OIDC documentation, it advises against using a user’s email address as the primary identity for a user record in your SaaS application and using the HD claim instead.
‍
However, many SaaS providers do this, including Slack and Zoom, as the Truffle Security blog post notes. The challenge for organizations is that there’s no obvious, apparent way to know which of their SaaS vendors may be impacted by this vulnerability—other than by reaching out to each SaaS provider directly.
‍
Yes. Our implementation of OIDC follows the same pattern as the many other SaaS providers affected by this vulnerability. In December 2023, we released an update to safeguard against this vulnerability. Nudge Security validates the HD claim (host domain) as part of the account creation process.
‍
It’s good to know that by default, Nudge Security uses a “request access” provisioning process for platform users, which the vast majority of our customers use. With this method, your Nudge Security administrator must first review and approve the access request to Nudge Security.
‍
Following the disclosure of this vulnerability, we proactively investigated our customer environments and have found no evidence of accounts being created using this technique, apart from known testing accounts.
‍
While no exploits of this vulnerability have been reported to date, the potential for exploit extends to unauthorized access, data exfiltration, and even full account takeover attacks. Consider a scenario wherein an employee creates a “shadow Google account” to sign up for a business SaaS application with administrative privileges. That shadow Google account, which is not protected or monitored by the organization’s security program, is later compromised, giving the threat actor full access the SaaS application and its data.
‍
This vulnerability underscores the major shift that’s taken place in modern cybersecurity. Given that most organizations use hundreds of SaaS applications, many of which are administered by business users outside of IT, it’s a growing challenge for IT security teams to maintain visibility and control of who (and what) has access to corporate data and how. Organizations need visibility of SaaS identities and activities beyond (and in addition to) their centralized cloud identity provider or SSO solution.
‍
So, how do you begin to address this vulnerability?
‍
According to the Truffle Security post, “all you have to do is disable login with Google, and strictly enforce SAML. This actually works for most service providers, however some don’t offer this option, and you may also have some internally developed applications that are impacted and don’t support SAML.”
‍
Unfortunately, this path isn’t practical for most organizations. As noted, it doesn’t fully address all SaaS applications that might be in use across the organization, as SAML support varies by SaaS provider.
‍
Here’s how you can detect the creation of shadow Google accounts from the Google admin console. Note: You may need an enterprise license to access the Security Center.
‍
‍
Nudge Security discovers these email events as part of our powerful email analysis, so you can discover these activities, in the past and as they occur.
‍
To review shadow Google accounts in Nudge Security, navigate to the Apps dashboard. Find your Google Workspace application. Navigate to Resources, and filter by Account Alias. Here, you’ll see a list of all the shadow Google accounts created using your domain.
‍
1. Domain takeover = Renewed access
If an attacker buys a former employee’s personal domain (or an unused corporate domain), they can recreate a shadow account and regain access to OAuth-connected tools. This makes dormant accounts a potential ticking time bomb.
2. Shadow IT extends beyond Gmail
This issue goes far beyond Google accounts. Shadow IT now includes:
‍
3. Google is taking action
As of June 2025, Google will start automatically deleting unused OAuth clients after six months of inactivity. This reduces one avenue of risk, but it doesn’t address alias account persistence, which remains an enterprise responsibility.
‍
‍
We’ll continue to update this blog as we learn more, and we’ll share additional updates via X and LinkedIn.
‍
If you’re not yet a Nudge Security customer, you can start a free 14-day trial and review your organization’s shadow Google accounts right away. Our trial will also allow you to see every cloud and SaaS asset created by your workforce and review all OAuth grants and scopes between apps.
