Klue — OAuth integration compromise feeding Icarus Salesforce data theft

What happened

Klue, a Vancouver-based competitive- and market-intelligence SaaS platform used inside enterprise sales organisations, identified unauthorised activity in its integration infrastructure on 12 June 2026. The company traced the intrusion to a compromised legacy credential, which the attacker used to push a code update into the integration layer. That update — automated in Python — silently harvested the OAuth tokens Klue holds to connect to customer environments, most importantly Salesforce, but also Gong, HubSpot, SharePoint, Zoom, Slack and others.

Public disclosure came between 18 and 19 June 2026. Klue notified its customers; Huntress publicly disclosed on 22 June that its own Salesforce tenancy was one of the victims, with an estimated 3.4 GB of Salesforce data exfiltrated. Several other companies followed in the days after. A newly surfaced extortion group calling itself Icarus, active since 28 April 2026, claimed the intrusion, began emailing victims and listed them progressively on a leak site.

The scale, when it firmed up, was substantially larger than the initial named list suggested. Independent analysis of Icarus’s communications and Klue’s customer graph put the number of downstream organisations reached at approximately 195 — enterprises whose Salesforce environments the attackers accessed and paginated through the REST API to bulk-export CRM records. Confirmed victims include Huntress, HackerOne, Recorded Future, Tanium, Jamf, LastPass, Snyk, OneTrust, Gong, Sprout Social and Insurity. The distribution skews heavily toward the enterprise security and DevOps industries — precisely the companies whose sales conversations describe how other companies defend themselves.

Klue engaged CrowdStrike for incident response, revoked the affected credentials and OAuth tokens, disabled the impacted integrations and removed the unauthorised code. Salesforce, on its side, disabled the Klue connected app across its platform, cutting the token-abuse path at the provider end for every customer whether they had noticed or not.

How it worked

The Klue intrusion is a three-step supply-chain compromise in which the attackers never needed to touch the downstream victims at all. Every step of the kill chain took place inside Klue’s own infrastructure, and every action against a customer environment was performed by Klue’s legitimate, pre-authorised integration.

Step one: the attackers acquired valid credentials for a legacy Klue account or service. Klue has described this as a “compromised legacy credential” without specifying the pathway. The obvious candidates are password reuse from an unrelated breach, an unrotated service credential belonging to a former employee or contractor, or a legacy authentication route that the current MFA policy did not fully cover. Whichever it was, the credential unlocked write access to the integration platform’s code deployment path.

Step two: the attackers used that access to push malicious code into the integration layer. The code was an automated Python collector that read from Klue’s OAuth token store — the place where Klue keeps the access tokens customers have granted so that Klue can query Salesforce, Gong, HubSpot, SharePoint and other targets on their behalf — and exfiltrated those tokens to attacker-controlled infrastructure. OAuth grants of this shape are conventionally long-lived and broad in scope; a single Salesforce grant to a competitive-intelligence tool typically covers read access to accounts, opportunities, contacts and custom sales objects across the entire tenant.

Step three: with valid tokens in hand, the attackers queried each victim’s Salesforce environment directly. This is the important part. To Salesforce, the API calls came from Klue’s OAuth application, with Klue’s client ID, presenting a valid token that a customer administrator had authorised. There was no anomalous login, no unfamiliar geography, no failed MFA prompt, no password reset. The Python collector paginated through the REST API’s standard bulk-query endpoints for up to several days per environment and pulled down whatever the token’s scope allowed. On Huntress’s Salesforce alone the pull ran to approximately 3.4 GB.

The clean-up mattered on both sides of the boundary. Klue’s own revocation of tokens shut the tap. Salesforce’s platform-wide disabling of the Klue connected app forced every customer tenancy to re-authorise the integration afresh — the single control that certifies to each customer that no lingering token remains valid. Both steps were needed; either on its own would have left a partial cleanup.

Timeline

• 28 April 2026 — Icarus emerges as a named extortion group, running a leak site with two earlier claimed victims.
• On or before 12 June 2026 — Attackers acquire a compromised legacy credential for Klue’s integration platform, and push a Python code update into the integration layer that begins harvesting customers’ OAuth tokens.
• 12 June 2026 — Klue detects unauthorised activity in the integration infrastructure and engages CrowdStrike for incident response.
• 12–18 June 2026 — Klue revokes affected credentials and OAuth tokens, disables impacted integrations and removes the unauthorised code. Attackers use the previously stolen tokens to query customers’ Salesforce and Gong tenancies via REST API bulk queries, exfiltrating CRM and sales-conversation data for up to several days per environment.
• 18 June 2026 — Klue publicly discloses the breach.
• 19 June 2026 — Salesforce disables the Klue connected app platform-wide, breaking the OAuth token-abuse path from the provider side.
• 22 June 2026 — Huntress publicly discloses that its Salesforce environment was affected, and that Icarus has listed it with an alleged 3.4 GB of exfiltrated Salesforce data.
• Late June – August 2026 — The named-victim list grows to include HackerOne, Recorded Future, Tanium, Jamf, LastPass, Snyk, OneTrust, Gong, Sprout Social and Insurity. Independent analysis puts the number of downstream organisations reached at approximately 195.

What defenders should learn

The first thing to internalise about Klue is that the attacker did not need to defeat anyone at any of the 195 downstream companies. There were no phished credentials, no compromised sessions and no failed MFA prompts on any customer environment. The attacker walked in through a legitimate, pre-authorised integration that every one of those companies had already granted to Klue and mostly forgotten about. From the customer’s logs, this was Klue signing into Salesforce, because it was Klue signing into Salesforce. The credential and the identity were valid.

That has a specific implication for the third-party risk register. Most registers count vendors and score them on a periodic questionnaire. Very few enumerate the OAuth grants those vendors hold, the scopes those grants cover, and the systems those scopes reach into. A Klue-shaped incident is invisible to a register organised around vendors and visible to a register organised around trust boundaries. The unit that determines blast radius is the connected app, not the supplier.

The second lesson is about the shape of the data at risk. The Klue victims did not lose consumer PII in bulk; they lost sales opportunities, pricing, competitive analysis, executive contacts and sales-call transcripts. For a security-industry victim list this is an unusually concentrated intelligence yield. An extortion actor now holds who is negotiating what with whom, at what price, and against which competitor, across a large fraction of the enterprise security market. Whether that ends up monetised on a leak site, sold privately to competitors or used to inform future social-engineering campaigns against those same buyers, the material is more strategically valuable than a bank of email addresses.

The third lesson concerns response controls. Klue’s own detection and revocation was the first-line action. Salesforce’s disabling of the Klue connected app across its entire platform was the second, and it was the one that guaranteed containment across all 195 tenancies simultaneously — including the customers who had not yet been notified. That two-sided model — the vendor cleans its own environment; the platform revokes the integration at source — is the pattern to expect from every OAuth-abuse incident that follows this one. Defenders should already know which of their connected apps their SaaS providers can force-disable centrally, and which they will have to revoke tenant-by-tenant on their own.

The fourth is a segmentation lesson framed sideways. Perimeter and identity controls did not prevent this attack and would not have prevented it, because the perimeter and identity of Klue were the perimeter and identity of the attack. What could reduce impact is a data-flow question: what is the smallest possible scope any single connected app needs against the target system, and what is the smallest possible dataset that scope should be able to read in a bulk query. A Salesforce grant that gives a competitive-intelligence tool read access to every opportunity ever recorded is generous. A grant that limits it to the accounts the tool is actively tracking is narrower and containable. Nothing in the OAuth specification requires the generous scope; it is chosen because the tool’s implementation is simpler that way. Scope minimisation is a real project that pays off exactly when a vendor is next compromised — which, for any organisation that uses more than a handful of SaaS integrations, will happen.

The last lesson is philosophical. The Klue breach is not a story about a novel technique. OAuth token theft in a supply-chain compromise is a well-understood 2020s pattern, and the underlying architecture that permitted it has been the industry’s default for a decade. The story is about how a mature, well-documented risk finally arrived in dozens of large enterprises at once, through a single unremarkable vendor that most of them would have described as low-criticality. The uncomfortable part of writing that up is not the technical detail. It is that every organisation now reading this has connected apps in its own Salesforce, Google Workspace, Microsoft 365 and cloud tenancies, and almost none of them have the same-day answer to the question: which of them, if compromised tomorrow, could pull 3.4 GB of sales data before anyone at your organisation would know.

This incident belongs to the same broad theme as the ShinyHunters Salesforce cluster already in this index — Salesloft/Drift, Cushman & Wakefield, Pitney Bowes and Vimeo/Anodot — but the access technique is materially different and worth separating. The ShinyHunters intrusions started with a phished or vished employee identity. Klue started with a poisoned third-party application: the attacker did not need anyone at the victim organisations to fall for anything. They compromised one upstream vendor, stole the OAuth grants those victims had already issued, and walked in through a trusted, pre-authorised channel.