Cloudflare didn't get breached. Neither did Palo Alto Networks, Zscaler, Google, or the roughly 700 other companies whose customer data ended up in an attacker's hands starting in August 2025. Every one of them did everything right on their own systems. What got them was a chatbot plugin almost nobody in security had ever heard of, connected to a system almost every one of them trusted completely: Salesforce.
That incident, and a second wave that echoed through the same integration again in mid-2026, is turning into one of the clearest case studies of a threat that keeps catching security teams off guard: it's often not your software that gets you hacked. It's the small, unglamorous third-party app someone in sales connected two years ago and everyone forgot was there.
How a Chatbot Plugin Became a Master Key
Salesloft's Drift is a sales chatbot that connects to a company's Salesforce instance to pull customer and support data. To do that connecting, it uses OAuth — the same authorization protocol behind most of the "sign in with Google" buttons you click without thinking. You approve an app once, it's issued a token, and from then on it can access what you allowed without asking you to log in again every time.
That convenience is exactly the design flaw an attacker tracked as UNC6395 went after. Investigators traced the root cause back to a months-long compromise of Salesloft's own GitHub environment in early 2025, which the attackers used to pivot into AWS infrastructure and pull out the OAuth tokens Drift used to talk to its customers' Salesforce orgs. Those tokens didn't belong to any one victim company — they belonged to the integration itself, and every company running it had effectively handed over a spare key without realizing it.
Figure 1: The breach happened once, upstream, and the damage fanned out to every customer of the compromised integration without any of them being touched directly.
What the Attackers Actually Did
Between August 8 and 18, 2025, the attackers used the stolen tokens to authenticate directly against Salesforce's APIs — no password, no MFA prompt, because OAuth tokens skip both by design. From there they ran automated queries across support cases, contacts, and account records, quietly measuring how much data each org held before pulling the largest, most useful sets.
The real target wasn't the CRM data itself — it was what people had accidentally pasted into it. Support tickets are full of copy-pasted error logs, and error logs are full of things that should never leave a password manager: AWS access keys, Snowflake tokens, VPN credentials. The attackers combed exfiltrated support cases specifically hunting for exactly that kind of leftover secret, turning a CRM breach into a springboard for a second round of intrusions elsewhere.
Figure 2: A stolen password usually dies at the next login prompt. A stolen OAuth token just keeps authenticating, silently, for as long as nobody revokes it.
It Didn't Stay a One-Time Incident
Salesloft revoked the compromised tokens within a day of detecting the activity and pulled Drift from the marketplace entirely. That should have closed the chapter. Instead, reporting on a similar wave of activity against the same integration surfaced again in mid-2026, a reminder that once an attacker has mapped out how a trust relationship like this works, the technique doesn't expire just because one incident got cleaned up.
Some of the stolen data also resurfaced later through extortion attempts, with a group associated with the ShinyHunters and Scattered Spider crowd threatening to leak records unless companies paid up — a second wave of pressure arriving months after the original intrusion, aimed at organizations that had already believed the incident was behind them.
The Uncomfortable Pattern Underneath
- OAuth tokens rarely expire. Unlike a login session that times out, a lot of integration tokens are built to keep working indefinitely unless someone actively revokes them — which means a breach from months ago can still be silently useful to an attacker today.
- Approvals are rarely revisited. Most companies have dozens of third-party apps connected to their core SaaS platforms, approved once by someone who's since changed roles, and never audited again.
- Nobody's watching the integration layer. Security teams monitor logins and endpoints closely. API traffic from an approved, "trusted" integration usually isn't scrutinized the same way — which is exactly why the attackers here were able to run bulk queries for ten days before anyone noticed.
Closing the Gap
| Gap | Fix |
|---|---|
| Old, unused app connections still hold live tokens | Audit connected apps quarterly and revoke what's unused |
| Integrations get broad, standing access | Scope OAuth grants to the minimum data the app actually needs |
| Secrets end up pasted into support tickets or CRM fields | Scan free-text fields for credentials and strip them automatically |
Bottom Line
The scariest part of this story isn't the sophistication of the attack — there wasn't much. It's the math. One compromised vendor, one integration, one set of tokens, and hundreds of unrelated companies were exposed without a single one of them making a mistake on their own systems. Every SaaS integration your company approves is a trust decision made on your behalf, and this is what it looks like when that trust gets exploited two steps removed from anything you actually control.