On June 11, 2026, attackers began a supply chain attack through Klue, a market intelligence platform that sales and competitive intelligence teams connect to their CRM and other business systems.
Because Klue integrates with applications that hold sales and customer data, a single compromise at Klue reached into many downstream environments at once. A group calling itself Icarus gained entry through a dormant credential, then used it to steal the OAuth tokens Klue holds for its customers.
A directory of cybersecurity firms, such as Huntress, LastPass, Gong, OneTrust, and others, appears on the list of victims. Although there is no indication that these vendors were directly impacted, there was a good chance that the attack will damage these businesses. This is a sobering fact that serves as a reminder to all organisations of how one credential has the potential to blow up an entire infrastructure. Let's examine the incident in more detail and see how businesses may strengthen their security posture by putting strong solutions in place.
An extensive investigation of the breach's structure
This is a classic example of a supply chain attack where a dormant credential was compromised, which was then used to harvest an OAuth token for an integration platform ultimately granting the attacker access to a CRM platform. Klue is a market intelligence platform where sales and competitive intelligence teams integrate with their CRM to keep their battlecards updated. This platform works with OAuth tokens that have pre-defined access permissions granted by the respective application that has integrated with.
The group calling itself Icarus carried out an unauthorised attack using a legacy compromised credential in the backend by pushing a code update to harvest the OAuth tokens. With the help of OAuth tokens containing pre-defined access privileges, the attacker gained lateral access to customer environments that were integrated with Klue. The OAuth tokens were the keys connected to victim environment. The attacker got access to Salesforce CRM and bombarded about 1,000 queries in 15 minutes by using automated Python scripts against Salesforce's REST API and exfiltrated a significant amount of customer data before the Klue team even knew there was a breach.
Timeline of the Klue Breach
| Date | Event |
|---|---|
| June 11 | Anomalous activity occurs in Klue's integration infrastructure, indicating the intrusion. |
| June 12 | Klue identifies suspicious external network connections and discovers the compromise. |
| June 13 | Klue revokes OAuth credentials and tokens for all affected customers, disables the impacted integrations, and sends a general customer notice. |
| June 16 | Affected organizations begin receiving extortion emails. |
| June 17–19 | Salesforce disables the Klue integration. Klue publicly discloses the incident, identifies the threat actor, and outlines the mitigation efforts. |
Klue's Response and the Scope of Exposure
Klue promptly began investigation, revoked the compromised credentials, disabled the integrations that got impacted and kept its customers informed. This hack has impacted over two dozen of Klue's clients, including LastPass, HackerOne, Huntress, Jamf, OneTrust, Recorded Future, Snyk, and Tanium in addition to AlertMedia, Blackbaud, Camunda, Cresta, Deel, Lucanet, Link11, and Tines. However, each company attested to the fact that their security architecture and critical passwords had not been compromised, merely customer and sales data.
The Klue Breach Left More Than Clues
The Klue breach is a reminder that it is not the mistake of a single vendor. The majority of businesses make something that is essentially a structural error. Over-privileged credentials can result in vulnerabilities in one way or another. Here is a thorough analysis of the lessons that IT and security teams should take away from this hack.
Dormant credentials are easily the keys to any vulnerability
This lesson is exactly what played out in the Klue breach. The credential the attacker exploited wasn't a random forgotten login — it was one Klue had created specifically to test an integration, then stopped using but never turned off. It was dormant for a long period until an attacker found it, used it to harvest an OAuth token that connected Klue to customer platforms like Salesforce — ultimately reaching CRM data. An inactive credential frequently proves to be an unmonitored credential, and Klue's case shows exactly how simple that makes things for an attacker: no phishing, no exploit, just a door nobody remembered to close. API tokens, OAuth tokens, service credentials, and any unused privileged credentials must be routinely reviewed; credentials that are not utilised for longer than ninety days should be revoked.
A single over-provisioned credential can turn into a mass breach
The attacker didn’t even escalate the privileges to get into the system. The credentials were already over-provisioned to push the code to harvest the OAuth tokens. Granting privileges to credentials and tokens is not considered safe practice as it has a broader access to laterally move across customer environments. Always apply least privilege principle and provide only necessary permissions to carry out the task.
OAuth tokens with pre-defined access control bypass your trusted control.
OAuth tokens had an established set of permissions to access Salesforce CRM bypassing the MFA, session monitoring, and privileged access. A trusted OAuth token doesn't require additional authentication because it has previously undergone pre-authentication. The majority of organisations had no access verification for machine identities that made 1000 API calls in a 15-minute window, whereas they have a greater threshold for human identities. Similar to human identities, this should be tracked and reported right away using behaviour analytics.
Govern Non-Human Identities Just Like Human Identities.
Human identities are onboarded, periodically evaluated, and removed upon offboarding. On the other hand, weak governance lets service accounts pile up and go dormant unnoticed, which creates risks. Non-human identities require the same governance just like human identities such as periodic rotation of credentials, provisioning approval, periodic access review, automatic expiry and more.
How Securden helps Achieve Zero Identity Sprawl
The Klue breach came down to three failures, and each maps to a control Securden is built to enforce. The attacker got in through a credential Klue had created to test an integration and never deactivated. Securden discovers every identity across the environment, human and non-human, and maps each one to an owner, so a credential left over from an abandoned project does not sit active with no one accountable for it. That credential did real damage because it carried far more access than its purpose required, enough to push code and harvest tokens. Securden removes standing privilege and grants access just in time for a specific task, so a single credential does not hold the broad access needed to compromise an entire integration layer. The stolen OAuth tokens were trusted, long-lived, and unmonitored, which let the attacker use them without raising an alarm. Securden enterprise NHI platform governs machine identities the way most teams already govern human ones, with credential rotation, automatic expiry, and access reviews, and flags abnormal activity such as a token suddenly pulling data at scale. Each control answers a specific way the breach unfolded, rather than a generic checklist.
Frequently asked questions for Supply chain attack
What caused the Klue breach?
The Klue breach happened where the dormant credential that Klue had originally created to test a third-party integration and then stopped using but never turned off. It was dormant for a long period until an attacker found it, used it to harvest an OAuth token that connected Klue to customer platforms like Salesforce — ultimately reaching CRM data.
Are non-human identities (service accounts, API keys, OAuth tokens) really as risky as employee accounts?
Yes. Human identities generally undergo onboarding, periodic review, and formal offboarding. The Klue attacker took advantage of the fact that non-human identities are often created for a single project or test and then left unmanaged forever without a comparable lifecycle mechanism.
What is a dormant credential, and why is it dangerous?
Any login, API key, service account, or token that is no longer in use but is still valid is considered a dormant credential. It's risky since it's unmonitored, which allows an attacker to work silently because no one is keeping an eye out for unusual behaviour on a credential that shouldn't be active in the first place.
