Your Salesforce wasn't breached. A connected app handed over the data.

Salesforce was not breached. The platform held, the same way it held when Salesloft Drift was abused and when Gainsight was abused. What gave way this time was a connected app called Klue, and the OAuth tokens it held to read its customers' Salesforce data. An extortion crew that calls itself Icarus walked through that door, ran automated queries against the CRM for roughly a full day, and walked out with sales contacts, price quotes, and account records belonging to multiple companies, including several security vendors.

If your team has ever clicked "Connect to Salesforce" on a third-party tool, this is your attack surface, and almost nobody is watching it.

What actually happened with Klue

Klue makes competitive-intelligence "battlecards" that plug into Salesforce and a long list of other SaaS tools. According to Salesforce, it disabled the Klue integration platform-wide on June 11, 2026, after a security incident at Klue. Klue itself caught the intruder a day later, on June 12, inside the systems that run those integrations. On June 16, employees at Huntress started receiving extortion emails carrying a 48-hour deadline.

The entry point was not a Salesforce flaw and not a clever zero-day. Investigators at ReliaQuest, the firm that uncovered the campaign, traced it to a dormant credential Klue had created for a prototype integration and never decommissioned. That stale account was still live. The attackers used it to reach Klue's environment, generated OAuth tokens, then ran automated Python scripts that queried Salesforce's REST API for close to 24 hours, enumerating objects and bulk-exporting records. Salesforce was blunt that the issue lived in Klue's app connection, not in Salesforce itself.

The two accounts differ on one detail worth flagging. The Hacker News frames the theft as tokens generated from the compromised service account. BleepingComputer reports the attackers also pushed a malicious code update into Klue's backend that harvested customer OAuth tokens directly. Both agree the dormant credential was the way in and OAuth tokens were the payout; whether the tokens were minted or skimmed is the open question.

Icarus is new. ReliaQuest says the group launched around April 2026 and had listed only two victims before this campaign. The tradecraft looked enough like the ShinyHunters Salesforce extortion campaign that early reporting drew the comparison, but BleepingComputer is clear that ShinyHunters was not behind this one. Huntress confirmed the thieves reached business contacts and sales data, but not threat intelligence, customer telemetry, passwords, or engineering systems.

Three breaches, one trust boundary

Look at the sequence. Salesloft Drift. Gainsight. Now Klue. In every case the headline names Salesforce, and in every case Salesforce's own platform was never the thing that broke. The constant is the OAuth grant a customer hands to a third-party app, and the fact that this grant lives outside almost every control a security team applies to its own people.

This is the part defenders keep underrating. A connected app's token does not get prompted for MFA. It is not subject to your conditional-access policy. It rarely expires on a schedule anyone tracks, and it is usually scoped far wider than the app needs because nobody pushed back during the procurement demo. A stolen connected-app token is a skeleton key with none of the friction a stolen employee password would hit. That is why 24 hours of bulk API extraction can run to completion without tripping a single alarm.

The victim list makes the second point for me. Huntress, Recorded Future, Tanium, and Jamf all confirmed stolen Salesforce data, and every one of them is a security company. They are not the soft targets in anyone's threat model. If firms that hunt this exact behavior for a living got their CRM data pulled through a vendor's token, the lesson is not "be more mature." You cannot out-mature your vendors' credential hygiene. Connected-app sprawl is a procurement problem that lands as a security incident, and the security team usually finds out after the extortion email.

Why the dormant credential keeps being the root cause

Strip away the brand names and these incidents are non-human identity lifecycle failures. A credential gets created for a test, a prototype, a one-time migration. The project ships, the people move on, and the credential is never revoked. Months later it is the quietest path into a system that real customers depend on. We saw the same shape when malicious third-party plugins stole developer credentials and when a trusted vendor pushed a backdoored update.

Human accounts get offboarding workflows. Service accounts, integration credentials, and OAuth grants mostly do not. There is no leaving-the-company trigger for a token, so it sits until someone audits it or an attacker finds it first. The Klue prototype credential is the same species of mistake as a forgotten CI deploy key or an old personal access token with org-wide scope, the same class of token expiration and session revocation gaps defenders keep rediscovering.

What to do this week

Treat this as today's work if you run Salesforce or any CRM with connected apps.

• Revoke and rotate. Pull the OAuth tokens for Klue and any integration you do not actively need, and terminate active sessions. ReliaQuest published four attacker IP addresses; check your Salesforce and SaaS logs for API activity from them.

• Inventory your connected apps. Pull the full list of OAuth-authorized apps in Salesforce and every major SaaS tenant. Most teams have never looked. You will find apps nobody remembers approving.

• Cut the scopes. An app that needs read access to contacts should not hold a token that can bulk-export every object. Re-grant on least privilege, even where it means a support ticket with the vendor.

• Alert on app-identity behavior, not just human logins. A connected app enumerating objects and running bulk REST queries for hours is a behavioral signature distinct from human CRM use. Salesforce event monitoring can surface it; the gap is that almost no one alerts on API volume tied to an app identity.

The uncomfortable read here is that this pattern is not slowing down. The Salesforce integration marketplace is enormous, every connected app is a credential holder, and Icarus just proved a four-month-old crew can monetize one stale token. Expect the next name in this sequence within weeks, and expect the platform to be innocent again. The question worth asking in your own environment is simpler than attribution: which of your vendors could lose a token tonight, and would you see it before the email arrived?