Full Report
New research has pulled back the curtain on a "deficiency" in Google's "Sign in with Google" authentication flow that exploits a quirk in domain ownership to gain access to sensitive data. "Google's OAuth login doesn't protect against someone purchasing a failed startup's domain and using it to re-create email accounts for former employees," Truffle Security co-founder and CEO Dylan Ayrey said
Analysis Summary
# Vulnerability: Google OAuth Flaw Allows Account Takeover via Reclaimed Startup Domains
## CVE Details
- CVE ID: Not explicitly provided in the text.
- CVSS Score: Not explicitly provided in the text.
- CWE: Not explicitly provided in the text, but relates to insecure direct object reference or failure in authentication logic dependent on domain ownership.
## Affected Systems
- Products: Applications and SaaS platforms relying on Google's "Sign in with Google" (OAuth) for authentication, including OpenAI ChatGPT, Slack, Notion, Zoom, and HR systems.
- Versions: Any application utilizing Google OAuth flow that relies solely on Google ID token claims (specifically email address and hosted domain) for user authentication without further validation.
- Configurations: Organizations whose former domains, registered under Google Workspace/G Suite, have been officially retired or expired and subsequently purchased by a third party who re-creates associated email accounts.
## Vulnerability Description
The vulnerability stems from a deficiency in how Google's "Sign in with Google" authentication flow handles domain ownership changes following a company's dissolution. When an application relies on the claims provided by Google's OAuth ID token—specifically the user's email and associated domain—to authenticate a user, an attacker who acquires a failed startup's expired or relinquished domain can re-create the former employee email addresses under their control. By associating these recreated emails with new Google Accounts, the attacker can trick the relying application into issuing an access token or relying on the domain claim to grant unauthorized login access to the old employee accounts across various integrated SaaS applications. This grants access to sensitive historical data.
## Exploitation
- Status: Proof of Concept/Demonstration described (Implied exploitation via domain squatting).
- Complexity: Low to Medium (Requires successful domain reclamation and re-creation of associated email addresses).
- Attack Vector: Network (Relies on manipulation of the OAuth trust mechanism during login).
## Impact
- Confidentiality: High (Potential access to SSNs, tax info, pay stubs, candidate feedback via re-accessed HR/Interview systems).
- Integrity: High (Ability to modify or delete data within accessed SaaS applications that an former employee previously controlled access to).
- Availability: Low (The primary impact is data exposure, not system denial).
## Remediation
### Patches
- No specific patch version provided, as the issue appears to be a design flaw in how relying parties consume third-party identity data. **Action required by Relying Parties (SaaS providers/Apps).**
### Workarounds
1. **Relying Parties:** Implement stronger post-authentication checks beyond just verifying the Google ID token claims. Relying applications should validate the authenticated user against their current, canonical user directory or actively check that the domain claim still corresponds to an active, vetted customer entity.
2. **Organizations:** Implement multi-factor authentication (MFA) across all critical SaaS applications. Decommission old corporate Google Workspace instances immediately upon company failure to prevent domain expiration and subsequent acquisition.
## Detection
- Indicators of Compromise: Look for authentication attempts via Google OAuth originating from previously inactive or disassociated domains. Anomalous access patterns or logins to historical/archival employee accounts.
- Detection Methods and Tools: Monitoring of identity and access management (IAM) logs for successful logins relying on domain verification that is no longer corporate-controlled.
## References
- Vendor Advisories: Research documented by Truffle Security.
- Relevant links:
- hxxps://trufflesecurity.com/blog/millions-at-risk-due-to-google-s-oauth-flaw
- hxxps://thehackernews.com/2025/01/google-oauth-vulnerability-exposes.html