In 2022, someone at Klue — a competitive intelligence platform used by sales teams across the tech industry — created a credential to prototype a third-party integration. The prototype was abandoned. The credential was not revoked. For four years, it sat in Klue's infrastructure like an unlocked side door that nobody remembered existed.
On June 11, 2026, someone walked through it.
A threat actor used that legacy credential to penetrate Klue's integration infrastructure, then pushed a code update designed to harvest OAuth tokens — the authentication keys that Klue's customers had granted so the platform could read and write data in their Salesforce instances. Within days, the attacker had used those stolen tokens to query Salesforce REST APIs across an estimated 195 customer environments, running automated Python scripts that paginated through CRM records for up to 24 hours per target.
The victim list reads like a cybersecurity industry directory: Huntress, Recorded Future, HackerOne, Tanium, Jamf, LastPass, Snyk, OneTrust, Gong, Sprout Social, and Insurity have all publicly confirmed data exposure. The companies that professionally detect and investigate cyberattacks were themselves compromised through a supply chain they trusted.
And this is not an isolated incident. The Klue breach is the third major Salesforce ecosystem OAuth attack in twelve months, following the Salesloft Drift compromise (August 2025, ~760 organizations) and the Gainsight token abuse (November 2025, ~200 Salesforce instances). The playbook is identical each time. The industry has not adapted.
For every enterprise running a modern SaaS stack — and the average enterprise now uses 291 SaaS applications, with large enterprises averaging 473 — the Klue breach is not a news story to read and forget. It is a readiness test your organization is almost certainly failing right now.
The Anatomy of the Attack: How One Token Becomes 195 Breaches
The Klue attack followed a five-stage sequence that security teams should study closely, because every stage exploited a gap that exists in most enterprise SaaS environments today.
Stage 1: Legacy Credential Exploitation (June 11)
The attacker gained initial access through a credential created in 2022 for a prototype integration that was later abandoned. Klue had no credential lifecycle management process that automatically revoked or rotated credentials when projects were discontinued. The credential remained active for four years.
Stage 2: Code Injection for Token Harvesting (June 11-12)
Once inside, the attacker pushed a code update to Klue's integration infrastructure — a backdoor designed to collect OAuth tokens that customers had granted for Salesforce, Gong, HubSpot, SharePoint, Zoom, Chorus, Clari, Google Drive, and Slack integrations. This is the critical escalation point: a single compromised vendor became a credential store for hundreds of downstream organizations.
Stage 3: Automated Data Exfiltration (June 12-16)
Using the stolen tokens, the attacker ran automated Python scripts (identifiable by Python-urllib user-agent strings) that first enumerated each organization's Salesforce object catalog via GET /services/data/v59.0/sobjects, then looped REST API queries against the query endpoint with QueryMore pagination cursors. In at least one environment, nearly a thousand queries hit in 15 minutes. In another, the extraction window lasted over six hours.
Because the queries came through a trusted connected application's OAuth tokens, they did not trigger failed login alerts, geographic anomaly detections, or standard authentication monitoring. The access was indistinguishable from normal application behavior.
Stage 4: Extortion (June 16-22)
The threat actor, operating under the name Icarus, sent extortion emails to affected employees with the subject line "top secret email" and a 48-hour ultimatum. Icarus listed Klue publicly on its Tor-based leak site on June 19 and posted samples of stolen Salesforce data on June 22.
Stage 5: Secondary Compromise (June 24)
In a twist that underscores the chaotic nature of modern cybercrime, a second unauthorized group gained access to the stolen data — apparently by compromising the Icarus operator's own server. This second group launched its own independent extortion campaign against the 195 affected companies. The original attackers were themselves attacked.
Klue has stated it is in communication with Icarus, and that the group claims to be deleting the stolen data. But with a second group now in possession of at least partial datasets, the exposure cannot be contained through negotiation with a single actor.
Why Security Companies Got Breached: The OAuth Blind Spot
The most striking aspect of this breach is not the sophistication of the attack — it used no zero-days, no advanced malware, no novel techniques. It is that the victims include companies whose entire business is detecting and preventing exactly this kind of compromise.
Huntress is a managed detection and response provider. Recorded Future is one of the most recognized names in threat intelligence. HackerOne runs the world's largest bug bounty platform. Tanium provides endpoint management to the Fortune 100. LastPass is a password manager used by millions.
Every one of these companies has mature security programs, dedicated SOC teams, and sophisticated detection capabilities. And every one of them was blind to the attack because it exploited a fundamental gap in how the industry monitors SaaS integrations.
The core problem, as ReliaQuest's analysis put it bluntly: "These integrations are non-human identities with persistent, often broad access to sensitive data, yet they are typically monitored far less closely than employee accounts. That gap is why a 24-hour automated query loop could run from a 'trusted' integration account without tripping the usual alarms."
Obsidian Security's technical analysis confirmed that the Klue integration's baseline traffic was highly stable — it primarily connected from Google Cloud infrastructure — making the deviation to attacker-controlled IPs (138.226.246.94, 94.154.32.160, 212.86.125.24, 213.111.148.90) theoretically detectable. But only if someone was watching.
Almost no one was watching.
The Pattern: Three Attacks, One Playbook, Zero Industry Adaptation
The Klue breach does not exist in isolation. It is the third iteration of a repeating pattern that the Salesforce ecosystem has failed to break:
| Incident | Date | Attack Vector | Downstream Victims | Attacker |
|---|---|---|---|---|
| Salesloft Drift | August 2025 | OAuth refresh tokens stolen from Drift integration | ~760 organizations | UNC6395 / ShinyHunters-linked |
| Gainsight | November 2025 | OAuth tokens from Gainsight integration abused | ~200 Salesforce instances | ShinyHunters-linked |
| Klue | June 2026 | Legacy credential → code injection → OAuth token harvest | ~195 organizations | Icarus (possible ShinyHunters affiliation) |
Three attacks in twelve months. The same playbook each time: compromise a trusted third-party vendor, steal OAuth tokens, use those tokens to query Salesforce APIs at scale, exfiltrate CRM data, extort the victims. The Picus Security analysis calls it the "ShinyHunters domino effect" — one breach, hundreds of victims.
What makes this pattern particularly dangerous is its economics. A traditional cyberattack requires separately breaching each target. An OAuth supply chain attack requires breaching one vendor and inheriting the trust relationships of every customer that has granted that vendor API access. The attacker's cost per victim approaches zero at scale.
And the Salesforce AppExchange ecosystem is enormous. There are thousands of connected applications with OAuth grants to customer Salesforce instances, each one a potential entry point. As Nudge Security warned: "The vector here isn't unique to Klue. It's the model of SaaS-to-SaaS OAuth integration itself."
Framework #1: SaaS Integration Risk Assessment
Every enterprise should run this assessment against their SaaS integration portfolio this week. Score each connected application on these seven dimensions:
The OAuth Integration Risk Matrix
| Risk Dimension | Low Risk (1) | Medium Risk (2) | High Risk (3) | Critical Risk (4) |
|---|---|---|---|---|
| Token Lifetime | Expires <24 hours | Expires <90 days | Expires >90 days | Never expires / unknown |
| Permission Scope | Read-only, single object | Read-only, multiple objects | Read/write access | Admin-level or full API |
| Data Sensitivity | Public metadata | Internal business data | Customer PII/financials | Credentials, tokens, secrets |
| Usage Status | Active, daily traffic | Active, weekly traffic | Dormant (<1 query/month) | Abandoned / no traffic |
| Vendor Security Posture | SOC 2 Type II + pentest | SOC 2 Type II | SOC 2 Type I only | No attestation |
| Monitoring Coverage | API logs + anomaly alerts | API logs, no alerts | Partial logging | No visibility |
| IP Restriction | Allowlisted to vendor IPs | Geo-restricted | Unrestricted | Unknown |
Scoring:
- 7-14 points: Acceptable risk. Annual review cycle.
- 15-21 points: Elevated risk. Quarterly review + monitoring upgrade required.
- 22-25 points: High risk. Immediate remediation: scope reduction, token rotation, monitoring deployment.
- 26-28 points: Critical risk. Disable integration immediately. Re-evaluate business need before re-enabling.
The Klue integration at the time of compromise would have scored 25+ on this matrix — never-expiring tokens, broad API access, a dormant legacy credential, and no anomaly monitoring. Every integration in your environment with a similar score is a pre-breach.
Framework #2: SaaS Supply Chain Incident Response Playbook
When a vendor in your SaaS supply chain is breached, the response sequence matters. Based on the Klue, Salesloft Drift, and Gainsight incidents, here is the playbook that separates the organizations that contained exposure from those that discovered the breach only when extortion emails arrived.
Phase 1: Immediate (0-4 Hours After Vendor Breach Notification)
- Revoke all OAuth tokens (including refresh tokens) for the affected vendor across every connected platform — not just Salesforce. Klue connected to nine platforms; many organizations only revoked Salesforce tokens initially.
- Disable the vendor's connected application in your identity provider and in each downstream platform.
- Capture and preserve API logs for the past 30 days before any log rotation occurs. Salesforce EventLogFile data is critical for forensic timeline reconstruction.
- Alert your legal and communications teams. If you hold customer data in the affected CRM, you may have notification obligations.
Phase 2: Investigation (4-48 Hours)
- Hunt for Indicators of Compromise. In the Klue case, search Salesforce LoginEvent logs for the application name "Klue Battlecards" and cross-reference source IPs against the known attacker infrastructure (138.226.246.94, 94.154.32.160, 212.86.125.24, 213.111.148.90).
- Analyze query volume. Look for REST API calls to
/services/data/v59.0/queryand/services/data/v59.0/sobjectswith QueryMore pagination. Normal integration traffic has a predictable baseline; bulk exfiltration looks like a thousand queries in 15 minutes. - Identify accessed objects. Determine which Salesforce objects (Account, Contact, Opportunity, Case, Lead) were queried. This defines the scope of exposure for downstream notification.
- Check for credential exposure in CRM fields. Attackers in previous Salesforce OAuth campaigns specifically targeted API keys, tokens, and passwords stored in ticket descriptions, notes, or case fields.
Phase 3: Remediation (48 Hours - 2 Weeks)
- Rotate all credentials that may have been stored in or accessible through the compromised CRM data. This includes any API keys, customer credentials, or internal tokens that sales or support teams may have pasted into Salesforce records.
- Implement IP allowlisting for all remaining third-party integrations. Restrict OAuth access to vendor-published IP ranges.
- Deploy API anomaly detection. If you do not have real-time monitoring on SaaS API query patterns, deploy it now. Datadog Security Labs published detection rules for the Klue-specific patterns.
- Scope token lifetimes. Replace long-lived OAuth tokens with short-lived tokens that require periodic reauthorization. Salesforce supports configurable token policies — use them.
- Warn customer-facing teams. Stolen CRM data is a phishing and social engineering toolkit. Prospect and customer contacts in exfiltrated Salesforce records will receive convincing impersonation attempts.
The Deeper Problem: Non-Human Identities Are the New Shadow IT
The Klue breach exposes a structural problem that goes far beyond Salesforce or competitive intelligence tools. The enterprise SaaS stack has created a massive layer of non-human identities — OAuth tokens, API keys, service accounts, integration credentials — that collectively have more persistent access to sensitive data than any human employee, but receive a fraction of the security oversight.
Consider the numbers. The average enterprise uses 291 SaaS applications in 2026. Large enterprises average 473. Each application that integrates with another creates OAuth grants, API keys, or service account credentials. A company with 300 SaaS tools and an average of three integrations per tool is managing roughly 900 non-human identity connections — many of which were created by individual employees, never centrally inventoried, and never subjected to access review.
This is the new shadow IT problem. The first generation of shadow IT was employees installing unapproved software on their laptops. The current generation is employees granting OAuth access to SaaS tools that create persistent, broadly-scoped API connections to core platforms like Salesforce, Google Workspace, and Microsoft 365 — connections that outlive the employee who created them, the project they were created for, and often the vendor relationship itself.
Klue's compromised credential was created in 2022 for a prototype that was abandoned. Four years later, it was still active. How many similar credentials exist in your environment? If you do not know the answer, you are not alone. But you are at risk.
The AI Angle: Why This Gets Worse Before It Gets Better
The OAuth supply chain attack pattern is about to accelerate for a reason the security industry is only beginning to grapple with: AI agents.
As enterprises deploy AI-powered tools across sales, marketing, customer support, and operations, each agent requires OAuth grants to access the platforms it operates on. An AI sales assistant needs Salesforce API access. An AI meeting summarizer needs Zoom and Google Calendar access. An AI customer support agent needs Zendesk, Intercom, or Freshdesk access.
Each of these AI integrations creates exactly the same attack surface that Klue, Salesloft Drift, and Gainsight exploited: a non-human identity with persistent, broad API access to sensitive enterprise data, managed by a third-party vendor whose security posture you do not control.
The IBM X-Force 2026 Threat Intelligence Index found that infostealer malware led to the exposure of over 300,000 ChatGPT credentials in 2025 alone — AI platforms have now reached the same credential risk profile as other core enterprise SaaS. And as the June 2 executive order on AI security acknowledges, the intersection of AI deployment and identity governance is becoming a national security concern.
The question is not whether an AI agent integration will be the vector for the next major OAuth supply chain attack. The question is which one, and how many downstream organizations it will compromise when it happens.
What Your Organization Should Do This Week
The Klue breach provides a clear and specific set of actions every enterprise security team should execute immediately:
1. Audit every third-party OAuth grant. Inventory every application connected to your Salesforce, Google Workspace, Microsoft 365, and other core platforms. For each integration, document: who authorized it, when, what permissions it has, whether it is still in active use, and whether the vendor has a current SOC 2 attestation.
2. Kill dormant integrations. Any OAuth grant that has not generated API traffic in the past 90 days should be revoked immediately. Klue's compromised credential sat dormant for four years. Your environment almost certainly has similar abandoned connections.
3. Implement token lifecycle policies. Replace indefinite OAuth tokens with short-lived tokens (24-hour to 7-day expiration) that require periodic reauthorization. This single change would have made the Klue attack significantly harder to execute at scale.
4. Deploy API-layer monitoring. Authentication monitoring alone will not detect OAuth abuse — the access comes through trusted tokens that do not trigger login alerts. You need monitoring at the API query layer: volume baselines, object access patterns, and anomaly detection for bulk data retrieval.
5. Restrict integration access to known infrastructure. IP allowlisting for third-party integrations is no longer optional. Every vendor-connected application should be restricted to the vendor's published IP ranges. Obsidian Security's analysis showed that legitimate Klue traffic came exclusively from Google Cloud infrastructure — the attacker IPs were from completely different ASNs that would have been caught by a basic allowlist.
6. Treat SaaS vendors as part of your attack surface. Your third-party risk management program should include SaaS integration security posture — not just SOC 2 compliance, but specific questions about credential lifecycle management, token storage encryption, integration monitoring, and incident response capabilities.
The Board Question
The Klue breach puts three questions on every CISO's desk this week:
-
How many OAuth grants exist in our environment that were created by employees who no longer work here, for projects that no longer exist? If the answer is unknown, the answer is "too many."
-
If one of our SaaS vendors is breached tomorrow, can we detect unauthorized API queries through their integration within hours — or will we find out when the extortion email arrives? For most organizations, the honest answer is the latter.
-
What is our total exposure through non-human identities? Add up every OAuth grant, API key, and service account credential across your SaaS stack. That number is your real attack surface. It is almost certainly larger than the number of employee accounts you manage through your identity provider.
The Klue attack is not a sophisticated zero-day exploit. It is a credential that should have been revoked in 2022, an integration that should have been monitored, and an OAuth token that should have expired. Every enterprise has these same gaps. The only question is whether you find them before someone else does.