If you spent any part of 2025 watching attackers march through the Salesforce ecosystem, the headlines from June 2026 will feel familiar. A trusted third-party platform gets compromised. Attackers quietly lift the OAuth tokens that connect it to customers' Salesforce environments. Then they pivot — org by org — into the CRM data of dozens of well-defended companies, exfiltrate it, and follow up with extortion.
This time the entry point is Klue , a market intelligence and competitive-enablement platform whose products integrate with Salesforce. And the playbook is almost a carbon copy of the one that defined last year's Salesforce breach wave.
The lesson security teams should take from it isn't "patch Salesforce." Salesforce wasn't breached. The lesson is that preventing every initial compromise is no longer a realistic goal and that the metric that actually matters is blast radius: when a trusted integration is compromised, how much of your sensitive data is sitting there to be taken?
What happened at Klue
On June 12, Klue identified unauthorized activity affecting part of its integration infrastructure. Their investigation determined that an attacker got in through a compromised legacy credential tied to an integration service. From there, the attacker obtained the OAuth tokens Klue uses to connect with third-party Salesforce platforms to then steal data from inside the connected customer environments.
The core mechanics were independently detailed by several security firms, who identified the attackers leveraged the stolen tokens to run various Python scripts against the Salesforce API over extended periods to pull data out.
No Salesforce zero-day — just a legitimate, trusted integration turned into a quiet siphon.
A victim list that keeps growing
What makes this incident notable isn't a single breached company. It's the blast radius. Because Klue sat as a trusted, connected app inside many organizations' Salesforce instances, one compromise opened the door to many environments at once. The roster of confirmed victims can be tracked here .
The pattern across nearly every disclosure is consistent: the theft was limited to CRM and business data inside Salesforce: contact names, email addresses, phone numbers, job titles, account and opportunity records, sales notes, and in some cases support-case metadata.
At least one organization publicly acknowledged finding a limited number of credentials and secrets embedded in its CRM data and had to rotate them.
Why these attacks keep working
Salesforce itself wasn't hacked. Again. The same was true of the Salesloft Drift campaign in August 2025, when attackers tracked by Google as UNC6395 stole OAuth tokens from the Drift integration, used them to access hundreds of Salesforce customer environments, and systematically exfiltrated CRM data while searching for embedded credentials and secrets. Several major software and cybersecurity vendors later disclosed they had been affected. The pattern repeated in November 2025, when compromised Gainsight applications exposed Salesforce data from more than 200 customer environments
The throughline isn't a flaw in the platform. It's the trust model around it. Modern SaaS runs on a web of integrations, each holding broad, long-lived OAuth tokens that act like standing keys to the data behind them. To Salesforce, traffic from a connected app looks like authorized activity from a partner the customer chose to trust. Compromise one widely deployed integration and you inherit access to everything it touches.
Two conditions make the payoff enormous:
- Standing access (tokens and permissions that are always on, rarely scoped down) and
- Data accumulation (sensitive records and files that pile up in the CRM and never leave).
Strip those two conditions away and the same compromise yields far less.
Minimizing the blast radius with SendSafely
You can't guarantee a trusted vendor never gets breached or an employee never gets phished . What you can control is how much damage a successful intrusion does. SendSafely is built around exactly that idea, and it rests on two principles that map directly to the conditions above.
Minimize the sensitive data that's there to steal. The most secure data is the data you never store — and the data an attacker can't read is nearly as good. SendSafely layers three controls that shrink what a compromised Salesforce integration could ever reach:
- End-to-end encryption. Files are encrypted before they're ever transmitted, so no intermediary — not Salesforce, not your 3rd party CRM integrations, and not SendSafely itself — can read the contents.
- Use your own storage, outside Salesforce. Encrypted files can be kept in your own cloud storage (such as your own S3 bucket) rather than inside Salesforce. The attachments customers share aren't sitting in the CRM for a compromised integration to query and export.
- Automated data expiration and deletion. SendSafely administrators can enforce organization-wide data expiration windows . Once the window closes, the access link is disabled and the data is deleted shortly after. Data that no longer exists can't be leaked, ransomed, or pulled through a stolen token.
Enforce least privilege and just-in-time access. Viewing a record shouldn't automatically unlock every file ever attached to it. SendSafely separates case access from file access, and automatically adjusts permissions as work moves , granting access when a case is assigned and revoking it when the case is closed or reassigned. This greatly limits what a compromised account can reach, and protects the back catalog of every closed case.
The bottom line
Salesforce is back in the crosshairs not because the platform is weak, but because the connections feeding into it are the softest, most rewarding target left. Attackers have proven, from Drift to Gainsight to Klue, that they'll keep coming through that door. Strong MFA, monitoring, and access reviews reduce the odds that the initial compromise succeeds. They're necessary. But they don't address the question that decides how bad the breach actually is: when someone does get in, what's waiting for them?
With SendSafely, the answer is: a lot less. Sensitive files stay encrypted and out of Salesforce, access is scoped to the work at hand and expires on its own, and there's no central store of standing credentials for an attacker to steal. The initial compromise becomes a contained event instead of a headline.
SendSafely Halo: The Trust Layer Between Your Data and Your AI Stack
Want to see how SendSafely contains the blast radius of an attack on your Salesforce environment? Contact us at sales@sendsafely.com or schedule a live demo.
