Google OAuth domain-takeover flaw (Truffle Security, Jan 2025)

Disclosed by Truffle Security in January 2025. The architectural premise of "Sign in with Google" is that the domain claim plus the email together identify a user. The claim is correct at one moment in time — but neither Google nor the relying SaaS apps track who owned that domain across time. So if domain ownership changes, the identity claim silently transfers with it.

The attack

1. A startup dies. Its domain (deadstartup.com) hits the open market.
2. Attacker buys the domain for ~$12.
3. Attacker spins up Google Workspace on deadstartup.com — Workspace let them claim the domain by serving a DNS or HTML proof, the same way the original owners did.
4. Attacker recreates the dead startup's employee emails: alice@deadstartup.com, bob@deadstartup.com, etc. (The names are often discoverable from LinkedIn, GitHub, the company's old marketing pages.)
5. Attacker visits Slack, Notion, Zoom, ChatGPT, etc., and clicks "Sign in with Google" as alice@deadstartup.com.
6. The SaaS sees: valid Google OAuth claim, matching email, matching domain. It logs the attacker in to the dead company's account — with all the historical data still present, because SaaS apps don't proactively expire data when a Workspace lapses.

The architectural problem is that neither side validates the temporal identity. Google issues a fresh OAuth claim for the email it currently sees. The SaaS apps trust the (email, domain) tuple as a stable identifier. There is no mechanism that says "this email used to belong to a different Workspace tenant in 2023." So when the email is recreated on a new Workspace, every dependent SaaS treats the new owner as the old user.

What this unlocks

Anything that the dead company SSO'd into and didn't fully wind down. In practice that includes most modern SaaS: Slack workspaces (chat history, files), Notion teams (specs, contracts, customer notes), Zoom (recorded calls), HR systems, ChatGPT workspaces, GitHub orgs that allow Google SSO, project trackers, CRMs. The thread author's framing: a $12 domain purchase is enough to reach into the old company's HR system.

The exposure scales with how many dead-or-acquired startups are out there with abandoned domains and abandoned SaaS accounts. The thread doesn't quantify the population; the implicit claim is that it's large.

Google's response

This is the part that turned the disclosure into a wider story.

• First triage: Google closed the report as "won't fix" and reclassified it from an OAuth bug to "fraud and abuse."
• Reopened: Only after the researchers' Shmoocon talk was accepted and the disclosure went public.
• Final bounty: $1,337. A meme amount (leet) for what the_smart_ape's thread calls "an industry-scale flaw."

The thread reads this as a signal beyond the specific bug: if a $12 domain purchase reaching into an old company's HR is the kind of thing the OAuth team initially classified as not-our-problem, the same team's other architectural decisions are worth re-evaluating from scratch.

Why "Sign in with Google" can't fix this unilaterally

Even with a perfect Google-side fix, the underlying problem also lives in the SaaS apps. They could check Workspace tenant continuity (the customer ID Google issues for the org), but most relying parties only look at the email and the hd (hosted domain) claim. A Google-only fix — for example, refusing to issue OAuth claims for newly-claimed domains for some quarantine window, or surfacing a "this domain ownership recently changed" signal — would mitigate but not eliminate the class.

A complete fix needs both: Google surfacing tenant-continuity information, and SaaS apps actually checking it. The thread's broader recommendation (sso-concentration-risk) — don't SSO money- or work-critical accounts through any one IdP — is the user-side mitigation while the platform-side fix isn't deployed.

See also

• smart-ape-dont-sign-in-with-google — the source thread.
• sso-concentration-risk — why this disclosure is one instance of a broader pattern.
• oauth-token-theft — adjacent attack class, different mechanism (token theft and consent phishing rather than identity transfer).