The Klue-Salesforce OAuth Attack: How One Stolen Token Hit Dozens of Firms

Attackers stole an OAuth token from a connected app and used it to drain Salesforce data across many companies. Here's how to lock down your integrations.

Sam CarterJun 23, 2026 8 min read

Cover image for The Klue-Salesforce OAuth Attack: How One Stolen Token Hit Dozens of Firms — Photo: The DEMO Conference / flickr (BY-NC-ND 2.0)

Salesforce disabled the Klue app integration in June 2026 after attackers abused its OAuth token to steal CRM data from a string of organizations, including several cybersecurity firms. It is the latest entry in a punishing 2026 pattern: compromise one trusted integration, steal the token it holds, and use that token to quietly read the data of every company connected to it. The most dangerous part is that OAuth tokens sail straight past multi-factor authentication.

Quick answer

Attackers stole an OAuth token from the Klue app and used it to read Salesforce CRM data across many organizations, including security firms, prompting Salesforce to disable the integration. The key danger: OAuth tokens are issued after login and carry pre-authorized access, so a stolen token bypasses MFA entirely, your password and authenticator are irrelevant. The only real fix is revoking the token at the platform, not resetting a password. To defend yourself, inventory every connected app, scope each to least privilege, monitor API logs for bulk queries, and rotate secrets fast when any vendor in your chain is breached.

Key takeaways

Attackers abused an OAuth token belonging to the Klue app to reach Salesforce CRM data across multiple organizations; Salesforce disabled the integration in response.
Impacted companies reportedly include well-known security and identity firms, a reminder that nobody is immune to a supply-chain compromise through a connected app.
OAuth tokens represent pre-authorized access and bypass MFA entirely. A stolen token does not need your password or your second factor, it already carries the app's granted permissions.
This mirrors the 2025 Salesloft/Drift attack that hit 700+ organizations through stolen Drift OAuth tokens. The technique is now a staple of the ShinyHunters and related campaigns.
The defense is treating connected-app identities as privileged accounts: inventory them, scope them to least privilege, monitor their API activity, and rotate their secrets.

How an OAuth supply-chain attack works

When you connect a third-party app to a platform like Salesforce, you grant it an OAuth token, a long-lived credential that lets the app act on your behalf without re-entering a password each time. That convenience is the whole point of integrations. It is also the weakness.

An attacker who compromises the integration vendor, through a breached code repository, leaked secrets, or a phished employee, can steal the OAuth tokens that vendor holds for its customers. Each token is a pre-authorized key into a downstream environment. The attacker uses it to impersonate a legitimate, already-approved connection and read whatever the app was permitted to read.

The critical detail: OAuth tokens bypass multi-factor authentication. MFA protects the login. A token is what you get after a successful login, so an attacker holding one never sees a login prompt at all. Your strong password and your authenticator app are irrelevant to a stolen token.

Warning

A stolen OAuth token is pre-authorized access. It carries the connected app's permissions and skips the login entirely, which means MFA does nothing to stop it. The only fix is to revoke the token, not reset a password.

Why this keeps happening

The Klue incident is not a one-off. In 2025, attackers compromised Salesloft's environment, stole OAuth tokens from its Drift integration, and used them to reach Salesforce data across more than 700 organizations. The 2026 ShinyHunters campaigns have made OAuth supply-chain abuse a core technique, alongside voice phishing and exploitation of misconfigured cloud portals.

The reason it works so well is structural. A modern company connects dozens or hundreds of SaaS apps, each holding a token into the core systems. Every one of those integrations is a potential entry point, and most are never inventoried, scoped tightly, or monitored the way a user account is. Compromise the weakest vendor in the chain and you inherit access to everyone downstream.

A quick way to see why MFA alone fails here is to compare what each credential actually protects:

Credential	Protects against	Stopped by MFA?	How to kill it
Password	Casual guessing, reuse	Yes, with MFA on	Reset password
MFA / authenticator	Login from a stolen password	N/A (it is the control)	Re-enroll device
OAuth token	Nothing on its own, it is post-login	No, bypasses MFA	Revoke the grant at the platform
Refresh token	Nothing, it re-mints access tokens	No	Revoke and rotate client secret

The bottom two rows are the whole problem: a stolen token or refresh token never triggers a login, so MFA is blind to it.

> connected app in

How to protect your organization

You cannot prevent every vendor from being breached, but you can dramatically limit what a stolen token reaches and how long it stays useful.

Inventory every OAuth-connected app. You cannot protect integrations you do not know exist. List every connected app in Salesforce, and your other core platforms, and who owns each one.
Scope permissions to least privilege. Most integrations request far more access than they use. Restrict each connected app to the minimum data and actions it genuinely needs.
Treat connected-app identities as privileged accounts. Apply the same scrutiny, review cadence, and monitoring you would for an admin user.
Monitor API logs for abuse. Watch for sudden high query volume, repeated pagination (QueryMore loops pulling whole tables), and unusual user-agents on token-based access.
Rotate and revoke proactively. When any integration in your chain is implicated, revoke its active OAuth grants and rotate the associated service-account passwords, refresh tokens, and client secrets, not just the obvious one.

Tip

After a supply-chain incident, revoking the token is the part teams forget. A password reset does nothing to an OAuth grant, the token stays valid until it is explicitly revoked at the platform. Make token revocation a standing step in your incident playbook.

The detection signals to hunt for

When researchers dissected these campaigns, a few signals showed up repeatedly in the victims' Salesforce API logs. If you are investigating a possible OAuth abuse, look for:

Abnormally high query volume from a single connected app over a short window, the signature of bulk data exfiltration.
Repeated QueryMore pagination, where the attacker walks through every page of a large object to pull the whole dataset.
Suspicious user-agents on token-based API calls, such as scripting clients that do not match the legitimate integration's normal traffic.

These are the fingerprints of automated scraping through a stolen token. Correlate them against your inventory of which apps should be making bulk queries.

The strongest single control

For the credential-phishing leg that often kicks off these campaigns, tricking an employee into surrendering SSO credentials, the most effective defense is phishing-resistant MFA using FIDO2 hardware keys or passkeys. Those methods cannot be intercepted or replayed even if a user lands on a fake login page, which closes the door the attackers walk through first. Our guide to defending against Microsoft 365 token theft and adversary-in-the-middle attacks covers the phishing-resistant rollout in detail.

It is worth being precise about what that does and does not solve. Phishing-resistant MFA stops the initial credential theft. It does not protect a token that was stolen from a compromised vendor, that is what least-privilege scoping, monitoring, and fast revocation are for. The two controls work in tandem. As a practical next step, our walkthrough on auditing and revoking third-party app access shows exactly how to find and cut the OAuth grants that attackers target.

What to do tonight

If you run Salesforce or any SaaS platform with connected apps, do these before you log off:

Open Setup, then Connected Apps and OAuth usage, and list every app holding an active token.
Revoke any integration you do not recognize or no longer use; do not wait for a vendor advisory.
Confirm Klue's grant is gone (Salesforce disabled it, but verify in your own org).
Turn on or tighten API monitoring so a sudden bulk query from one app raises an alert.
Add "revoke OAuth grants and rotate client secrets" as an explicit step in your incident playbook.
Roll out phishing-resistant MFA (FIDO2 keys or passkeys) to close the credential-theft entry point.

Frequently asked questions

If I have MFA on everything, am I safe from this?

No, and that is the core lesson. MFA protects logins; OAuth tokens are issued after login and carry pre-authorized access, so a stolen token bypasses MFA completely. You need integration-level controls, scoping, monitoring, and revocation, on top of MFA.

How do I find every OAuth app connected to my Salesforce?

In Salesforce, review Connected Apps and OAuth usage in Setup to see every app with an active token, the scopes it holds, and its recent activity. Other platforms have equivalent connected-app or third-party-access dashboards. Build a single inventory and assign an owner to each entry.

A vendor we use was breached. What do we revoke?

Do not stop at the headline token. Revoke the active OAuth grants tied to that integration and rotate everything associated with it: service-account passwords, refresh tokens, and client secrets. Then hunt your API logs for the abuse signals above to confirm whether data was actually pulled.

Why was Klue disabled instead of just patched?

Disabling the integration severs the abused access path immediately while the incident is investigated, protecting downstream customers regardless of any individual organization's response speed. It is a containment step at the platform level, not a code fix.

Sources

#security#oauth#saas#supply-chain#salesforce