Drift. Gainsight. Now Klue. And This Time, It Wasn't ShinyHunters.

Salesforce’s response was the same as the last two times: the problem was “limited to the app’s connection” and “does not arise from a vulnerability within the Salesforce platform.” That sentence is true. But the most important fact about this breach is not in Salesforce’s statement. It is in the attribution.

The first two waves were ShinyHunters, one of the most capable extortion crews operating. This one was not. According to Huntress and BleepingComputer, the Klue breach was run by a crew calling itself Icarus, a new outfit with two victims to its name. They ran the ShinyHunters playbook against two cybersecurity companies, and it worked.

When the understudy can run the play and win, the play is no longer a signature. It is infrastructure.

The Token That Walked Out

Sometime on Tuesday, June 16, employees at Huntress opened an email with the subject line “top secret email.” It was not from a customer or a colleague. It was from whoever had spent the prior week quietly pulling data out of Huntress’s Salesforce environment, and it carried a deadline.

Huntress sells managed detection and response. Watching for exactly this kind of intrusion, inside other companies’ environments, around the clock, is the entire product. And the first hard confirmation of how much had been taken arrived in an extortion email, after the fact, the way it does for everyone else.

Here is how the data left, and the dates matter, because the dates are the story.

On June 11, attackers reached the back end of Klue, a competitive-intelligence platform that syncs sales “battlecards” and win/loss data with Salesforce and a dozen other tools. They got in, according to Huntress, through a credential Klue had created for an abandoned integration prototype and never decommissioned. A key nobody remembered, left switched on. They then pushed a malicious code update whose only job was to harvest the OAuth tokens Klue’s customers use to connect Klue to their own systems — not just Salesforce, but HubSpot, SharePoint, Slack, Zoom, Gong, and Google Drive.

By June 12, Klue had spotted connections to servers it did not recognize and was deactivating tokens. By the 13th it was warning customers. By Tuesday the 16th, customers were getting extortion emails. By Wednesday the 17th, Salesforce had cut the Klue connection and posted a notice about “unusual activity” that “may have resulted in unauthorized access to a subset of customer data.”

In between those dates, the theft happened. ReliaQuest, which surfaced the campaign, describes automated scripts firing close to a thousand queries in fifteen-minute bursts against the Salesforce API, with extraction running past six hours. Picture it: not a smash-and-grab, but a patient, steady pull, paced to look like an integration doing its job, running for most of a working day against a token the platform had no reason to doubt.

A legitimate key, used quietly, through a door that was already open.

Now notice what is absent from this story, because its absence is the whole point. There is no cover-up. No status page ran a comforting lie while the building burned. Klue moved in a day. Salesforce moved within the week. Huntress told the truth about its own breach in public, in detail, while the extortion clock was still running. Every party behaved roughly as you would want them to. The data walked out anyway, and the bill is arriving anyway. When a breach this large can happen with no one acting in bad faith, the failure is not a failure of conduct. It is a failure of structure, and structure is harder to fix than conduct, because there is no one to fire.

The Pattern: Three Apps, Ten Months, One Door

The individual stories have been covered well. The line connecting them has not.

August 2025: Salesloft Drift (ShinyHunters)

Attackers stole the OAuth tokens that Drift, an AI chat widget, used to talk to Salesforce, then used them to walk into customer orgs and download the Account, Contact, and Case tables. ShinyHunters claimed roughly 1.5 billion records from about 760 companies, a figure BleepingComputer reported from the group directly. The marquee victims were Palo Alto Networks, Zscaler, Cloudflare, and Google. How did they get the tokens? Months earlier, in March 2025, they had breached Salesloft’s GitHub repository and read the code.

November 2025: Gainsight (ShinyHunters)

Same crew, different app, and here is a connection few drew at the time: Gainsight was itself a Salesloft Drift customer. When Drift fell, Gainsight was exposed, and the campaign moved on to abuse Gainsight’s own Salesforce-connected apps. Google’s threat team put the blast radius above 200 Salesforce instances. Gainsight’s CEO, Chuck Ganapathi, told the press he was aware of “only a handful of customers” affected. Both numbers cannot be right, and the gap between a vendor’s count and a forensics team’s count tends to close in one direction.

June 2026: Klue (Icarus — a new crew)

Same playbook. Different hands. Huntress and BleepingComputer attribute this wave not to ShinyHunters but to a new extortion crew calling itself Icarus, operating under the alias “Mr Brean,” active only since late April and carrying two prior victims. ReliaQuest, careful as ever, could not confirm attribution and noted only that the activity matches the established OAuth-abuse playbook. Either way, the conclusion is the same and it is the one that matters: the crew that pioneered this technique is not the crew that just ran it.

The Playbook Outlived Its Inventors

This is the finding the day-of coverage is treating as a footnote, and it is the headline.

For ten months, the defense against this class of attack has quietly rested on an assumption: that it took ShinyHunters to pull it off. A crew with years of operational history, a track record against Fortune 100 targets, and the patience to breach Salesloft’s GitHub six months before using what they found there. Hard to do, done by hard people, a known quantity to track.

Icarus is not that. Icarus is six weeks old with a two-victim résumé. And Icarus ran the same play, against Huntress and Recorded Future, and walked out with the data.

That is what commoditization looks like. The technique has detached from the group that invented it. It no longer requires a nation-state-adjacent crew or a GitHub heist staged half a year in advance. It requires a compromised app, a harvested token, and a script. The barrier to entry has collapsed, which means the right mental model for every Salesforce customer is no longer “are we a target for ShinyHunters?” It is “this is now a standard technique that any new crew can pick up, and the next one will not announce itself.”

When the understudy runs the play and wins, the play is no longer a signature. It is infrastructure. And you do not get to wait for attribution before you defend against infrastructure.

What “Not Our Vulnerability” Accounts For — and What It Doesn’t

Notice what is missing from all three incidents: a Salesforce vulnerability. There isn’t one. Salesforce is right. Its platform was not breached in August, in November, or this week.

So look closely at what the sentence “not a vulnerability within the Salesforce platform” actually does. It accounts for the integrity of Salesforce’s code. It does not account for the design decision that any connected app gets a long-lived token with broad read access to the customer’s most sensitive data store. It does not account for the near-total absence of native alerting when one of those tokens suddenly behaves like an exfiltration script. It does not account for the fact that the platform will faithfully serve a thousand API calls in fifteen minutes to a token it was told to trust. The sentence is a statement about the code. The breach was a property of the design. The gap between those two things is exactly where 760 companies, then 200, then Klue’s customers lost their data.

The door is not malfunctioning. The door has no lock that anyone is watching. That is a design, and a design is a choice.

What Every Salesforce Customer Should Do Now

Given that the platform has now, three times, pointed elsewhere, here is what the people who own these orgs can do. None of it is exotic.

1. Inventory every OAuth-connected app touching your CRM and your identity provider. Not the ten you remember. All of them. Klue’s entry point was a credential its own vendor had forgotten; your version is the integration a departed admin wired up in 2023. You cannot govern access you have never enumerated.
2. Scope every token to least privilege, and revoke the standing access you don’t need. A battlecard tool does not need read access to your entire Account and Contact object. If it has it, that is a setting you can change today.
3. Monitor API behavior, not just logins. Every one of these thefts looked, at the authentication layer, like a legitimate integration. The tell was the volume and pacing. Detection that stops at “valid token, valid login” will never see it.
4. Rotate and re-scope on a schedule, not on an incident. A token you issued and never rotated is a key you handed out and never asked back.
5. Treat your vendors’ breaches as your breaches. Klue’s incident became Huntress’s incident the moment a token was stolen. Plan for how you find out, and how fast you can revoke, because you may hear it first from an extortion email.
6. Map the second-order graph. Gainsight was exposed because it used Drift. Your exposure is not just your apps; it is your apps’ apps. Their supply chain is now yours.

The Reckoning

The consequences here run well past one more breach notice, and most of them are arriving quietly.

The Victims Are the Security Industry

Start with who got hit, because it dismantles the comfortable story executives tell themselves.

When attackers reached Huntress’s Salesforce data through Klue, Huntress was not a company that had skimped on security. It runs a security operations center that watches other companies’ environments for exactly this kind of intrusion, every hour of every day, for a living. It had the tooling, the threat intelligence, and the institutional paranoia its own customers pay it to supply. The CRM data walked out anyway.

Here is the part that is almost too neat. In April 2025, Huntress launched a product called Rogue Apps, billed as the industry’s first proactive protection against malicious OAuth applications — the exact technique at the center of this entire wave. Its own researchers had analyzed more than 20 million OAuth apps and warned that compromised ones let attackers steal data quietly and build invisible backdoors. Fourteen months later, Huntress lost its own Salesforce data to a compromised OAuth app.

That is not a product failure, and it is worth being precise about why. Rogue Apps watches the OAuth apps inside a company’s own Microsoft 365 and Google Workspace. The token that drained Huntress’s CRM did not live there. It lived in Klue’s back end and reached into Salesforce, three companies removed from anything an identity product was positioned to see. The firm that built the first defense against malicious OAuth apps got hit by one anyway, through the one door that defense does not cover. The best detection team in the building cannot watch a door inside a vendor’s vendor.

Huntress was not the only irony in the victim list. In November, when ShinyHunters hit Gainsight, the threat-intelligence firm Recorded Future published a careful public explainer on that exact OAuth breach — how trusted SaaS integrations become a supply-chain risk, how one compromised app can expose data across many. Seven months later, Recorded Future was on the list of companies whose Salesforce data was taken through Klue. The firm that wrote the warning became the case study.

Neither company is the exception. Palo Alto Networks had all of it too, back in August. So did Zscaler. So did Cloudflare. CrowdStrike, F5, and SonicWall sat on the November list. These are the companies the rest of the market pays to define what good security looks like, and the same kind of stolen token walked out of each of them, through an app they trusted, while their own defenses reported nothing wrong. The breach happened anyway.

That is the part executives need to sit with. This was not a competence gap the victims could have closed by trying harder. The firms that sell detection could not detect this on their own data, because the entire category of risk lives in a blind spot the current tooling was never built to watch: the standing access held by software you connected once and then stopped thinking about.

What Salesforce and the App Vendors Should Have Done

Set aside whether Klue could have prevented its own breach. Vendors get breached; that is a permanent condition of using software, not a scandal. What is not a hard problem is the part everyone downstream could see coming. A few of these belong to the app vendors. Most belong to the platform.

1. Cap what a connected app’s token can reach by default. A token issued to a battlecard tool should not be able to read an entire customer’s CRM unless someone deliberately widened it. Broad scope should be an opt-in, not an inheritance.
2. Expire tokens, and make customers re-consent. Long-lived, never-expiring tokens are why a key stolen in August was still useful in November. A default expiry turns a permanent master key into a temporary one.
3. Alert on token behavior the way every platform alerts on logins. Impossible-travel and new-device prompts are standard at the login layer. The equivalent for integration tokens — a sudden thousand-query burst from a sync that normally moves dozens of records — barely exists. It should be native and default.
4. Kill dormant and prototype credentials automatically. The Klue intrusion started with a forgotten test credential. Access unused for a defined window should expire on its own.
5. Give customers a live view of their own token surface. Most Salesforce admins cannot answer, in one screen, “which apps hold tokens into our org, what can each reach, and when did each last do something unusual.” That dashboard is buildable. Its absence is why the inventory above is hard.

None of these is new technology. Most existed as options the day the first token was issued. They are not defaults because defaults tuned for frictionless integration sell better than defaults tuned for the morning a vendor’s back end is compromised. Three campaigns in ten months — and a new crew able to join the trend on week six — are the invoice for that tradeoff.

Where the Liability Actually Lands

Here is the structural problem underneath all of it.

At every hop of this chain, accountability gets a little thinner. The customer trusts Salesforce. Salesforce trusts the connected app the customer authorized. The app trusts its own back end, its own contractors, its own forgotten credentials. Responsibility diffuses a little further at each step, until at the end of the chain there is a prototype token nobody owns and an attacker nobody invited.

Legal liability does not diffuse that way. It stays bolted to the company whose name is on the customer records.

When a Klue customer’s pipeline data, contract values, and sales correspondence are exfiltrated and ransomed, it is that customer — not Klue, not Salesforce — who owns the consequences. “Our vendor’s vendor was breached” is a true sentence and a complete explanation. It is not a defense, and it is not a notification exemption. The data owner assesses materiality, files the disclosures, notifies the affected people, and answers the lawsuit. The party with the least control over the breach carries the most exposure from it. That is the asymmetry the market has not yet priced.

And the obligations are not abstract. A public company among the victims has to weigh whether the loss is material under the SEC’s four-business-day Form 8-K Item 1.05 rule. A victim that is a financial institution falls under the FTC Safeguards Rule’s notification timeline. Customer records covering residents of essentially every U.S. state trigger that state’s breach-notification statute, several carrying per-record penalties and private rights of action. Any EU personal data in those CRMs starts the 72-hour clock under GDPR Article 33. “This was a third-party app, not us” stops none of those clocks. They all run against the data owner.

The Thread Back to Canvas

One more line is worth drawing, because it explains why this keeps happening.

The technique now being run by a six-week-old crew was pioneered by ShinyHunters, and Cloudskope has been tracking its arc since May. The same group took the Canvas learning platform offline during finals week, claiming 275 million records across 8,809 schools — and Instructure’s first compromise by that group, in September 2025, came through its Salesforce environment. Same platform, same OAuth-trust weakness, one rung down the supply chain.

What has changed in the nine months since is the part that should worry boards. In September, this was the work of a specific, trackable, sophisticated crew. By June, it is a method a newcomer can pick up off the shelf. We wrote at the time that a company’s belief an incident is over is not evidence that it is. The update to that lesson is sharper: the absence of ShinyHunters from your threat briefing is not evidence that you are safe from ShinyHunters’ technique. “Contained” is a status a company assigns itself. The playbook is a fact about the world.

What Boards and Deal Teams Should Ask This Week

In private-equity diligence, the CRM is the single richest data store in the target company, and it is almost never on the security checklist as a system in its own right. Buyers ask about endpoints, firewalls, the SOC 2 report, the pen test. Almost no one asks the target to enumerate every third-party app holding a live OAuth token into the CRM and the identity provider, with the date each was last reviewed.

A target can hand you a clean penetration test, a current SOC 2 Type II, and a tidy org chart, and still be one forgotten battlecard-tool token away from a 48-hour extortion clock. The clean report and the open door are not contradictions. They are the normal state of affairs, and this week is what it costs.

So three questions, worth more than any single finding. Ask your portfolio companies before someone else asks them for you:

• Who holds a standing OAuth token into our CRM and our identity provider, and when did we last look?
• If a SaaS vendor’s back end is compromised tonight, how do we find out, how fast, and from whom?
• What can a single stolen integration token reach, and is that scope a decision we made or a default we accepted?

If any answer is a pause, you have found the door before the attacker did. This week, three times over, and now with a crew that didn’t even exist in the spring, the attacker found it first.