Three times in twelve months, attackers walked out with Salesforce data without touching Salesforce. The door they used was one your org installed on purpose.
On June 11, 2026, someone logged into the backend infrastructure of a competitive intelligence vendor called Klue using a credential that should not have existed. It was a long-disused but still active API credential, originally created by Klue to prototype a third-party integration the company later abandoned.
Nobody revoked it. Nobody was looking at it. It worked.
From there the attacker pushed a code update designed to harvest the OAuth tokens Klue’s customers used to connect the platform to Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive, and Slack. With those tokens in hand, the attacker queried those customers’ CRM systems directly and exfiltrated the data. Huntress, which published the most detailed public account on June 18, called it a security domino effect: one compromise cascading into a chain of follow-on compromises across many of Klue’s customers.
Salesforce was not breached. No Salesforce vulnerability was involved. The platform behaved exactly as designed, which is the entire problem.
What the traffic looked like
ReliaQuest’s threat research team documented the extraction pattern, and it is worth reading closely because it explains why nobody stopped it.
The attacker authenticated through a compromised Klue integration service account, generated OAuth tokens, and ran automated Python scripts identifiable by a python-urllib user agent. The scripts first enumerated the org’s object catalog through the sobjects endpoint, then looped queries against the REST query endpoint, paginating through results with the QueryMore cursor for close to 24 hours. In at least one environment the pace shifted: nearly a thousand queries inside a 15-minute window, trading stealth for speed. In another, extraction ran over six hours.
ReliaQuest’s assessment of why this ran unimpeded is the sentence worth pinning to a wall. Integrations are non-human identities with persistent, often broad access to sensitive data, and they are monitored far less closely than employee accounts. A day-long automated query loop originating from a trusted integration account did not trip the usual alarms because nothing about it looked unusual for an integration account.
There was no malware to quarantine. No malicious process to kill. The credentials were valid the entire time.
The third repetition
This was not novel. It was the third public instance of the same playbook in roughly twelve months.
August 2025, Salesloft Drift. A cluster tracked as UNC6395 stole OAuth refresh tokens from the Drift integration and used them to query Salesforce and exfiltrate data across hundreds of organizations. Zscaler and Palo Alto Networks were among the disclosed victims. The stolen tokens were valid and broadly scoped, so the attackers queried Account, Opportunity, User, and Case objects through calls that were indistinguishable from ordinary integration traffic. Because the tokens bypassed interactive login, they bypassed MFA along with it.
Late October 2025, Gainsight. Same shape. Threat actors compromised the vendor and abused that access to steal and replay valid tokens against an undisclosed number of Salesforce orgs.
June 2026, Klue. As above.
Tanium appears on both the Drift and the Klue victim lists, ten months apart, through two unrelated vendors. That is the detail that should end the argument about whether this is a vendor problem. If the response to August 2025 was to review the Salesloft connection and move on, the correct scope of the fix was never one connection.
ReliaQuest’s forward assessment is that threat actors will keep targeting third-party Salesforce-connected integrations through the rest of 2026, on the grounds that the playbook is repeatable, effective, and now widely adopted. Verizon’s 2026 DBIR puts third-party involvement as a factor in 48% of all breaches.
The part everyone skipped
Here is the fact that turns this from a lament into an argument.
Okta was a customer of Salesloft Drift. Okta was also a customer of Gainsight. Attackers attempted to use a compromised Drift token against Okta’s Salesforce instance.
It failed.
It failed because the connection originated from an IP address that was not on the allowlist, and because Okta had constrained tokens to the specific client they were issued to using Demonstrating Proof of Possession. Okta’s security team described inbound IP restriction as the single control that mattered most, and called the incident a <cite index=”127-1″>”wake-up call for the entire SaaS industry.”</cite>
Two vendor compromises, same customer, both stopped at the door.
Every control involved is a native Salesforce feature that has existed for years. Connected App settings support IP relaxation set to enforce restrictions. API Access Control lets an admin allowlist which connected apps may reach the org at all and block everything else. Permitted Users policy can be set so that only admin-approved users are pre-authorized rather than allowing users to self-authorize. Scopes can be narrowed below full access. Integration identities can be dedicated users with object and field level restrictions rather than credentials riding a broad profile.
None of this is exotic. None of it requires a product purchase. It requires someone to have decided that a connected app is a privileged identity and to have configured it accordingly.
Okta’s own account of the Gainsight incident includes an uncomfortable adjacent point: their security architecture team publishes baseline expectations for the SaaS providers they use, many providers have adopted them, and some have not, so Okta keeps applying pressure. That is the posture. Not trusting the vendor’s security program. Verifying it, and constraining the grant regardless of the answer.
The architectural version of the same point
Everything above is configuration, and configuration is the right immediate answer. But there is a design question sitting underneath it that most orgs never get asked.
A standing OAuth grant from an external system into your org is an architectural choice. It is frequently the correct one. It is almost never examined as a choice, because it arrives bundled with a purchasing decision that was made on functional grounds by people who were evaluating features.
The grant has properties independent of the product that holds it. It persists. It survives the vendor’s employee turnover, their acquisition, their abandoned prototypes, and their credential hygiene. It carries whatever scope was convenient at install time, usually more than the use case requires, because narrowing scope is work and broad scope always functions. And it sits at the far end of a network boundary you do not administer.
That last property is the one that matters. When functionality runs as a native managed package inside the org, there is no persistent external token to steal, because there is no external system holding one. The code runs under the platform’s own security model, subject to the org’s sharing rules, its permission sets, its field level security, and its audit trail. That is not a claim that native architecture is secure by default. Badly built native packages exist in quantity. It is the narrower and more defensible claim that a native package does not participate in this specific failure mode, because the artifact the attacker needs is not there to take.
Every integration is a judgment about whether the functional benefit is worth adding a permanent, externally-held key to your data. Sometimes it plainly is. The failure is not answering yes. The failure is never asking.
What to actually do
Three tiers, in order of how fast they can be done.
This week. Produce the inventory. Every connected app, every OAuth grant, every integration service account, with a named owner and a business justification for each. Anything dormant or unowned gets revoked. The credential that opened Klue was an abandoned prototype, and most estates are carrying their own equivalents from proofs of concept nobody decommissioned. If the list cannot be produced today, that absence is the first finding.
This month. Enforce IP restrictions on integration connected apps and get egress ranges from every vendor that has a grant. Turn on API Access Control so unapproved connected apps are blocked rather than merely unused. Strip API Enabled from broad profiles and grant it through targeted permission sets. Narrow scopes to the minimum the integration actually needs, then verify the integration still works, because the answer is frequently that it needed less than it asked for.
Ongoing. Monitor the API layer, because that is where the entire attack lives. Event Monitoring should be alerting on anomalous query volume from integration accounts, repeated pagination through large result sets, unfamiliar user agents, and access from unexpected infrastructure. Revocation procedure matters too: killing the refresh token is what severs persistent access, not resetting a password. And add the security questions to procurement, so the grant gets evaluated when it is being created rather than after somebody else’s dormant credential turns up in an incident report.
Then run the architectural review. For every standing grant, ask whether that capability could live inside the platform instead. Often the answer is no and the grant stays, now properly scoped and monitored. Sometimes the answer is that a native package would do the same job without the permanent key, and that is a build decision worth pricing.
The pattern is stable enough now to plan against. The vendor will be somebody nobody flagged as high risk. The credential will be old. The traffic will look legitimate the entire time. The only variables an org actually controls are how narrow the grant was, whether the token could be replayed from arbitrary infrastructure, and how quickly anyone noticed.
Those are all decisions, and all three can be made before the next one.
Resource Interactive builds native Salesforce applications and treats every external grant as an architectural decision requiring a defense, on the theory that the safest integration is frequently the one that turned out not to be necessary.
Sources
- ReliaQuest Threat Research, “Klue Integration Abused in Salesforce Data Theft,” June 17, 2026, updated June 22, 2026
- Huntress, “Cybercrime Breaches Klue: Salesforce Data Impacted for Many Victims, including Huntress,” June 18, 2026
- Help Net Security, coverage of the Klue incident, June 19 and June 24, 2026
- Okta, “First Drift, now Gainsight: Closing the gaps in SaaS hygiene,” November 2025
- The Hacker News, “Google Warns Salesloft Drift Breach Impacts All Drift Integrations Beyond Salesforce,” September 2025
- Salesforce Help, “Restrict Access to APIs with Connected Apps”
- Verizon, 2026 Data Breach Investigations Report
Leave a Reply