Klue Supply Chain Breach: Icarus Hits HackerOne, Snyk and 8 More Firms

On June 12, 2026, a cybercrime group called Icarus breached Klue — a market intelligence SaaS platform used by enterprise sales and competitive intelligence teams — and used that access to steal OAuth tokens from Klue's integration layer. Those tokens gave Icarus read access to the Salesforce environments of at least ten named companies, including HackerOne, Snyk, Recorded Future, Jamf, OneTrust, Tanium, Gong, Sprout Social, Insurity, and Huntress. Salesforce was forced to disable the Klue integration entirely. CrowdStrike is handling incident response.

This is not a conventional data breach. It is a supply chain attack: one vendor compromised, ten customers downstream exposed. Every engineering team that uses third-party SaaS integrations with CRM access should read what happened here.

What Klue Is and Why It Had Access to Salesforce

Klue is a competitive intelligence platform. It aggregates product, pricing, and market data from across the web and syncs it with enterprise CRM systems — primarily Salesforce — so that sales teams can see competitive context alongside their deal data. To do that, Klue holds OAuth tokens that authorize it to read and write to customers' Salesforce instances.

That authorization model is standard practice in B2B SaaS. The problem is what happens when the vendor holding those tokens is compromised. The OAuth token is a standing authorization, not a one-time credential. Once Icarus had the tokens, they had persistent, API-level access to each customer's Salesforce data without needing to touch the customer's own infrastructure at all.

This is the structural risk of deeply integrated SaaS ecosystems. The attack surface is not just your own systems — it is every vendor you have granted OAuth access to, and every security decision that vendor has made about how they store and protect those tokens.

The Attack Chain: Step by Step

June 11-12, 2026: Initial Compromise

Icarus gained access to Klue's integration infrastructure using a compromised legacy credential tied to a service account. The credential was associated with an integration tool — the kind of service account that handles connections between systems and often gets created during early product development, then forgotten as the product matures. Legacy credentials that retain elevated permissions but are no longer actively monitored are one of the most common initial access vectors in enterprise breaches.

June 12: Malicious Code Update

After gaining access, Icarus pushed a malicious code update within Klue's integration infrastructure. This update was designed to harvest OAuth tokens — the authorization keys that Klue uses to connect to customers' Salesforce environments. The malicious update intercepted or extracted these tokens as they were used or stored.

June 12: Data Exfiltration

With OAuth tokens in hand, Icarus made API calls to affected customers' Salesforce instances and exfiltrated data. Because the requests came with valid OAuth tokens, they looked like legitimate Klue integration activity from Salesforce's perspective. No customer authentication was required. No customer network was touched.

June 12: Discovery and Response

Klue identified the unauthorized activity on June 12 and notified customers the same day. Klue immediately revoked affected credentials and disabled integrations across Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive, and Slack. Klue engaged CrowdStrike for incident response and forensic investigation and notified law enforcement.

Salesforce separately disabled the Klue application integration at the platform level.

Who Icarus Is

The Icarus cybercrime group is new. Their own leak site states they have only been active since April 2026 and have indicated only two prior victims unrelated to Salesforce-connected attacks before Klue. This was their largest claimed operation to date.

Icarus operates a ransomware-adjacent model: breach, exfiltrate, threaten to publish on their leak site unless paid. They announced on June 22 that they would publish the stolen data if Klue did not pay. This business model is increasingly common among groups that do not use traditional ransomware encryption — they hold data publication as the leverage rather than locking systems.

The fact that a group active for only two months was able to execute a supply chain attack that hit ten known enterprise security and technology companies is a signal about how low the barrier has become for this kind of operation when the initial vector is a legacy credential rather than a sophisticated zero-day exploit.

What Was Stolen: Company-by-Company

The affected companies disclosed varying scopes:

HackerOne: Business relationships and sales activity, including business contact information (email and phone numbers) and sales account and opportunity records. HackerOne noted that no vulnerability disclosure data, security reports, or bounty information was accessed.

Snyk: Business data within Salesforce environments, including customer business contact information and a limited subset of customer support case titles and descriptions.

Recorded Future: Business contact and CRM data from Salesforce. Recorded Future has not disclosed specifics beyond confirming the impact.

Jamf: Confirmed data exposure from Salesforce CRM records. Jamf provides Apple device management to enterprise customers, so the exposed data likely includes contact information for IT and security administrators at those organizations.

OneTrust, Tanium, Gong, Sprout Social, Insurity, Huntress: All confirmed impact. Huntress published a detailed incident response blog post documenting the breach from their perspective.

The common pattern across disclosures: the data stolen was business CRM data — contacts, deal records, account information — not product data, source code, or security infrastructure. That limits the direct harm but creates secondary risk through targeted phishing against the exposed contacts.

The OAuth Token Problem: Why This Keeps Happening

The Klue breach is not an isolated incident. OAuth token theft from SaaS integration layers has become a recurring attack pattern because it offers attackers a clean, API-authorized path into customer environments without triggering the network-level detection that more traditional attacks would.

The core issue: when you grant a SaaS vendor OAuth access to your Salesforce, GitHub, Google Workspace, or Slack, you are creating a standing authorization that lives in that vendor's infrastructure. The security of that authorization is now partly dependent on the vendor's credential hygiene, their code security, and their monitoring capabilities.

Most enterprise security teams audit their own infrastructure thoroughly. Far fewer audit the OAuth grants they have made to third-party vendors, monitor those vendors' security posture continuously, or have processes to revoke and rotate OAuth tokens when a vendor has a security event.

Developer and Security Team Action Items

Immediate:

• Audit all active OAuth grants in your Salesforce, Google Workspace, GitHub, Slack, and HubSpot accounts. Most platforms have an "authorized applications" or "connected apps" section that lists every third-party integration with active access.
• Identify any Klue-connected grants and revoke them if you have not already.
• Check whether you received a notification from Klue about the June 12 incident.

Short term:

• Review your process for approving SaaS integrations that request CRM-level OAuth access. Who approves these? Is there a periodic review cycle?
• Implement OAuth token rotation policies for high-sensitivity integrations. Some platforms allow you to set expiry on OAuth grants.
• Check your Salesforce audit logs for unusual API activity between June 11-15 from Klue's integration service accounts.

Structural:

• Treat third-party OAuth grants as part of your attack surface, not as routine administrative tasks. The credentials you hand to vendors are your credentials in their custody.
• Prefer integrations that use field-level access scoping over broad Salesforce object access.

What This Means for the SaaS Security Market

The Klue breach will accelerate demand for a product category that has been growing but has not yet become standard: SaaS Security Posture Management (SSPM). SSPM tools continuously monitor which third-party applications have OAuth access to your core platforms, flag overprivileged grants, and alert when a connected vendor has a known security event.

Companies like Obsidian Security, AppOmni, and Wing Security operate in this space. The Klue breach is the kind of high-profile event that moves SSPM from "nice to have" to a security audit checkbox.

For security teams, the framing has shifted: the question is no longer whether your own systems are secure. It is whether the vendors that have OAuth access to your systems are secure, and whether you have monitoring in place to know when they are not.

Our Analysis: Why Legacy Credentials Keep Being the Entry Point

The initial access vector in this breach was a compromised legacy credential tied to a service account. That is the same vector that enabled the SolarWinds breach in 2020, the Okta breach in 2022, and dozens of supply chain attacks in between.

Legacy service account credentials accumulate in mature software products. Early-stage products create service accounts to connect systems quickly. Those accounts get elevated permissions to make integration work. As the product matures, the accounts get forgotten, but the permissions remain. They rarely appear in active credential rotation policies. They often predate modern secrets management tooling.

The technical fix exists: secrets rotation pipelines, service account audits, and credential lifecycle management. The organizational challenge is that these tasks do not have natural owners in most engineering teams. Security teams own external perimeter. DevOps owns infrastructure. No one explicitly owns legacy service account hygiene until a breach makes it urgent.

The Klue breach adds another data point to what should now be a clear pattern: if you have not audited your service accounts and their permissions in the last six months, assume there is a legacy credential somewhere that represents a risk.

Key Takeaways

• Icarus, a group active only since April 2026, breached Klue on June 12 via a compromised legacy service account credential — not a zero-day exploit
• The attack harvested OAuth tokens from Klue's Salesforce integration layer, giving Icarus API-authorized access to ten enterprise customers' CRM data without touching any customer network
• Named victims: HackerOne, Snyk, Recorded Future, Jamf, OneTrust, Tanium, Gong, Sprout Social, Insurity, Huntress — all confirmed data exposure
• Salesforce disabled the Klue app integration at the platform level; Klue engaged CrowdStrike and notified law enforcement
• Data stolen was CRM-level: business contacts, deal records, account data — not source code or security infrastructure; the secondary risk is targeted phishing against exposed contacts
• For developers: audit your active OAuth grants in Salesforce, GitHub, Slack, and Google Workspace now — this is your attack surface, not just the vendor's
• Structural lesson: third-party SaaS integrations with CRM access should be audited as regularly as your own infrastructure — the Klue breach is a supply chain attack, not a conventional breach