The Klue OAuth Breach: When a Dormant 2022 Credential Took Down LastPass, Snyk, and HackerOne

Between 11 and 24 June 2026, an extortion group calling itself Icarus used a dormant service-account credential inside a Vancouver-based market intelligence firm called Klue to harvest OAuth tokens for approximately 200 downstream Salesforce environments. Eleven weeks on, the publicly confirmed victim list has grown from the initial thirteen names disclosed in June to more than sixteen and includes LastPass, Snyk, HackerOne, Tanium, Huntress, Recorded Future, ReliaQuest, Jamf, Sprout Social, Gong, Insurity, OneTrust, BeyondTrust, 8x8, Pendo, and others. FINRA issued a member alert in late July. The public reporting is now extensive. See BleepingComputer, SecurityWeek, Cybersecurity Dive, Datadog Security Labs, and Huntress.

Eleven weeks is long enough that the initial reporting has settled into a clearer picture. What began as one incident at one Vancouver SaaS vendor became, over the course of the summer, the reference case for an attack pattern the industry now has a name for: OAuth pivot from a compromised SaaS integration hub. Microsoft dedicated a full research blog to defending against ShinyHunters-style OAuth abuse in July. The Cloud Security Alliance published a research note framing 2026 as the year of the OAuth pivot. Klue is the incident that crystallised all of it.

Three things about the Klue incident are still worth writing about that the standard advisories underweighted at the time and continue to underweight now. The credential that let Icarus in was four years old and unused. The blast radius was not Klue's own systems, it was every Salesforce environment a Klue customer had connected. And the confirmed victim list is disproportionately security vendors. This is V-Spot's retrospective reading of what those three facts mean together, and the OAuth attack surface every SaaS-heavy team is still carrying whether they have inventoried it or not.

The four-year-old credential that killed sixteen companies

The initial access vector is the story most worth internalising. According to Klue's own disclosure and the follow-up reporting, Icarus obtained a service-account credential that had been created in 2022 for an integration prototype that Klue never shipped. The credential stayed alive in Klue's backend infrastructure for four years. No one revoked it. No one rotated it. No monitoring caught its continued existence, presumably because nothing about its behaviour was anomalous until Icarus used it.

This class of credential has a name in the SaaS security literature. It is a non-human identity, or NHI. NHIs are the API keys, service accounts, OAuth tokens, and integration credentials that machines use to authenticate to other machines. NHIs now vastly outnumber human identities in most enterprise environments, by ratios that vendor reports commonly place between ten and forty NHIs per human account. The governance discipline around NHIs is nowhere near the discipline around human credentials. Human accounts get provisioned, reviewed, deprovisioned, and audited. NHIs get created, forgotten, and inherited by whoever owns the system next.

The Klue incident is the archetypal NHI failure. A single credential lived for four years past its intended purpose. When Icarus obtained it, no human at Klue was ever going to remember it existed. The only reason it left a trace at all is that Icarus pushed a code change with it on 11 June, which Klue's monitoring caught the following day. If Icarus had used the credential to read data instead of write it, the compromise might still be undetected.

The uncomfortable question every engineering leader should be asking, eleven weeks after Klue and with the pattern now fully documented, is not whether their company has a four-year-old service account somewhere. It is how many they have, and how they would know.

Why the blast radius reached companies that never touched Klue

The second fact worth underlining is that the direct victims of this breach were not Klue's data. Klue is a competitor intelligence platform for sales teams. Its product, called Battlecards, integrates with the CRM and collaboration tools its customers already use. The list of supported integrations, per the public reporting, is Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive, and Slack.

Every one of those integrations requires an OAuth token. When a Klue customer connects their Salesforce to Klue Battlecards, they grant Klue a scoped OAuth token that Klue can present to Salesforce to read customer records, sales activity, and account context. That token, from Salesforce's perspective, is Klue. Its actions are indistinguishable from Klue's own automated calls. It has whatever scopes Klue asked for during the OAuth grant flow, which for a competitor intelligence tool typically includes broad read access across the CRM.

When Icarus obtained access to Klue's backend on 11 June, they pushed a code change that captured these OAuth tokens as customer integrations refreshed. The tokens themselves are what Icarus stole. The tokens were the payload. And with those tokens, Icarus could then connect directly to each customer's Salesforce environment, presenting valid credentials that Salesforce could not distinguish from Klue's legitimate automation.

The reported exploitation was industrial. Automated Python scripts, per Datadog Security Labs' reconstruction, ran against victim Salesforce instances and exfiltrated CRM data in bulk. One estimate cited in the reporting placed the average bulk exfiltration at roughly fifteen minutes per environment. Icarus did not need to log into any of the roughly 200 downstream companies' networks. They needed only to be Klue, which the OAuth tokens made them.

The data taken was not source code, not infrastructure, and not consumer data. It was CRM data. Names, emails, phone numbers, physical addresses, sales notes, price quotes, competitive intelligence reports, and account context. The kind of data that enables the next round of social engineering, spear-phishing, and vendor impersonation attacks, at industrial scale, against the sales teams of every affected company.

The pattern is not new. The pattern is a pattern now.

The third fact worth putting on the record, and the one the summer confirmed, is that the technique behind the Klue breach is not novel. By August 2026, it is the reference case for an attack class the industry now names.

The precedent was Drift, earlier in the year. Drift is a conversational marketing platform. The same primitive was used. A compromise of the intermediary hub gave an attacker OAuth tokens for its customers' Salesforce environments, which were then used to exfiltrate CRM data. Delinea's analysis, published shortly after the Klue disclosure, explicitly frames Klue as a repeat of the Drift attack pattern.

What emerged over June, July, and August is that Drift and Klue were not two isolated incidents. They were the visible early cases of an OAuth abuse campaign class that also included the ShinyHunters cluster, which Microsoft's own security research team dedicated a full blog post to defending against in July. The Cloud Security Alliance published a research note on ShinyHunters' OAuth pivot framing 2026 as the year OAuth token theft moved from niche to primary. Google Threat Intelligence tracks related activity under UNC6395 and UNC6040, the second of which has been linked in AppOmni's analysis to the ShinyHunters cluster. The names and the entry points differ. The primitive is the same.

The class of target is easy to identify. Any SaaS product whose value proposition is that it integrates with your CRM is, structurally, a candidate. Marketing automation tools, competitor intelligence tools, revenue operations tools, sales enablement tools, customer support tools, forecasting tools, note-taking tools. All of them hold OAuth tokens for their customers' CRMs. All of them are, from the attacker's perspective, a shorter path to the CRM than attacking the CRM directly. Drift and Klue proved the primitive works at scale. ShinyHunters proved it generalises across actors.

The security-vendor victim list is the story

The most uncomfortable fact about the confirmed victim list is who is on it. LastPass. Snyk. HackerOne. Tanium. Huntress. Recorded Future. ReliaQuest. BeyondTrust. Not the peripheral names in the security industry. Some of the largest. Snyk sells software supply chain security. HackerOne sells vulnerability disclosure. Tanium sells endpoint visibility. Huntress sells managed detection. LastPass sells credential management. BeyondTrust sells privileged access management.

This is not a coincidence. Cybersecurity vendors run more mature security programmes than the median enterprise. If the confirmed victim list is heavily weighted toward security vendors, the plain reading is that mature security programmes were not sufficient to prevent this class of attack. The four-year-old credential inside Klue was not the security vendors' problem to fix. The OAuth token their sales team granted to Klue Battlecards was.

The industry response so far has largely emphasised what the security vendors did right. LastPass emphasised that its products, services, and core infrastructure were not affected. Snyk and others emphasised that they had already disabled the Klue integration. Those statements are true and they are also the wrong lens. The vendors that appear on the confirmed list are the ones who chose to acknowledge the exposure publicly. The vendors that appear on the leak site but not on the confirmed list are the interesting cohort. The vendors that were exposed but do not yet know it are the largest cohort.

The OAuth token audit every team should have already run

If your organisation uses Salesforce, HubSpot, or any comparable system as its system of record for sales, marketing, or customer data, the actionable output of the Klue incident is a directed audit of your OAuth grants. Not a general SaaS review. Not a compliance exercise. Specifically OAuth tokens issued from your primary CRM and collaboration tools to third-party integrations.

The four questions to answer in writing, per integration:

1. Which OAuth integrations does this system currently have? For Salesforce, this is visible under Setup → Connected Apps OAuth Usage. For HubSpot, under Settings → Integrations → Connected Apps. Enumerate them. Include the ones nobody currently uses.

2. What is the granted scope of each? Read-only against a specific object type is a different exposure profile from full CRM read. Broad read scopes on the primary customer object should be scrutinised. If the integration's product function does not obviously require the scopes it was granted, it was overscoped at grant time.

3. When was each token last used, and by which client? OAuth logs show this. Integrations that have not been used in the last ninety days are, in most cases, safe to revoke. Integrations that have not been used since a vendor changed products or your team churned should be revoked.

4. If this vendor is compromised tomorrow, what data walks? This is the modelled question. Answer it before an incident forces the exercise. The answer determines whether the integration is worth the risk it carries.

The point of the audit is not to eliminate every integration. That is not realistic and it would break your revenue team. The point is to convert an implicit trust decision that was made once, often years ago, into an explicit reviewed inventory. The four-year-old credential inside Klue is not the point. The four-year-old OAuth token in your own environment is.

Seven concrete moves, if you have not already run them

For teams that want a tactical playbook rather than a framework, the moves below are the ones V-Spot researchers would prioritise if given a week and a Salesforce administrator:

1. Enumerate every OAuth grant against your primary CRM, then repeat for HubSpot, Slack, SharePoint, Google Drive, and Zoom. Export the list. This is your NHI baseline and you probably do not currently have one.

2. Revoke every grant older than twelve months without a documented business owner. Departed vendors, deprecated tools, and proof-of-concept integrations that never became real are the cohort. If nobody can name the owner, revoke it.

3. For the surviving grants, request a written attestation from the vendor of their internal credential hygiene. Include NHI review cadence, service-account rotation policy, and detection controls on their own backend. Vendors that cannot answer these questions are the next Klue.

4. Turn on Salesforce Event Monitoring on the object types that would matter most. For most companies this is Account, Contact, Opportunity, and Case. Alert on bulk read patterns that do not match the integration's known usage baseline.

5. Reduce the scopes of any integration that was granted more than it needs. Most CRM OAuth grants were negotiated at initial vendor onboarding by people with no security context. The scopes are often broader than the product actually uses.

6. Rotate OAuth tokens on a defined cadence, defaulting to ninety days. Where the integration does not support scheduled rotation, add it to the vendor's next contract review as a required capability.

7. Enable monitoring on your CRM API traffic from the integration's known egress IPs. Bulk exfiltration campaigns look very different from normal integration traffic even without deep content inspection. Egress patterns alone are usually sufficient to alert.

The V-Spot research division applies the four-question dependency review framework to package dependencies. The framework above is its equivalent for OAuth integrations, which is a different, and in many organisations larger, dependency surface.

What the summer confirmed, and what it did not

What was called and landed. In the days after the initial June reporting, V-Spot's internal read was that the confirmed victim count would grow past the twenties and that the total exposed set would end closer to Icarus's claim of ~200 than to the initial confirmed count of thirteen. Both were correct. By late July the confirmed victim count crossed sixteen and continues to grow, with 8x8, Pendo, and others joining, and FINRA issuing an industry alert. The gap between confirmed and exposed remains large, which means most Klue victims are still working through their own disclosure decisions.

What the summer surfaced that Klue alone did not. The ShinyHunters campaign that Microsoft dedicated a July research post to made clear that Klue was not the only game in town. The OAuth pivot attack class is now demonstrated across at least three distinct actor clusters (Icarus, ShinyHunters, and the Drift-linked activity Google tracks as UNC6395) operating against overlapping target sets. The migration required to defend against any one of them defends against all three, which is the one piece of good news in the analysis.

What is still an open question, close to eleven weeks on. The industry has now recognised the class of problem, produced significant research on it (CSA, Microsoft, AppOmni, Datadog, Delinea, and others), and yet OAuth token inventory and NHI governance are still a minority discipline in most enterprises. The defensive response is running weeks behind the offensive one. The next major incident of this class will not be a surprise. It will land against a vendor most of the industry has never heard of, and the response cycle will begin again.

The underlying observation still holds. Two large-scale demonstrations became four, and the four became a documented attack class. The defensive migration required to make it uneconomical remains substantial. The offensive migration required to keep running it remains trivial. In that asymmetry, the attackers are still ahead.

The V-Spot lens

The wave of hardening advice that followed the Klue disclosure has emphasised revoking the Klue Battlecards integration, monitoring Salesforce for anomalous access, and rotating credentials. All of that is correct. None of it addresses the class of problem.

The class of problem is that SaaS-to-SaaS integrations rely on OAuth tokens that most organisations do not track, do not audit, do not rotate, and cannot revoke at speed. The class of solution is that OAuth grants must be treated with the same governance discipline currently applied to human privileged access. Named owner. Documented purpose. Scheduled review. Automatic expiration. Alerting on anomalous use.

Klue was the second warning shot. ShinyHunters was the third. The fourth is already being run against a vendor whose name is not yet in any advisory. Enough organisations have absorbed the discipline that the industry no longer treats OAuth pivot attacks as an emerging threat. Not enough have absorbed the discipline that the average enterprise has an OAuth token inventory it can act on. The Klue victims paid for the industry's education. The right response is to use their bill to fund your own audit.

If you are mid-response on the Klue incident, or auditing OAuth grants across your CRM stack, V-Spot's research division and offensive security team can help. We are tracking this class of incident and running audits against it for our clients.

The Klue brief sits inside V-Spot's broader supply chain security coverage. For the wider actor-tracking arc, see the TeamPCP research series. For the methodology V-Spot applies to third-party dependency and integration reviews, see the V-Spot four-question dependency review.

---

Sources:

• Klue OAuth breach linked to Icarus Salesforce data theft attacks, BleepingComputer
• More Klue Breach Victims Identified as Hackers Get Hacked, SecurityWeek
• Klue investigating supply chain attack that targeted Salesforce integrations, Cybersecurity Dive
• Detecting the Klue supply chain attack in Salesforce instances, Datadog Security Labs
• LastPass confirms data breach in Klue supply chain attack, BleepingComputer
• Cybercrime Breaches Klue: Salesforce Data Impacted for Many Victims, Huntress
• Klue Supply Chain Compromise and CRM Data Exfiltration Incident Advisory, Kudelski Security
• The Return of the SaaS Supply Chain Attack: From Drift to Klue, Delinea
• Defending SaaS-based applications against ShinyHunters OAuth abuse, Microsoft Security Blog
• ShinyHunters' OAuth Pivot: A Year of SaaS Supply-Chain Breaches, Cloud Security Alliance