OAuth token theft: one vendor, hundreds of firms

In August 2025, hundreds of companies learned that their Salesforce data had been stolen — even though nobody cracked their passwords or bypassed their MFA. The attackers didn’t need to: they obtained the OAuth tokens belonging to a popular marketing integration (Salesloft Drift, connected to Salesforce), and those tokens were simultaneously the key to the data of every customer who had installed that integration. It’s one of the most important incidents of the year and a textbook lesson about an underrated risk: third-party apps connected to your systems.

How this attack works (and why it’s so effective)

When you connect an external app to Salesforce, Microsoft 365 or Google Workspace via “Sign in with…” or an integration install, you issue it an OAuth token — a persistent credential that lets the app act on your behalf without logging in again and independently of your MFA. It’s convenient and entirely standard. The problem arises when a token leaks:

1. The attacker compromises the integration provider (here: infrastructure linked to Salesloft Drift) and steals its customers’ database of OAuth tokens.
2. Each such token is ready-made access to a customer’s data — no password, no MFA, no “unusual login” alert, because from Salesforce’s point of view it’s a legitimate, known app doing what it usually does.
3. The attacker mass-queries the data (in this case — Salesforce data from hundreds of companies’ instances), often hunting for further secrets: API keys, tokens to other clouds, credentials in text fields.

The result: a single compromise of one provider turns into a leak at hundreds of its customers at once. It’s the same leverage we saw with the npm worm — the scale comes from the trust we place wholesale in integrations.

Why MFA didn’t help

This is the key takeaway for boards that “invested in MFA and feel safe”. OAuth tokens by design bypass the login — they exist precisely so the app doesn’t have to re-authenticate constantly. A stolen token is access that no strong password or second factor will stop, because it operates outside that mechanism. The only thing that revokes it is revoking the consent / rotating the token — and to do that, you first have to know it leaked.

Lessons for every company

Integrations are vendors — treat them like vendors. Every OAuth app connected to your systems has access to data and is another link in the supply chain. Before you connect it: what permission scope does it request? does it really need write access and access to all records? who owns it?

Review and minimise OAuth consents. Inventory the apps connected to Salesforce, M365 and Google — in every second tenant we find forgotten integrations with broad access. Revoke the unused ones, cut scopes to the minimum. It’s the same review we recommend for shadow IT and M365 security.

Monitor token usage, not just logins. Classic monitoring focuses on user logins. Here you need visibility into app activity: unusually large data pulls by an integration, access from new addresses, record queries beyond the normal pattern. It’s an extension of security monitoring into the application layer.

Don’t keep secrets in data. The attackers mass-searched the pulled Salesforce records for keys and passwords typed into text fields (notes, descriptions). It’s a reminder that CRM data can be a trove of credentials — and those belong in a password manager, not a record comment.

Respond with rotation, not just patching. After such an incident, revoking tokens and rotating everything that could have been in the stolen data is key. It’s the same “secret theft defeats fixing” principle we saw with ToolShell.

Frequently asked questions (FAQ)

We use Salesforce/M365 with MFA. Were we safe? Not necessarily. If you had a connected integration whose tokens leaked, an attacker could read your data despite MFA — because an OAuth token operates outside the login. Security in that model depends not just on you but on the integration provider.

How do we check which apps have access to our data? Salesforce, Entra ID and Google Workspace all have “connected apps”/“enterprise applications” panels listing OAuth consents and scopes. Review them: revoke unused ones, narrow excessive ones, verify which have write access and access to full data.

What to do when an integration provider reports an incident? Treat it as your own incident: revoke and re-create consents/tokens for that integration, review app activity logs for unusual pulls in the exposure window, check whether the data held secrets to rotate. Don’t wait for confirmation of “whether it specifically affected you”.

Should we abandon OAuth integrations altogether? No — they’re too useful, and they aren’t the problem; the lack of oversight is. It’s about deliberate management: minimal scopes, consent reviews, usage monitoring and treating every integration as a vendor with data access.

How do we test this risk at our organisation? A security audit covering SaaS configuration reviews OAuth consents, integration permission scopes and the visibility of their activity — exactly the areas that decided the reach of this leak. Book a review.

Summary

The Salesloft/Salesforce token leak showed that in the SaaS era your data is only as safe as the weakest app you’ve given access to — and an OAuth token can bypass even the best MFA. The defence isn’t abandoning integrations but managing them like vendors: minimal scopes, regular consent reviews, token-usage monitoring and fast rotation after an incident. Check who your systems trust today — before someone unauthorised does it for you.

Sources and further reading: Google Threat Intelligence / Mandiant.