Salesforce's OAuth problem comes back through Klue

Salesforce spent the back half of 2025 cleaning up after a run of OAuth-token thefts, and the first one of 2026 to make real noise arrived through a vendor most people outside competitive-intelligence teams have never heard of. On 11 June, Salesforce disabled the Klue Battlecards integration after a security incident at Klue. By 19 June, an extortion crew calling itself Icarus — active since around April — had listed Klue on its leak site. The pattern underneath it is the one defenders should care about, because it has now repeated three times in a year with three different third parties in the middle.

Here is what happened, in plain terms. Klue is a competitive-intelligence platform that connects to its customers’ Salesforce instances so it can pull and push sales data. That connection is authorised with OAuth tokens — long-lived credentials that let Klue’s systems talk to Salesforce on the customer’s behalf without anyone logging in each time. Icarus compromised Klue, harvested those tokens, and used them to run automated REST API queries against the connected Salesforce tenants, exporting CRM data at volume. Reporting and the post-incident analysis from ReliaQuest and Obsidian name Huntress, Jamf, Recorded Future, Tanium, Gong, Insurity and Sprout Social among the affected. The grim irony that several of those are themselves security firms is not lost on anyone.

The mechanism is worth slowing down on, because it is the whole story. Nobody phished a Klue customer. Nobody defeated anyone’s multi-factor authentication. Nobody guessed or stole a single Salesforce password belonging to the victims. The attacker compromised one supplier sitting in the middle of dozens of trust relationships and inherited standing, pre-authorised access to every Salesforce tenant downstream of it. That is the same shape as the Salesloft Drift campaign in August 2025, where UNC6395 lifted OAuth refresh tokens and queried Salesforce across hundreds of organisations, and the ShinyHunters vishing wave before that, where employees were talked into authorising a malicious connected app. Different vendor each time. Same architecture being abused each time.

There is a secondary blast radius that the Drift campaign made famous and that applies here too. Salesforce support cases and CRM notes are full of things that were never meant to be secrets-at-rest: API keys, snippets of credentials, internal hostnames, the occasional password a support agent pasted in to reproduce a problem. When an attacker exports the case text wholesale, the CRM theft becomes a credential-harvesting exercise with a second hop into cloud and SaaS environments. The data that leaves Salesforce is rarely the end of the incident.

The thing that makes this class of attack so effective is that the abused credential lives in everyone’s blind spot. A third-party OAuth token is a privileged identity that your organisation issued, usually at the point one team trialled a tool, and then stopped watching. It typically does not expire on its own. It is frequently granted far broader scope than the integration actually needs, because the consent screen offered “full access” and somebody clicked accept. And — this is the part that matters — it sits entirely outside the identity controls most security programmes are built around. Your MFA, your conditional access, your SSO policies govern humans logging in. They do nothing about a token-bearing machine integration that was authorised months ago. The trust path runs around your strongest controls, not through them.

What defenders should learn from this is less about Klue specifically and more about the connected-app surface as a whole, and this is where a segmentation and least-privilege lens earns its keep. The questions worth asking before the next vendor in this chain gets popped: which connected apps in your Salesforce org actually hold a live, valid token right now; what OAuth scopes does each of them carry, and is that scope the minimum the integration needs or the maximum the consent screen offered; and is there any monitoring that would flag a single integration suddenly pulling tens of thousands of records when its normal behaviour is a trickle. Most organisations cannot answer the third question, because API-level data-egress from a trusted integration looks exactly like the integration doing its job. Treating connected apps as the privileged identities they are — inventoried, scoped down, rotated, and watched for anomalous volume — is the work this keeps pointing at. Klue is the third reminder in twelve months. It will not be the last.