Back in April we covered what the Mythos leak taught us about Salesforce third-party risk–a contractor’s access becoming someone else’s entry point. In May we argued your org needs a bouncer checking IDs at the door instead of handing every vendor a key. The Klue breach is both warnings landing at once: a four-year-old credential at a single vendor exposed Salesforce CRM data for roughly 195 companies–including security vendors like Huntress, Recorded Future, HackerOne, LastPass, Tanium, Jamf, Snyk, and OneTrust.

What Actually Happened

Klue, a competitive intelligence platform used by sales and product marketing teams, created a credential in 2022 for a prototype integration it later abandoned–but never deactivated. On June 11, attackers used that legacy credential to push a code update into Klue’s integration infrastructure. The malicious code harvested the OAuth tokens Klue’s customers had granted it to connect to their own systems: Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive, and Slack.

Armed with those tokens, the attackers didn’t need Klue anymore. They impersonated Klue inside customer environments, querying CRM data directly. In one observed burst, they executed nearly 1,000 Salesforce API queries in 15 minutes and sustained data extraction for more than six hours. The take: business contacts, account details, pricing quotes, and sales communications.

The timeline from there moved fast. Klue detected anomalous behavior on June 12 and revoked OAuth credentials for all customers on June 13, disconnecting its integrations entirely and bringing in CrowdStrike for incident response. By June 16, extortion emails were landing in Huntress staff inboxes. On June 22, the threat actor “Icarus” began listing victim data on its leak site. Roughly 15 of an estimated 195-200 exposed companies have gone public so far–Huntress itself has said it expects more to come forward as internal reviews finish. The list is a floor, not a ceiling.

The Pattern: Three OAuth Ecosystem Attacks in Twelve Months

Klue is not an isolated incident. It’s the third major attack on the Salesforce ecosystem’s OAuth supply chain in a year:

1. Salesloft Drift (August 2025): stolen OAuth tokens exposed data from roughly 760 organizations.
2. Gainsight (November 2025): token abuse touched around 200 Salesforce instances.
3. Klue (June 2026): a legacy credential led to token harvesting across 195-200 customer environments.

Three different vendors, one identical mechanism: a SaaS platform holds standing OAuth grants into hundreds of customer orgs, the platform gets compromised, and every one of those grants becomes an attacker’s session. The attackers have learned that the most efficient way into a well-defended Salesforce org isn’t through the front door–it’s through the vendor that already has a key.

Why This Matters for Your Salesforce Org

• The breach wasn’t in Salesforce–but the data was. Nobody phished your users or cracked your MFA. A valid OAuth token walked in through the API like it belonged there, because technically it did.
• Token theft is invisible to login-based defenses. No login event, no MFA challenge, no new device alert. The phishing-resistant MFA that became mandatory for admins this month does nothing against a stolen refresh token. Detection depends on watching API behavior, not authentication.
• Your vendor’s credential hygiene is your attack surface. Klue’s abandoned prototype credential from 2022 became 195 companies’ breach in 2026. You can’t audit your vendor’s internal credentials–but you can control what their token can reach in your org.
• The victims were security companies. Huntress, Recorded Future, HackerOne, LastPass. If organizations whose entire business is security carried this exposure, the average enterprise org almost certainly does too.

Deeper Dive

Anatomy of a Token-Relay Breach

To defend against this pattern, it helps to be precise about what the attacker actually holds. When a user authorizes a connected app–say, Klue’s Salesforce integration–Salesforce issues a refresh token tied to that user, that app, and the OAuth scopes the app requested. The vendor stores that refresh token and exchanges it for short-lived access tokens whenever it needs API access.

That design means a vendor-side compromise hands the attacker three things at once: valid credentials (the tokens), a pre-approved identity (the integration user or the authorizing users), and a plausible traffic pattern to hide in (the vendor’s normal API activity). Every defensive layer keyed to authentication–MFA, login IP ranges, device activation–was satisfied months ago when the token was first granted. From the org’s perspective, the attacker is the vendor.

Two properties determine your blast radius when this happens:

• Scope of the grant. An app that requested api refresh_token with a narrowly permissioned integration user can read what that user can read. An app authorized by a System Administrator with full refresh_token can read essentially everything. Most orgs have no idea which of these two situations they’re in, per app.
• Lifetime of the token. A refresh token with no expiration policy is a permanent credential. Salesforce supports expiring refresh tokens and forcing re-authorization–most orgs never change the default.

The Connected App Audit Playbook

Here’s the audit to run this week, in order of return on effort:

1. Inventory every active OAuth grant. Setup → Connected Apps OAuth Usage shows every app with active tokens and a user count. For a queryable view, use the OauthToken object: which apps, authorized by which users, last used when. Anything unrecognized, unused in 90 days, or authorized by a departed employee gets revoked today.
2. Check what each grant can reach. For each app, identify the authorizing users and their permission sets. A marketing enrichment tool authorized by an admin with Modify All Data is a full-org export waiting for a vendor breach. Reauthorize vendor integrations under dedicated integration users with minimum-necessary permission sets and API-only access.
3. Tighten app policies. For each business-critical connected app: set Permitted Users to “Admin approved users are pre-authorized” so a phished end user can’t grant new tokens; enforce IP restrictions rather than relaxing them; and set a refresh token expiration policy so grants die when unused.
4. Use API Access Control if you have it. Orgs with the feature can flip the default from “any app a user approves gets API access” to “only allowlisted apps get API access.” This single control would have limited every one of the three ecosystem attacks to explicitly approved integrations.
5. Put vendor integrations in your offboarding process. When a contract ends, the connected app’s tokens don’t revoke themselves. The Klue credential that started all this was an abandoned prototype–every org has its own equivalent sitting in the OAuth usage list.

If you want help with this audit, Permissions Assistant’s Integration Analysis feature maps every connected app in your org to the users who authorized it, shows when each grant was actually used, and lets you revoke access on the spot–and because the app is fully native and Security Reviewed, the analysis runs inside the Salesforce trust boundary with no externally stored OAuth tokens. A tool for auditing integration risk shouldn’t add to it.

Detection: Watch the API, Not the Login

The Klue attackers ran nearly 1,000 queries in 15 minutes. That’s not subtle–if anyone is watching API behavior. This is where the detection stack we covered in our Event Monitoring deep dive earns its keep against this specific threat:

• ApiAnomalyEvent exists for exactly this pattern: an integration user suddenly querying at 50x its baseline volume, touching objects it never touched before.
• ApiEvent in Real-Time Event Monitoring streams every API call with query details–the raw material for alerting on volume spikes per connected app.
• Transaction Security policies can act, not just alert: block the session or require step-up when an anomaly fires. Note that Salesforce’s own default policy (auto-enabled July 13 for Shield and Event Monitoring customers) only covers report exports over 10,000 records–API extraction through a connected app needs your own policy.
• Security Center Essentials, now rolling out to every Enterprise and Unlimited org, surfaces a baseline integrations view even without Shield. It won’t catch a live attack, but it makes the quarterly connected app review a dashboard instead of a spreadsheet.

The six-hour extraction window at Klue’s customers is the benchmark. If a connected app in your org started exfiltrating at 9 PM on a Friday, would anything fire before Monday?

Governance: Treat Every Vendor Integration as a Standing Credential

The strategic shift is to stop thinking of integrations as features and start thinking of them as credentials you’ve issued–because that’s what an OAuth grant is. That means each one gets the lifecycle treatment you’d give an admin password:

• An owner who is accountable for it
• A documented business justification and data footprint
• A review date, after which it’s revoked unless renewed
• Inclusion in vendor risk assessment: ask vendors how they store customer tokens, whether tokens are encrypted at rest, and what their credential rotation practice is–Klue’s answer to that last question is why 195 companies are in breach-notification mode

Longer term, this is the argument for the token exchange architecture we covered in May: vendor integrations that authenticate through your IdP with short-lived, per-request tokens instead of holding durable refresh tokens. The vendors won’t offer it until customers demand it. Demand it.

The Bottom Line

Klue is the third proof in twelve months that the Salesforce ecosystem’s soft underbelly is the OAuth token layer–valid credentials, held by vendors, outside your security perimeter but inside your data. The attack requires no Salesforce vulnerability, defeats login-based controls by design, and scales to hundreds of orgs per compromised vendor. The defense is unglamorous: know every grant, scope every grant, expire every grant, and watch API behavior like you watch logins. The orgs that did that work limited Klue’s token to a narrow integration user and caught the query spike. The orgs that didn’t are finding out now what their vendor’s 2022 prototype credential was worth.

Book a 15-Minute Security Strategy Call

Reference(s):

https://techcrunch.com/2026/06/22/klue-hack-results-in-data-breach-at-several-cybersecurity-firms/

https://www.huntress.com/blog/klue-breach-investigation

https://www.csoonline.com/article/4187907/klue-breach-exposed-salesforce-crm-data-through-stolen-oauth-tokens.html

https://fieldeffect.com/blog/klue-integration-breach-salesforce-data

https://www.rescana.com/post/klue-supply-chain-breach-exposes-oauth-tokens-and-salesforce-data-in-multi-stage-cybersecurity-incident-june-2026