Salesforce Disables Klue After Hackers Steal CRM Data via OAuth Tokens

The Salesforce Klue breach is a masterclass in why your CRM is only as secure as the weakest app connected to it. On June 11-12, 2026, attackers compromised Klue — a competitive intelligence platform used by sales teams worldwide — and harvested OAuth tokens that gave them access to customers’ Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive, and Slack instances. One breach. Ten platforms. Unlimited damage potential.

Salesforce responded by disabling the Klue integration entirely, cutting off access for every Klue customer. The “Icarus” extortion group has been attributed to the attack. And Klue’s CEO is still insisting there’s “no evidence of platform data impact” — a statement that’s doing a lot of heavy lifting given the circumstances.

Here’s the full breakdown of the Salesforce Klue breach, how OAuth token harvesting works, and why this type of supply chain attack is the biggest threat to enterprise security in 2026.

Salesforce Klue Breach: What Happened

The Salesforce Klue breach began on June 11, 2026, when attackers gained access to Klue’s internal systems using a compromised legacy credential. Klue is a competitive intelligence platform that helps sales teams track and analyze competitor activities — it integrates with virtually every major business tool to aggregate competitive data.

Those integrations are the problem. To function, Klue requires OAuth access tokens to connect with its customers’ SaaS platforms. When attackers compromised Klue, they didn’t just get Klue’s data — they got the keys to every platform Klue was connected to.

The affected integrations include:

• Salesforce — CRM data, sales pipelines, customer contacts, deal information
• HubSpot — Marketing data, contact lists, campaign information
• SharePoint — Internal documents, company wikis, shared files
• Zoom — Meeting recordings, transcripts, participant lists
• Gong / Chorus — Sales call recordings, conversation analytics
• Clari — Revenue intelligence, forecasting data
• Google Drive — Shared documents, spreadsheets, presentations
• Slack — Channel messages, direct messages, shared files

That’s not just a data breach — it’s a complete exposure of an organization’s competitive strategy, sales pipeline, customer relationships, internal communications, and revenue data. For a sales-driven company, this is a worst-case scenario.

How the OAuth Token Attack Worked

The attack exploited a fundamental weakness in how SaaS integrations work: OAuth tokens are persistent, powerful, and often poorly monitored.

Here’s the attack chain:

1. Initial Access: Attackers compromised a legacy credential — likely an old API key, service account password, or developer credential that was never properly rotated or decommissioned. This is a depressingly common initial access vector, especially in fast-growing startups that accumulate technical debt.
2. Lateral Movement to Token Storage: Once inside Klue’s infrastructure, attackers located the database or vault where OAuth tokens were stored. These tokens are the mechanism by which Klue maintains persistent connections to customer platforms — each token grants specific API access to a customer’s Salesforce, Slack, or other integrated system.
3. Token Harvesting: Attackers exfiltrated the OAuth tokens en masse. Unlike passwords, OAuth tokens don’t require the user’s credentials to use — they’re bearer tokens that grant access directly. Whoever holds the token has access.
4. API Access: Using the harvested tokens, attackers could make authenticated API calls to each connected platform as if they were Klue. This means they could read CRM data from Salesforce, download files from Google Drive, access Slack messages, and retrieve call recordings from Gong — all without ever touching the customer’s actual systems.

The elegance of this attack is that it’s almost invisible to the victim organizations. The API calls look legitimate because they’re coming through Klue’s authorized integration. Security teams monitoring for unauthorized access wouldn’t see anything unusual — the access is technically “authorized” via valid OAuth tokens. It’s similar in principle to the GitHub VS Code extension compromise that hit 3,800 repos through trusted tooling.

The Icarus Extortion Group Behind the Klue Breach

The Salesforce Klue breach has been attributed to a threat actor group called “Icarus,” an extortion-focused operation that has been increasingly active in 2026. Unlike ransomware groups that encrypt data and demand payment for decryption keys, Icarus operates on a pure data theft and extortion model.

Their playbook is straightforward:

1. Compromise a third-party SaaS vendor or integration platform
2. Harvest credentials and access tokens
3. Exfiltrate sensitive data from connected customer accounts
4. Demand payment from the vendor and/or individual customers to prevent data publication

This model is particularly effective against SaaS supply chain targets because the blast radius is enormous. Instead of compromising one company at a time, Icarus can breach a single vendor and access dozens or hundreds of downstream customers. It’s a force multiplier that makes traditional ransomware look inefficient by comparison.

The group’s name — Icarus — is either ironic or aspirational, depending on your perspective. The mythological Icarus flew too close to the sun and fell. Whether the real-world Icarus will suffer the same fate depends on how quickly law enforcement can attribute and disrupt their operations.

Salesforce Response: Disabling Klue Integration

Salesforce’s response to the Klue breach was swift and blunt: they disabled the Klue integration entirely. Every Klue customer’s connection to Salesforce was severed, effective immediately. No warning. No transition period. Just a hard cutoff.

This is the nuclear option in SaaS security, and Salesforce deploying it tells you how seriously they assessed the threat. By revoking Klue’s OAuth application credentials at the platform level, Salesforce ensured that even if attackers still held individual customer tokens, those tokens would no longer function.

The downside? Thousands of sales teams that rely on Klue for competitive intelligence suddenly lost access to a critical tool. Sales calls went into meetings without competitive briefs. Battle cards went stale. And organizations that had built their competitive intelligence workflows around Klue had to scramble for alternatives.

It’s a real-world demonstration of a security concept called “blast radius management.” Salesforce decided that the risk of continued data exposure outweighed the business disruption of cutting off a major integration partner. They chose security over convenience — the right call, but one that highlights how fragile the interconnected SaaS ecosystem really is.

Who Is Affected by the Salesforce Klue Breach

Klue’s customer base includes hundreds of B2B companies across technology, financial services, healthcare, and manufacturing sectors. Any organization that had active Klue integrations with Salesforce or other platforms during the June 11-12 compromise window should assume their data was potentially exposed.

Huntress, a well-known cybersecurity firm, confirmed that it was among the affected customers. The irony of a cybersecurity company being compromised through a third-party SaaS integration is not lost on the industry — if Huntress, with all their security expertise, was exposed through Klue, what chance does an average company have?

Klue CEO Jason Smith released a statement saying there was “no evidence of platform data impact” — meaning Klue’s own platform data wasn’t compromised. But this carefully worded statement sidesteps the real concern: it’s the customer data accessible via OAuth tokens that matters, not Klue’s platform data.

Organizations affected by the Salesforce Klue breach should immediately:

• Audit all OAuth tokens and API connections associated with Klue
• Review access logs in Salesforce, HubSpot, Google Drive, Slack, and other integrated platforms for unusual API activity during June 11-12
• Rotate all credentials and tokens that were shared with or accessible through Klue
• Notify customers if CRM data may have been exposed
• Engage incident response teams to assess the full scope of potential data exposure

The OAuth Supply Chain Problem

The Salesforce Klue breach exposes a systemic problem in modern enterprise architecture: we’ve built our businesses on a web of OAuth connections that nobody is properly monitoring.

The average enterprise has 130+ SaaS applications, according to Productiv’s State of SaaS report. Each of those applications potentially connects to other applications via OAuth, creating a complex web of trust relationships. When one node in that web is compromised, the attacker inherits all the trust relationships of the compromised node.

This is exactly what happened with Klue. Organizations trusted Klue with access to their most sensitive platforms. Klue was compromised. And suddenly, every platform Klue was connected to became a potential victim — a pattern that mirrors the cPanel supply chain attack from earlier this year.

The OAuth protocol itself isn’t the vulnerability — it’s actually a well-designed authorization framework. The problem is how organizations implement and manage OAuth connections:

• Over-permissioning: Applications are granted broader OAuth scopes than they actually need. Klue probably didn’t need full read access to every Salesforce object, but most organizations don’t carefully review OAuth scope requests.
• No token rotation: OAuth tokens often persist for months or years without rotation. When they’re compromised, attackers have extended access windows.
• Minimal monitoring: Most organizations don’t actively monitor OAuth token usage patterns. Unusual API access through authorized tokens goes undetected.
• No centralized inventory: Security teams often don’t even know which third-party applications have OAuth access to their platforms.

How to Protect Your CRM From OAuth Token Attacks

The Salesforce Klue breach is a wake-up call for every organization that relies on SaaS integrations. Here’s what you should do right now:

1. Audit Your OAuth Connections

In Salesforce, go to Setup > Connected Apps OAuth Usage to see every application with OAuth access to your org. In Google Workspace, check Admin Console > Security > API Controls. In Slack, review Apps & Integrations. Do this for every major platform. You’ll probably be surprised by how many third-party apps have access.

2. Implement Least-Privilege OAuth Scopes

Review the OAuth scopes granted to each connected application. Does your competitive intelligence tool really need access to all Salesforce objects? Does your meeting recording tool need full Google Drive access? Restrict scopes to the minimum required for the application to function.

3. Enable Token Rotation Policies

Configure OAuth token expiration and rotation policies. Short-lived tokens with automatic refresh reduce the window of opportunity for attackers who steal tokens. Salesforce supports configurable token policies — use them.

4. Monitor API Access Patterns

Implement monitoring for unusual API access through OAuth tokens. Modern threat detection platforms can establish baselines for normal API usage and alert on anomalies — like a sudden spike in data exports or access to objects that the application doesn’t normally touch.

5. Evaluate Third-Party Vendor Security

Before granting OAuth access to any third-party application, assess their security posture. Ask about their token storage practices, incident response capabilities, and SOC 2 compliance. The AI-powered threat landscape means that vendor security assessments need to be ongoing, not one-time checks.

The Salesforce Klue breach won’t be the last OAuth supply chain attack. The interconnected nature of modern SaaS ecosystems guarantees that. Your CRM, your communications, your sales intelligence — they’re all connected through a web of OAuth tokens. And that web is only as strong as its weakest node.

Make sure that weakest node isn’t connected to your data.