The Klue OAuth Breach: Auditing the Salesforce Connected Apps You Forgot You Approved

A connected app you approved once, probably because a sales rep asked for it, spent roughly six hours one day last week reading your customer database and handing the records to someone else. No one phished a password. No malware ran on a laptop. The app already held a standing permission to read your Salesforce data, and the attacker simply borrowed it.

That is the shape of the Klue breach. Klue sells an AI-driven competitive-intelligence platform that plugs into Salesforce and Gong to sync sales "battlecards." On June 11, 2026, an attacker got into Klue through a long-disused credential left over from an abandoned prototype integration, then pushed a code change that harvested the OAuth tokens Klue's own customers had used to connect the app to their systems. Klue caught the anomaly on June 12 and deactivated every customer's OAuth credentials, and Salesforce disabled the Klue Battlecards integration on June 19, as The Hacker News reported. By then the records were gone. A threat actor calling itself "Icarus" listed Klue among its victims the same day, per BleepingComputer.

Who this hits, and who can close the tab

Here is the honest relevance verdict. If your business runs Salesforce, Google Workspace, Microsoft 365, HubSpot, or any SaaS platform where you have ever clicked "Allow" to connect a second tool - a CRM enrichment app, a meeting recorder, a marketing plugin, an analytics connector - this breach is a preview of your own exposure. The only readers who can stop here are the ones with zero third-party OAuth grants in any tenant, and in 2026 that is almost nobody.

What the attacker walks away with is not a system you can re-image. ReliaQuest, which tracked the abuse, watched automated scripts pull CRM records through the Salesforce REST API: in one environment a burst of nearly a thousand queries in fifteen minutes, in another a steady drain lasting more than six hours, with the whole event spanning close to a full day. Huntress, itself a Klue customer, confirmed the haul against its own org: business contacts, price quotes, and sales messaging. For a small business that is your pipeline, your pricing, and your customers' names sitting in an extortion email or a competitor's inbox. The person who fields that call is usually whoever also runs IT, which in a small company is one already-stretched human.

What actually happened inside the integration

The mechanism matters because it explains why your existing controls stayed silent. The attacker never authenticated as one of your users. They authenticated to Klue's integration service account - the machine identity Klue uses to talk to your Salesforce org - and generated OAuth access tokens from there. With a valid token, the Salesforce REST API answered normally: a GET /services/data/v59.0/sobjects call to enumerate which objects existed, then repeated /services/data/v59.0/query requests paginated through QueryMore cursors to walk every record.

Two details made this hard to catch. The scripted client identified itself with User-Agent strings like Python-urllib/3.12 and Python-urllib/3.14 across roughly 900 queries, and some requests carried a blank or numeric ("5238") user agent, traffic that disappears into the API noise of a busy org when nobody is watching for it. And because the token was minted from a trusted connected app, multi-factor authentication never entered the picture. MFA guards a login. A refresh token that already exists has moved past the login.

Why the connected app is the part nobody watches

Every OAuth connection you approve creates a non-human identity: a standing grant that lets one service read or write your data on your behalf, indefinitely, with no human present. Large security teams have learned to treat these as first-class accounts. Most small teams never see them, because the grant sits two menus deep and was authorized months ago by someone who has since changed roles or left.

The Klue case adds the lifecycle failure that makes these grants dangerous. The credential the attacker used came from a prototype integration Klue had abandoned but never decommissioned: live access that nobody owned. Your own tenant carries the same hazard in miniature. The analytics tool you trialed and dropped, the contractor's app from a project that ended last year, the marketing connector from a vendor you stopped paying - each is a door still standing open because closing it was never assigned to anyone.

The enterprise control, and the version a small team can run

Large organizations govern this with SaaS security posture management or a CASB that inventories every OAuth grant, scores its scopes, and alerts on new or over-permissioned apps. You do not have to buy that to get most of the protection. Salesforce ships the controls natively, and the only missing ingredient is the hour it takes to use them.

Do these inside your Salesforce org this week

• Inventory the grants. Setup > Connected Apps OAuth Usage lists every app holding live tokens and how many users authorized it. Anything you do not recognize or no longer use gets its tokens revoked from that page.
• Right-size the scopes. For the apps you keep, open the connected app's OAuth policies and cut access to the minimum. An enrichment tool rarely needs full api and refresh_token reach across every object you own.
• Lock the integration to known addresses. Set the connected app to enforce IP restrictions and add the vendor's published egress ranges. The Klue scripts ran from four addresses - 138.226.246.94, 212.86.125.24, 213.111.148.90, and 94.154.32.160 - and an IP allowlist on the integration account would have refused all four.
• Cap the refresh-token lifetime. A refresh token valid "until revoked" is a permanent key. Give it an expiry so a stolen token dies on its own schedule.

Salesforce documents each of these under managing OAuth access policies for a connected app. The same logic carries to Google Workspace ("Apps with access to your account") and Microsoft 365 (Enterprise Applications plus an admin-consent policy): inventory, scope down, restrict where it runs from.

Detecting the exfiltration without a SOC

You do not need a SIEM to catch the signature this attack left behind. Salesforce Login History and Event Monitoring record API logins and query volume, and the tell here is a service account suddenly running thousands of read queries from a scripting library's user agent. If you have the Salesforce CLI configured, this surfaces the API logins worth a second look:

# 1. Recent API logins for integration / service accounts (Salesforce CLI)
sf data query --target-org prod --query \
  "SELECT LoginTime, SourceIp, Application, Browser, Status \
   FROM LoginHistory \
   WHERE Application IN ('Klue','Gong') OR Browser LIKE '%urllib%' \
   ORDER BY LoginTime DESC"

# 2. Pull today's API event logs, then hunt the scripted-exfil pattern
sf data query --target-org prod --query \
  "SELECT Id, EventType, LogDate FROM EventLogFile \
   WHERE EventType = 'API' AND LogDate = TODAY"

# After downloading the event CSV, flag the user agents and the IOC IPs:
grep -E 'Python-urllib|/services/data/v[0-9]+\.0/query' api_events.csv \
  | grep -E '138\.226\.246\.94|212\.86\.125\.24|213\.111\.148\.90|94\.154\.32\.160'

A human integration logs in once and stays quiet. A scripted pull shows up as a service principal generating hundreds of query calls in minutes, often from an unfamiliar IP and a generic user agent. If your edition lacks Event Monitoring, Login History alone still shows the source IP and login application for every API session, which is enough to spot an integration account talking from somewhere it never has before.

Kill the standing access, not just the breached app

When Klue was identified, the instinct was to disconnect the integration. Huntress flagged why that is not enough: revoking the app in the marketplace can leave the underlying OAuth grants and sessions alive. The full reset is to revoke the active OAuth tokens and refresh tokens, rotate the connected app's client secret, reset the service-account password, and kill outstanding sessions, then confirm in Login History that the tokens stop working. Treat any app that touched your data the way you would treat a compromised admin account, because for the duration of that token it was one.

Inventory the apps that can read your CRM

The fix for the Klue pattern is not a patch you install once. It is a habit. Open Connected Apps OAuth Usage in Salesforce, the third-party access page in Google Workspace, and Enterprise Applications in Microsoft 365, and read the list out loud. For every app, answer one question: do we still use this, and does it need everything we granted it? Revoke whatever fails that test today, then put a recurring 30-minute review on the calendar so dead integrations never pile up again. An app you cannot name is access you cannot defend, and the next Klue is already connected to somebody's tenant. If that list runs longer than you expected, and it usually does, that is the moment to bring in a second set of eyes to map the grants and the scopes with you.