Klue Breach: What You Need to Know

The Klue breach shows how stolen OAuth tokens from a trusted SaaS integration can expose Salesforce CRM data. Learn what happened, which companies confirmed impact, what data was exposed, and how defenders should respond.

What Happened in the Klue Breach?

The Klue breach was a third-party Software-as-a-Service (SaaS) integration incident that affected customer environments connected through Klue’s integration layer. Klue said it detected unauthorized activity on June 12, 2026, and found that an attacker used a compromised legacy credential tied to an integration service. That access allowed the attacker to obtain OAuth tokens for third-party platforms, including Salesforce.

Those tokens gave the attacker a trusted route into connected customer environments. Klue said the incident was limited to affected third-party platforms and that it had not found evidence that customer content stored inside the Klue platform was impacted.

Klue responded by revoking affected credentials and tokens, removing unauthorized code, disabling potentially impacted integrations, notifying law enforcement, and engaging CrowdStrike to support the investigation. You can follow Klue’s official update on the recent security incident for vendor-provided information.

Salesforce also disabled the Klue Battlecards app integration. Salesforce stated that the issue was tied to Klue’s app connection and did not come from a vulnerability in the Salesforce platform.

How Did Attackers Use OAuth Tokens?

OAuth tokens allow one application to access another service without repeatedly asking a user to sign in. In normal business use, this helps tools like Klue connect to Salesforce and other platforms.

In this case, attackers abused that trust relationship. Huntress reported that anomalous activity began in Klue’s integration infrastructure on June 11 and that the attacker pushed a code change capable of collecting OAuth tokens used by Klue customers.

After obtaining valid tokens, the attacker could query connected Salesforce environments through the trusted app path. Datadog reported that the attacker used automated REST API queries, including Python-based user agents, and looked for activity tied to the Klue Battlecards connected app in Salesforce logs.

Which Companies Confirmed Impact?

Public statements and incident summaries confirm impact across these organizations:

What Data Was Exposed?

The exposed data varied by organization, but the common theme was Salesforce CRM and business relationship data. Public disclosures mention names, business email addresses, phone numbers, job titles, account records, sales opportunities, pricing details, support case metadata, and other commercial CRM fields.

Several affected companies said the incident did not affect their core platforms, infrastructure, passwords, payment card data, product telemetry, or customer-facing services. Still, CRM data can create real risk because attackers can use business context to make phishing, extortion, and social engineering attempts more convincing.

When Did the Klue Incident Happen?

The public timeline points to a fast-moving incident across several days:

1. June 11, 2026: Anomalous activity began in Klue’s integration infrastructure, according to Huntress and Datadog reporting.
2. June 12, 2026: Klue identified unauthorized activity and began containment.
3. June 13, 2026: Klue alerted customers and disabled integrations during the investigation, according to Huntress and Datadog.
4. June 16, 2026: Extortion emails began reaching some affected organizations.
5. June 17–23, 2026: Multiple companies published impact statements or status updates, including Recorded Future, Jamf, OneTrust, HackerOne, Snyk, Insurity, and LastPass.

Who Was Behind the Klue Breach?

Attribution remains complicated:

• Huntress reported that the extortion group Icarus listed Klue on its leak site.
• ReliaQuest also noted a separate claim from a Telegram account presenting itself as ShinyHunters, which said on June 21, 2026, that Salesforce environments linked to Klue partners had been taken. The Telegram message also pointed to a Session Messenger contact associated with Icarus, raising the possibility of shared infrastructure, collaboration, or borrowed branding.

Since the ShinyHunters account has not been verified, the safest position is to treat the attribution as unresolved.

What Should Defenders Do Now?

Organizations that used Klue, Salesforce connected apps, or similar SaaS integrations should treat OAuth tokens like privileged credentials.

Start with containment:

• Revoke OAuth tokens, refresh tokens, client secrets, and service account credentials tied to Klue or other affected integrations.
• Disable the integration until the vendor and internal teams validate the environment.
• Review whether connected apps have broader Salesforce access than they need.
• Rotate credentials for adjacent integration middleware or automation accounts.

Then investigate Salesforce activity:

• Search for unusual REST API query volume.
• Review activity from the Klue Battlecards connected app.
• Look for Query and QueryMore activity across Account, Contact, Opportunity, Lead, Case, Task, Contract, Campaign, Event, and User objects.
• Check user agents, source IPs, OAuth refresh token use, and access patterns that do not match normal integration behavior. Datadog identified REST API query behavior and read-heavy activity across many objects as useful detection leads.

Finally, prepare for follow-on abuse:

• Warn sales, support, finance, and executive teams about phishing and extortion attempts.
• Search inboxes and spam folders for messages referencing stolen CRM data.
• Notify affected customers through trusted channels.
• Review SaaS log retention before the next incident, not during it.

How Can Organizations Reduce Third-Party SaaS Risk?

The Klue breach shows why SaaS integrations need the same scrutiny as privileged user accounts. Security teams should maintain a current inventory of connected apps, OAuth grants, service accounts, API scopes, and third-party data flows.

Practical controls include:

• Apply least privilege to connected apps.
• Remove unused integrations and legacy credentials.
• Shorten token lifetimes where possible.
• Require IP allowlisting for sensitive service accounts.
• Monitor API behavior, not only interactive logins.
• Review vendor access during onboarding and renewal.
• Keep incident-ready logs for Salesforce and other critical SaaS platforms.

How Can SOCRadar Help?

Security teams can also use threat intelligence and external risk monitoring to watch for exposed credentials, leaked CRM data, brand impersonation, and Dark Web chatter after vendor incidents.

SOCRadar’s Extended Threat Intelligence can help with:

• Attack Surface Management: Finds exposed assets and risky external services.
• Supply Chain Intelligence: Monitors vendors and partners for breach-related risks.
• Brand Protection: Detects fake domains, phishing pages, and impersonation attempts.
• Cyber Threat Intelligence: Tracks threat actors, indicators, and campaigns tied to SaaS abuse.
• Dark Web Monitoring: Looks for leaked credentials, stolen records, and organization mentions across criminal sources.

This helps teams detect follow-on abuse before stolen CRM data turns into a successful phishing or extortion attempt.

Conclusion

The Klue breach was not only a Salesforce incident or a single-vendor problem. It showed how a trusted integration can become a high-impact access path when OAuth tokens, service accounts, and connected apps are not tightly governed.

Organizations should know which third-party applications can access sensitive business data, limit what those applications can do, monitor how they behave, and be ready to revoke access quickly when a vendor incident occurs.