Imagine opening your inbox to find a message from Google telling you that someone created a Workspace account using your email address—and may have used it to log into your Dropbox. That's exactly what happened to at least one reader who reported the incident to KrebsOnSecurity last week. The email was a heads-up about something bigger: a flaw in Google's own account creation process that let attackers bypass email verification entirely.
Google has since patched the vulnerability. But the episode raises questions about how deeply we trust "Sign in with Google" buttons across the web—and what happens when that trust gets abused.
How the Google Workspace Vulnerability Worked
The flaw sat in Google Workspace's account signup flow. Normally, creating a Workspace account requires verifying you own the domain tied to your email address. This prevents someone from, say, signing up as admin@yourcompany.com without actually controlling that domain.
According to Google's statement to KrebsOnSecurity, attackers found a way around this. They sent "specially crafted requests" during the signup process that bypassed the email verification step for Email Verified (EV) accounts. The trick? Use one email address to start the sign-in process, then supply a completely different email address to verify the token. Once that bypassed verification registered, attackers could access third-party services using Google's Single Sign-On (SSO) — essentially impersonating the domain owner.
Google told KrebsOnSecurity the malicious activity began in late June and involved "several thousand" Workspace accounts created without proper domain verification. Google says it fixed the problem within 72 hours of discovering it and added extra detection to guard against similar bypasses going forward. Importantly, Google emphasized that none of the affected domains had ever been associated with Workspace accounts before — these were purely fraudulent registrations.
Why This Matters for Teams Using Google Workspace
If your team runs on Google Workspace, this story matters for two reasons. First, it's a reminder that the "Sign in with Google" button — the one you click on countless third-party sites — inherits its security from Google's account verification process. When that process breaks, every service you've connected with Google SSO becomes a potential entry point for impersonators.
Second, attackers weren't trying to access Google's own services. They wanted to use your domain's reputation on other platforms. In the case of the reader who contacted KrebsOnSecurity, Google warned that the unauthorized Workspace account was used to log into their Dropbox. That's a classic identity spoofing play: if a service trusts Google verification, and Google's verification was fooled, the attacker walks right in.
Who Should Care
| Role | Risk Level | Immediate Action Needed? |
|---|---|---|
| Google Workspace admins | High | Yes — review admin console for unknown users |
| Teams using Google SSO on third-party apps | Medium | Check connected apps; watch for suspicious logins |
| Individual users who received a notification | High | Assume third-party accounts may be exposed; rotate tokens |
| Users who didn't receive a notification | Low | Still worth auditing connected apps periodically |
For Agile teams, this hits close to home. Many teams use Google Workspace as their backbone — Docs for sprint documentation, Drive for shared assets, Meet for daily standups. If an attacker can impersonate a team member's domain, they could potentially access project management tools, code repositories, or client portals that rely on Google SSO. The vulnerability is patched now, but the incident highlights how much workflow security depends on authentication layers you don't control.
What to Watch Next
Google's fix closed the specific gap, but authentication bypasses rarely stay unique for long. Security researchers will be watching to see whether similar techniques emerge for other cloud platforms or whether attackers adapt Google's now-public method for new targets.
There's also a subplot worth noting. Google confirmed the Workspace vulnerability is unrelated to a separate incident involving Squarespace domain hijacks that made headlines around the same time. In that case, attackers exploited weaknesses during Squarespace's migration of domains from Google Domains. Different flaw, different platform, but both incidents highlight how authentication gaps in one system can cascade into other services.
Bottom line: this particular fire is out. But the incident reinforces that your team's security posture depends not just on your own tools, but on how those tools verify users across the wider web.
Key takeaways
- Google patched a flaw that let attackers bypass Workspace email verification using specially crafted requests, creating fraudulent accounts impersonating domain owners.
- The bypass allowed attackers to access third-party services via "Sign in with Google," potentially exposing any connected apps your team uses.
- Google says it fixed the issue within 72 hours and added detection for similar bypasses; no misuse of Google services was confirmed.
- Review any recent Google notifications about account activity, and rotate passwords or OAuth tokens if you received a warning.
- Assume every "Sign in with Google" connection is only as secure as Google's weakest verification path at the time of login.
Frequently asked questions
What was the Google Workspace vulnerability about?
Google patched a flaw that allowed attackers to bypass email verification during Workspace account creation. This let them impersonate domain owners and log into third-party services using Google's Single Sign-On feature.
Was my Google account affected by this vulnerability?
Google said the vulnerability targeted Workspace accounts for domains that had never been associated with Workspace before. If you received a notification from Google about this issue, your email domain was among those used fraudulently.
What did attackers do with the bypassed Workspace accounts?
Rather than accessing Google's own services, attackers used the fraudulent accounts to log into third-party platforms that accept "Sign in with Google." In at least one reported case, this included Dropbox.
Is "Sign in with Google" still safe to use?
Google has patched the specific vulnerability. For now, "Sign in with Google" is safe to use, though the incident is a reminder to review connected apps periodically and monitor for any unexpected account notifications.
How can I check if my domain was used without authorization?
Look for any recent emails from Google about unusual Workspace account activity. You can also log into your Google Admin console and review the Users section for any accounts you don't recognize.