Klue OAuth Hack Hits Salesforce CRM | Salesforce Dictionary

Salesforce killed the connection at 7:22 p.m. BST on June 17, 2026. Klue Battlecards, the competitive intelligence app, lost its OAuth link to every Salesforce org it touched. No warning to customers. No grace period. The reason became public two days later: an attacker had been pulling CRM data out of connected orgs using a stolen token, and cybersecurity firm Reliaquest had caught it.

Here is what happened, why it worked, and the cleanup task sitting in your org right now.

What got disabled and why

Klue is an AI-powered competitive intelligence platform with roughly 500 customers, including Adobe, Dell, and Shopify. Its core product, Battlecards, syncs with Salesforce so sales teams can pull competitor positioning into deals. To do that, Klue holds an OAuth grant in each customer org.

One of those grants was the problem. Salesforce disabled the integration across all connected orgs once the compromise was confirmed. The company was direct about scope: "This issue is limited to Klue's app connection and does not arise from a vulnerability within the Salesforce platform." That is accurate. Nothing in the Salesforce API was broken. The attacker used a credential that was working exactly as designed.

Permiso Security researchers named the attack "Icarus." The name fits. Klue flew on an old token it had forgotten about, and the whole thing came down fast.

The three stages of Icarus

The attack ran in three stages, and each one is worth understanding because the pattern repeats across vendors.

Stage 1: Token acquisition. The attacker obtained a long-lived OAuth refresh token from Klue's infrastructure. The detail that matters: this token belonged to a deprecated integration Klue had stopped using but never revoked. The code was dead. The credential was not. Klue did not disclose the exact compromise vector, so it is not clear whether it came from phishing, an exposed code repository, or a direct breach of Klue systems. The vector is almost beside the point. What mattered was that a valid token existed and nobody had killed it.

Stage 2: Authorization exploitation. The token still carried its original OAuth scopes: read access to Salesforce accounts, contacts, opportunities, and custom objects. Klue had functionally discontinued the integration on its side, but the authorization grant living in each customer's Salesforce org stayed active. This is the part most teams get wrong. Turning off an integration in the vendor's product does nothing to the grant sitting in your org. The grant is yours. It survives until someone in your org revokes it.

Stage 3: Exfiltration. With a valid token and live scopes, the attacker ran bulk SOQL queries and pulled tens of thousands of records. Salesforce anomaly detection eventually flagged the behavior, but only after roughly 15 minutes per org. Fifteen minutes of bulk reads is a lot of data. By the time alerts fired, the damage in each affected org was already done.

What was exposed

The data the attacker could reach maps directly to the OAuth scopes on that token. This was not a partial leak of one object type. It was the commercial core of a CRM.

The exposed records included opportunity pipeline values and deal stages, account and contact information, competitive battlecards with structured competitor positioning documents, and buying committee and decision-maker details.

The battlecards are the specific sting. Klue's entire product is competitive intelligence. The integration was purpose-built to sync CRM signals with competitive positioning. An attacker with access to that data gets a view of your active deals, the competitors you are tracking, and how you plan to beat each one. For a competitor or a data broker, that is the whole game.

Why the usual controls did not help

The hard lesson from Icarus is that your security perimeter assumed the attacker would knock on the front door. They did not.

A valid OAuth token bypasses multi-factor authentication. It bypasses IP restrictions. It bypasses session timeout controls. None of those mechanisms get a vote, because the API treats a valid token as a valid token. The whole point of OAuth is that the user already authenticated once and granted access, so the integration does not have to re-prove itself on every call. That is convenient when the integration is trusted. It is dangerous when the credential walks out the door.

So MFA on your user accounts did nothing here. The attacker never logged in as a user. They authenticated as an application that your org had already authorized, using a token your org had never told to stop working.

This keeps happening

If Icarus feels familiar, that is because it is. The same OAuth-abuse pattern hit SalesLoft and Drift in prior years. Different vendors, same mechanism: a third-party integration's credential gets compromised, and that credential carries broad read access into connected Salesforce orgs.

Reliaquest, the firm that detected the Klue compromise, stated that OAuth-abuse campaigns will remain a primary attack vector. The economics favor the attacker. One compromised vendor token can fan out across hundreds of customer orgs, and most of those orgs have no idea how many active grants they are carrying or how old they are.

Coverage from Salesforce Ben framed this as "another OAuth hack" for a reason. Their running 2026 hacks tracker now lists Klue alongside earlier incidents. The technical breakdown at SFDC Developers and the Icarus analysis at gblock.app land on the same conclusion. The vulnerability is not in Salesforce. It is in the pile of forgotten authorizations sitting in nearly every enterprise org.

The dormant grant problem

Here is the uncomfortable part. Most enterprise Salesforce orgs have dormant, never-revoked OAuth authorizations from vendors they stopped using months or years ago. Someone evaluated a tool, connected it, the trial ended, the contract lapsed, and the grant stayed. Nobody revoked it because nobody owns the list.

Each one of those grants is a Klue waiting to happen. The integration does not need to be active on the vendor's side. The grant in your org is what the attacker uses, and that grant outlives the relationship until you act.

This is a housekeeping problem that became a security problem. The fix is not complicated. It is an audit.

What to do now

Stop reading and open Setup. This takes one administrator an afternoon, and it is the single highest-value security action available to you this week.

Go to Setup, then Connected Apps OAuth Usage, and export the full list. Look for anything with a last-activity date that does not match current usage, anything from a vendor you no longer use actively, and anything that was authorized for a trial or proof-of-concept you never committed to.

For every grant you can confirm is active and necessary: check that its OAuth scopes are limited to what the integration actually needs. If an integration only reads accounts and contacts, it should not also have access to opportunities and custom objects.

Revoke any token tied to a dormant, deprecated, or decommissioned integration. In Salesforce, that is OAuth usage revocation under Setup. On the vendor side, rotate the connected app credentials as well.

If you are a Klue customer, contact Klue directly to determine whether your specific org was among those affected, what records were within scope, and what remediation Klue is providing. Do not wait for a breach notification to arrive on its own schedule.

Make the connected apps audit a recurring calendar item, not a one-time reaction to this incident. Quarterly is reasonable for most orgs. The grants accumulate whether or not you are watching, and the next compromised vendor will not send advance notice.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.