One legacy credential became OAuth tokens. OAuth tokens became hundreds of customers' Salesforce orgs. Among the victims: Huntress, Tanium, Recorded Future, Snyk, HackerOne. If they can't catch this, better vendor diligence is not the answer.
Ask a security team to name their third-party risk and you will get a list of vendors with contracts — the cloud provider, the payroll processor, the managed detection service. Ask them to name every application an employee has connected to Salesforce with an OAuth grant, and you will get silence, then an offer to go and find out.
That second list is where the compromise came from.
What happened
Klue is a market-intelligence platform — competitive intel, battlecards, the sort of tool a product marketing manager adopts and nobody in security ever hears about. It has more than 250,000 users.
An attacker used a compromised legacy credential to reach Klue's integration infrastructure, harvested OAuth tokens, and used those tokens to pivot into customers' Salesforce environments. Hundreds of customers were affected. Extortion followed, from a group calling itself Icarus, with 48-hour deadlines delivered over Session.
The victim list is the part that should stop a security leader mid-sentence: Huntress, Recorded Future, Tanium, Jamf, Gong, HackerOne, Snyk, Kudelski Security, Sprout Social, Insurity. A meaningful share of them sell security products. Several sell products specifically intended to catch this class of problem.
When the companies that build detection tooling get compromised by the same path, the conclusion is not that they were careless. It is that the path is not visible to anyone using the standard controls — including the people who make them.
Why the questionnaire cannot see this
Third-party risk management rests on an assumption that is quietly false in a SaaS estate: that you can assess a vendor's security and thereby bound your exposure to it.
Two things break that. The first is a matter of timing. A questionnaire measures a vendor's present control set — MFA enforced, SSO available, SOC 2 current. The Klue compromise entered through a legacy credential, which is by definition an artifact of the vendor's history, not its present. Every organization more than a few years old has credentials that predate its current standards. No questionnaire has ever surfaced one, because no questionnaire asks what you have forgotten you still have.
The second is structural. An OAuth grant is not a data-sharing arrangement of the kind procurement understands. It is a standing, self-renewing key into your production system, issued in about four clicks by whoever clicked "Allow," scoped by whatever the application requested rather than by what it needed, and typically without an expiry that anyone chose deliberately. It survives the employee leaving. It usually survives the contract ending.
Visual 1 — Where the model and the reality diverge
What third-party risk management assumes | What the OAuth estate actually is |
|---|---|
Vendors are known, because they have contracts | Grants are made by employees; many connected apps never touched procurement |
Assessment bounds exposure | The attack entered through a legacy credential no assessment asks about |
Data shared is defined in an agreement | Scope is whatever the app requested at consent time, usually broader than needed |
Access ends when the relationship ends | Tokens persist through offboarding and contract termination unless revoked |
The blast radius is the data you sent | The blast radius is everything the token's scope permits, live, now |
Reassessment is annual | A new grant can be created any afternoon, by anyone, with no ticket |
How to read it: Every row on the left is reasonable. Every row on the right is what is actually running. The gap is not a maturity problem you can close with a better questionnaire — the two columns are describing different objects.
The pattern, not the incident
Klue is the clearest case, but it is not isolated, and the enterprise-software layer had a bad quarter generally.
A PeopleSoft zero-day, CVE-2026-35273 (CVSS 9.8), was claimed by ShinyHunters against more than 100 organizations out of roughly 300 vulnerable instances, with about 68 percent of targets in higher education. The University of Nottingham confirmed roughly 40GB exfiltrated. Oracle issued an out-of-band alert on June 12. Separately, an E-Business Suite flaw, CVE-2026-46817, was exploited in the wild before public exploit code existed, followed by a Cl0p extortion wave. Nissan later disclosed possible payroll and Social Security number exposure through a PeopleSoft intrusion.
The common thread across all of it is that the compromise arrived through a system the security team does not operate, via an access path the security team did not grant, into data the security team is nonetheless accountable for.
An aside on reading ransom numbersCoveware's Q2 2026 data puts the average ransom payment at $1,880,612, up 176 percent on the prior quarter. The same dataset puts the median down 50 percent, at $150,000, with the payment rate at a record low. The average is being dragged by a small number of outlier payments. Anyone quoting the average without the median — including in a board pack — is telling a story the data does not support. In the same dataset, lateral movement and exfiltration each appear in 76 percent of cases, and initial access is described as heavily identity-driven, which is the finding that actually matters here.
What to do about it
Inventory the grants before anything else. Your identity provider and each major SaaS admin console can enumerate connected applications and their scopes. Most organizations doing this for the first time find between three and ten times more than they expected, including applications whose vendor no longer exists. The inventory is a day of work and it is the only step that cannot be skipped.
Treat scope as the control, not the vendor's reputation. An application with read access to opportunity records is a different risk from one with full API access to the org, regardless of how good its security program is. Scope minimization survives the vendor being compromised; diligence does not.
Give tokens an expiry and a rotation you chose. Default lifetimes are set for convenience. A grant that must be re-consented periodically fails closed when a vendor relationship lapses, which is exactly the behavior you want and almost never the behavior you have.
Alert on grant creation, not just on grant inventory. A new connected application in a production system is a change to your access architecture made by someone with no change-management obligation. Routing that to a queue where someone looks at it costs almost nothing and closes the window in which a rogue or over-scoped grant sits unnoticed.
Make connection approval a change, not a preference. The reason this estate grows unmanaged is that connecting an app feels like choosing a setting rather than opening a door. That framing is a policy choice, and it can be changed — with the caveat that if approval takes three weeks, people will find another way, and you will be back to an unmanaged estate you can no longer see.
The uncomfortable lesson from the victim list is that this is not a diligence problem. Huntress, Tanium and Snyk are not organizations that skipped their vendor reviews. They were exposed through an access mechanism that sits outside what vendor review examines, in a category of tool nobody classifies as sensitive, granted by people acting entirely reasonably. Until the connected-app estate is inventoried, scoped and expiring, your security posture is the union of every SaaS product your staff has ever clicked "Allow" on — and you do not currently have that list.
Sources and method. A BusinessInfomatics original. Klue compromise, attack chain and named victims as reported by The Register, June 22, 2026. Oracle PeopleSoft CVE-2026-35273 scope, targeting and the University of Nottingham exfiltration per The Register, June 11, 2026; Oracle out-of-band alert June 12, 2026. Oracle E-Business Suite CVE-2026-46817 exploitation per The Hacker News, June 2026. Nissan disclosure per The Register, June 29, 2026. Ransom payment figures from Coveware by Veeam, July 30, 2026 — vendor case data, and cited here with both the average and the median because the average alone is misleading. Readers should note that a widely circulated account dating the Salesloft Drift OAuth campaign to August 2026 is incorrect; that campaign occurred in August 2025 and is not part of the events described here.
