Klue breach exposes Salesforce data across the SaaS supply chain

What happened

On June 12, 2026, Klue, a B2B SaaS app for competitive intelligence and win-loss platform, identified unauthorized activity affecting a portion of its integration infrastructure. According to Klue's disclosure, an attacker gained access through a compromised legacy credential associated with an integration service. Using that foothold, they obtained OAuth tokens that Klue held on behalf of its customers to connect with third-party platforms, including Salesforce. Those tokens were then used to access and exfiltrate data from the Salesforce environments of an unknown number of Klue customers.

‍

To be clear: Salesforce itself was not compromised. The attacker used Klue as an entry point and pivoted to Salesforce instances of Klue customers through the OAuth tokens Klue legitimately held. The distinction matters, but so does the implication: if a SaaS tool you trust is integrated with your Salesforce instance and gets breached, your Salesforce data can be exposed without anyone touching your Salesforce credentials.

‍

This attack is very similar in nature to the Salesloft Drift breach that was disclosed in August of 2025.

‍

Scope of impact

The list of companies who have confirmed impact is growing. Rather than list them here, we have created a Klue breach tracker that will be updated as more companies issue disclosures.

‍

Why you might be affected even if you don't use Klue

This is the part that often gets lost in breach coverage: you don't have to be a Klue customer to be at risk.

‍

Many of the organizations who have issued disclosures are themselves SaaS vendors with their own customer bases. If your organization is a customer, prospect, or partner of any affected company, your contact information—name, email, job title, phone number—may have been sitting in their Salesforce instance and could have potentially been exfiltrated.

‍

Beyond that, think about your own SaaS stack. Klue connects to Salesforce, but so do dozens of other sales intelligence, competitive enablement, revenue operations, and AI tools your teams may have granted OAuth access to. If any of those vendors face a similar compromise, the same attack pattern could be possible.

‍

The vector here isn't unique to Klue. It's the model of SaaS-to-SaaS OAuth integration itself. We’ve written previously about the risks of OAuth sprawl related to the Salesloft Drift breach as well as the Vercel breach.

‍

Timeline of events

June 12, 2026 — According to Klue's website, Klue identified unauthorized activity affecting a portion of Klue's integration infrastructure. Klue notes, "Our investigation determined that an attacker gained access through a compromised legacy credential associated with an integration service. The attacker used that access to obtain OAuth tokens used to connect Klue with certain third-party platforms, including Salesforce and Gong, and subsequently accessed data within a number of connected customer environments."

‍

Klue notes it immediately began revoking affected credentials and tokens, removing unauthorized code, disabling impacted integrations, and notifying law enforcement.

‍

June 16, 2026 — Huntress personnel receive extortion emails claiming the stolen data has been downloaded and threatening disclosure. The threat actor is reportedly engaged in an extortion campaign against multiple victims.

‍

June 17-22, 2026 — Affected organizations begin publishing individual disclosures. Salesforce issues an official statement. Datadog Security Labs and Huntress publish independent technical analyses.

‍

What the attacker did once inside

Based on technical analysis published by Datadog Security Labs and Huntress, the below indicators point to evidence of Klue-related activity.

‍

OAuth refresh token abuse. In some environments, the attacker used OAuth refresh tokens to maintain API access. These appear in Salesforce logs under login_sub_type: OAuth Refresh Token (or oauthrefreshtoken in the Login object).

‍

Broad API enumeration. The attacker queried standard Salesforce objects through the API. Researchers also observed spikes in failed API requests alongside successful ones—a sign the attacker was casting wide queries to maximize data return.

‍

QueryMore for large-scale exfiltration. Because Salesforce limits each API request to 2,000 records, the attacker used Salesforce's QueryMore capability to paginate through large data sets.

‍

Known indicators of compromise. Klue confirmed the following IP addresses as threat actor infrastructure:

• 138.226.246[.]94
• 212.86.125[.]24
• 213.111.148[.]90
• 94.154.32[.]160

The Klue Battlecards integration appears in Salesforce logs under application: "Klue Battlecards" in LoginEvent logs, and connected_app_name: "Klue Battlecards" in API events.

‍

Recommendations for security practitioners

Whether you use Klue directly or you're a customer of an affected vendor, or you're simply auditing your own OAuth exposure after reading this, here's where to focus:

‍

If you're a Klue customer:

• Revoke all Klue OAuth tokens across every connected platform immediately, not just Salesforce.
• Follow the specific remediation guidance Klue is providing directly to affected customers.
• Audit your Salesforce logs for activity from the known threat actor IP addresses and user agents listed above, scoping your search to June 11-12 activity tied to the Klue Battlecards connected application.
• Search for evidence of QueryMore activity: spikes in RestApi or ApiTotalUsage events, especially against Opportunity, Case, Contact, Lead, and Account objects.
• Scan CRM data for exposed credentials: API keys, tokens, passwords in ticket descriptions, notes, or case fields. This was a specific target in the Drift/Salesloft incident, and it's a likely target here too.
• Warn your go-to-market team: the stolen data is a phishing and social engineering toolkit. Prospect and customer contacts from your Salesforce instance may receive convincing impersonation attempts.

For everyone else:

• Audit every third-party application connected to your Salesforce instance and any other SaaS systems with broad data access. For each one, ask: who granted this access? When? What scope? Is it still in use?
• Revoke OAuth grants for integrations that are unused, undocumented, or of unknown origin.
• Right-size OAuth scopes going forward. "Full access" is a convenience that becomes a liability at moments like this.
• Implement IP restrictions for connected apps in Salesforce where possible: in the Connected App settings, set IP Relaxation to enforce restrictions and limit to your corporate egress ranges.
• Remove the "API Enabled" permission from broad profiles; grant it only via granular permission sets for the specific connected apps that need it.
• Implement session timeout policies for integrations.
• Centralize your Salesforce event logs and alert on anomalous API activity—particularly high-volume read operations from connected application accounts, unusual source IP addresses, or unexpected use of OAuth refresh tokens.
• If you're a customer, prospect, or partner of any confirmed affected organization, expect that your contact information may be in the wild. Communicate that context to your security awareness program so people recognize the possibility of social engineering attempts.

The broader pattern

This isn't the first time this attack path has worked. In August 2025, attackers used compromised OAuth tokens from the Salesloft Drift integration to exfiltrate Salesforce data from hundreds of organizations in a nearly identical campaign. The same architecture—SaaS vendor holds OAuth tokens on behalf of customers, SaaS vendor gets compromised, attacker pivots into customer environments—played out again here.

‍

The attack surface isn't Salesforce. It's the entire ecosystem of third-party apps connected to Salesforce. And that ecosystem tends to be large, under-inventoried, and under-monitored.

‍

Most organizations can't quickly answer: what apps are connected to our Salesforce instance right now? What data can they see? Who approved this? When? Are the tokens still active?

‍

That gap is what attackers are exploiting. Closing it requires treating SaaS integrations with the same rigor applied to endpoints and network access—regular audits, least-privilege scopes, active log monitoring, and a clear revocation process when something looks wrong. Our guide covering Salesforce security best practices is also a good reference to ensure you've taken the most important steps to fend off these types of attacks.

‍

Sources: Klue security incident disclosure | Datadog Security Labs | Huntress breach investigation