What to Check in Your Salesforce Org After the Klue Data Breach

In June, attackers breached Klue, a competitive-intelligence platform that revenue teams connect to their Salesforce orgs, and used the access they stole to siphon CRM data through automated queries that ran for roughly 24 hours at a time.

More than ten organizations have since confirmed their data was stolen, and several of them are cybersecurity companies that protect other businesses for a living, with multiple security firms confirming the theft publicly. Their own security programs were not the weak point, because a vendor they trusted was the way in.

It would be easy to write Klue off as a small vendor that got unlucky, but that is not what this is. Klue is a well-established competitive-intelligence platform, founded in 2015, with more than 500 customers and over 200 employees across North America and Europe. It has raised around $81 million in venture funding, and one of its backers is Salesforce Ventures. A company that established, funded in part by Salesforce itself, became the doorway into its customers’ Salesforce data. If it can happen to Klue, it can happen through any of the integrations sitting in your org right now.

I have spent more than nineteen years architecting and securing Salesforce as a Certified Technical Architect, and I want to walk through exactly what happened and, more to the point, what to check in your own org this week so the same connected-app path does not become your breach.

What happened to Klue is not a rare event anymore. Breaches that involve a third party now account for 48 percent of all breaches, a figure that climbed 60 percent in a single year, according to Verizon’s 2026 Data Breach Investigations Report. Klue is what that statistic looks like when it reaches a Salesforce org.

How attackers turned a trusted integration into a Salesforce data-theft tool

Klue syncs battlecard and win/loss data into Salesforce, which means customers granted it an OAuth connection into their orgs. The attackers did not exploit a flaw in Salesforce, and they did not break into any customer org directly. They got into Klue’s own systems using a compromised legacy credential, described by investigators as a long-disused but still-active account tied to one of Klue’s integration systems.

Once inside, they pushed a code update to that backend system that harvested the OAuth tokens customers had granted to connect Klue to their platforms. Those tokens were the keys to connected Salesforce environments, and the attackers used them to authenticate as the Klue integration itself.

From there the theft was methodical, and the pattern is worth studying because it is how these attacks usually unfold. The attackers generated OAuth tokens and ran automated scripts against the Salesforce REST API for roughly 24 hours. They first enumerated the org’s object catalog to see what was available, then looped queries against the query endpoint and paged through the results, which is the digital equivalent of walking the aisles before deciding what to take. Once they knew what they wanted, they accelerated, and in at least one environment they sent nearly a thousand queries in a 15-minute window. A legitimate integration does not behave that way, and that contrast between slow reconnaissance and a sudden burst is exactly the signal a defender can catch.

The stolen data was mostly CRM contact and sales information, and it included business contacts, price quotes, and other sales-related records. The attackers did not take source code or passwords. Business contact data is still more than enough to power convincing phishing and extortion, which is what the group calling itself Icarus is now doing as it emails ransom demands to affected customers.

The question worth asking is what could have changed the outcome. On Klue’s side, the entry point was a credential that should have been retired long before it was abused, which is the clearest argument I know of for rotating and decommissioning old secrets on a schedule. On the customer side, the amount of data each org lost depended entirely on what its Klue connection was allowed to reach, so a tightly scoped integration would have meant a smaller loss by design. Because the activity ran entirely through valid tokens and the REST API, the orgs that stood the best chance of catching it early were the ones watching their own API traffic for exactly this kind of volume spike.

Salesforce was not breached. The connected app you authorized was.

Salesforce disabled the Klue Battlecards connection quickly, and the company was clear that the issue lived in the app connection rather than in the platform itself. That statement is accurate, and it is also the point. The platform did its job, and the connection is what failed. Under the shared responsibility model, the integrations you install and the access you grant them are yours to manage.

This is also not the first time we have watched this exact attack, because Klue is at least the third trusted Salesforce-connected integration turned into a data-theft pipeline in the past year, after Salesloft Drift and Gainsight. Attackers have stopped trying to breach Salesforce directly, because one compromised middleware vendor already holds valid tokens into hundreds of orgs at once.

What to check in your own org this week

The encouraging part is that Salesforce gives you control over most of this. For a third-party integration, you first install the vendor’s app from Connected Apps OAuth Usage in Setup, which instantiates the app’s policies in your org so you can govern them, and every control below maps both to what failed at Klue and to a setting you can verify today. Salesforce restricted the creation of new connected apps as of Spring 2026 and now recommends external client apps for new integrations, and existing connected apps continue to work, so the controls below still apply to the app already authorized in your org.

Start by requiring admin approval for the app itself. The Klue attack ran through a vendor-authorized connected app, so once you have installed it you should set Permitted Users to admin-approved rather than self-authorize, and because editing that policy also revokes the app’s existing authorizations, that single change cuts off tokens already issued. From there, scope every integration to least privilege, since the amount each org lost was bounded by what its Klue connection could reach, which means an integration should be granted only the objects and fields it genuinely needs. Tokens deserve the same discipline as passwords, because the attackers relied on stolen OAuth tokens for persistent access and the default Salesforce policy keeps a refresh token valid until it is revoked, so you should set the token to expire on a schedule and expire the refresh token during any cleanup rather than assuming a password reset is enough.

Network controls close another door. On the installed app you can set IP Relaxation to enforce IP restrictions, and you define Login IP Ranges on the integration user’s profile, since Salesforce enforces the restriction only when it is configured there, and together those settings block a stolen token used from attacker infrastructure. Visibility matters just as much as configuration. The theft showed up as a burst of automated REST API queries, and Salesforce Event Monitoring records API events and baselines normal behavior so you can catch the spikes and sudden scope increases that defined this attack, including activity from non-human integration accounts. When something looks wrong, Salesforce’s own log analysis guidance shows how an ApiEvent tied to a connected app, paired with mass query operations and high row counts, is the fingerprint of exactly this kind of exfiltration, and reviewing those events confirms what an integration actually touched. Finally, inventory the connected apps and tokens you already hold, because Klue’s entry point was a forgotten legacy credential and the OAuth Connected Apps Usage page in Setup shows which apps are active and lets you revoke their tokens, and you cannot defend an integration you have forgotten you authorized.

None of this fixes the vendor’s own token handling, which is theirs to secure. What it does is shrink what a stolen token can reach in your org and shorten how long it works, which is the part within your control.

Klue caught the breach on day one, then left customers in the dark

There is one more lesson in the Klue story, and it has nothing to do with how the attackers got in. Detection was never the failure here, because Klue detected the intrusion on June 12, the same day it began. What followed shows both halves of the problem. The company did the expected containment work, bringing in incident-response firm CrowdStrike, revoking affected credentials and tokens, disabling the compromised integrations, notifying law enforcement, and removing the malicious code the attackers had planted. Those are reasonable steps. What was missing is everything that turns containment into accountability.

Klue has still not said how many of its customers were affected, its public notice went up on a page configured so search engines would not index it, it offered no detail on the unauthorized code or how long it ran, and at the time of writing it does not list anyone responsible for security on its leadership page. Affected customers largely learned their data was gone from outside researchers and from the attackers’ own extortion emails rather than from Klue.

A confirmed breach starts a regulatory clock you cannot pause

The moment a breach is confirmed, a clock starts, and for any org holding EU personal data that clock includes the 72-hour notification window under GDPR Article 33, with NIS2 adding its own 24-hour and 72-hour deadlines on top. Detection tells you something happened. It does not tell you who owns that clock, the notifications, and the evidence. That is the part where Klue stalled, and it is the part regulators and auditors care about most.

Klue lost its customers’ Salesforce data in about a day, and more than ten companies are still counting the cost. The next breach like this one is already being planned, and it will look a great deal like it. The teams who come through it well will not be the ones who somehow avoided every incident. They will be the ones who checked their connected apps before they had to, scoped their integrations, watched their API traffic, and could say without hesitation exactly who owned the response.

Klue knew on day one. Customers found out from the attackers. Detection finds the problem. Someone still has to own the response. Argus assigns a named human owner to every confirmed incident, drives it through the complete NIST response lifecycle with sign-off required before any phase advances, and produces audit-ready evidence when regulators or auditors ask for proof. See Argus in action. 

FAQ

Was Salesforce breached in the Klue attack?
No. Salesforce itself was not breached. The attackers compromised Klue, a third-party competitive-intelligence app, then used the OAuth tokens customers had granted that app to authenticate into connected Salesforce orgs through the REST API. Salesforce disabled the Klue Battlecards connection quickly, and the failure lived in the authorized app connection rather than in the platform.

How did attackers steal Salesforce data through a connected app?
The attackers got into Klue’s own systems using a compromised legacy credential, then pushed a code update that harvested the OAuth tokens customers had granted. Those tokens let them authenticate as the Klue integration and query the Salesforce REST API directly. In at least one environment they sent nearly a thousand queries in a 15-minute window, a volume no legitimate integration produces.

What should I check in my Salesforce org after a connected-app breach?
Start by requiring admin approval on the app’s Permitted Users policy, which also revokes existing authorizations. Scope every integration to least privilege so it can reach only the objects and fields it needs. Set OAuth tokens to expire on a schedule and expire the refresh token during cleanup. Enforce IP restrictions on the integration user, watch API traffic through Event Monitoring, and inventory the connected apps and tokens you already hold.

Does resetting a password stop a stolen OAuth token?
No. A password reset does not revoke an active OAuth token. The default Salesforce policy keeps a refresh token valid until it is revoked, so an attacker holding a stolen token keeps working access even after the password changes. You have to expire and revoke the token itself, which you can do from the OAuth Connected Apps Usage page in Setup.

How common are third-party breaches like the Klue attack?
Breaches that involve a third party now account for 48 percent of all breaches, a figure that climbed 60 percent in a single year, according to Verizon’s 2026 Data Breach Investigations Report. Klue is at least the third trusted Salesforce-connected integration turned into a data-theft pipeline in the past year, after Salesloft Drift and Gainsight.

Detection caught the Klue breach on day one, so why did it still go badly for customers?
Detection was never the failure. Klue identified the intrusion the same day it began, then stalled on everything that turns containment into accountability. It did not say how many customers were affected, its notice went up on a page search engines could not index, and affected customers largely learned of the theft from outside researchers and from the attackers’ own extortion emails. Detection tells you something happened. It does not tell you who owns the regulatory clock, the notifications, and the evidence.