On 12 June 2026, Klue, a Vancouver-based AI-powered market intelligence platform, discovered unauthorised access to part of its integration infrastructure. The attacker had used a credential from 2022, a leftover from a limited third-party pilot programme that had never been properly retired, to access Klue's internal systems and steal the OAuth tokens that Klue held on behalf of its corporate customers for their Salesforce environments. Those tokens opened the door to customer data at twelve organisations, including LastPass, Recorded Future, Jamf, HackerOne, Huntress, OneTrust, Snyk, Sprout Social, Gong, Tanium, Insurity, and a twelfth that had not publicly confirmed its involvement as of late June 2026. BleepingComputer reports that the Icarus extortion group formally listed Klue as a victim on 19 June, having been active since April 2026 and previously claiming only one other victim. A credential four years old, never cleaned up, was the thread that unravelled data across more than a dozen of the world's most security-conscious software companies.
Klue describes itself as a competitive intelligence platform. It aggregates information about competitors, pricing changes, product launches, win/loss patterns, sales messaging, and surfaces it to revenue teams so they can position more effectively in deals. Its integrations are the core of its value proposition: it pulls data from and pushes it to the CRM and sales infrastructure that revenue teams live in, most prominently Salesforce. To do this, Klue requests OAuth tokens from its customers that allow it to read from and write to their Salesforce environments on their behalf.
OAuth tokens are the backbone of modern SaaS integration. Rather than storing a customer's Salesforce username and password, an integration platform like Klue stores a token that grants specific, scoped access to the customer's Salesforce data. The customer authorises the token during setup, and from that point the integration platform uses it automatically. The security model depends on two things: the customer trusting the integration platform with the token, and the integration platform storing and protecting those tokens securely. The Klue incident is a case study in what happens when the second condition fails.
Klue CEO Jason Smith confirmed publicly that the initial access to Klue's infrastructure used a credential dating back to a 2022 third-party integration pilot. TechCrunch's reporting on Klue's disclosure explains that this credential, associated with a limited pilot that was not in active use, had not been revoked when the pilot ended. It had been sitting in Klue's infrastructure for roughly four years, granting whoever held it access to Klue's integration systems.
This is one of the most common and most consequential credential hygiene failures in enterprise security. When a pilot programme ends, when a vendor relationship terminates, when an employee who held an integration credential leaves the company, the credentials associated with those relationships need to be explicitly revoked. They do not expire automatically. They do not become invalid when the relationship they were created for ends. They remain valid, and usable, until someone deliberately invalidates them. The Klue case is representative of a class of risk that security teams often underestimate: not the credentials in active use, which are monitored and rotated, but the credentials that are simply forgotten, sitting in infrastructure that no one is actively watching.
How the Icarus group obtained the 2022 credential is not fully clear from public reporting. Possible explanations include a previous data breach or credential exposure that surfaced the credential on underground markets without triggering an alarm at the time, an insider source, or a prior intrusion into Klue's systems that went undetected. The fact that a four-year-old credential was still valid and still provided access to production integration infrastructure suggests a gap in Klue's credential lifecycle management that the Icarus group identified and exploited.
The Icarus extortion group is a relatively new actor. Public tracking of the group begins in late April 2026, and the Klue breach is only their second claimed victim. Despite their newness, the Klue attack demonstrates a level of operational sophistication, specifically, the identification and exploitation of a legacy credential to access a high-value SaaS integration platform, that suggests either experienced individuals operating under a new name or rapid capability development from an emerging group. The Hacker News notes that the attack prompted Salesforce itself to disable the Klue app integration within the Salesforce AppExchange ecosystem while the investigation into the token theft was underway.
The Icarus group's approach to the Klue intrusion follows a pattern that has become more common among extortion actors who focus on SaaS and cloud environments rather than on-premise infrastructure: identify a trusted intermediary that holds access to multiple high-value targets, compromise that intermediary, and use the access it legitimately holds to reach the final victims. This is a fundamentally different threat model from traditional ransomware, which requires deploying encryption to every device in a network. Stealing OAuth tokens from a SaaS integration platform is cleaner, quieter, and reaches multiple victims without requiring separate intrusions into each one.
The list of confirmed victims in the Klue breach reads like a who's who of the cybersecurity and security-adjacent software sector: LastPass, Recorded Future, HackerOne, Huntress, Snyk, and OneTrust are all organisations that security professionals interact with directly in the course of their work. Jamf, Tanium, Gong, Sprout Social, and Insurity represent the broader enterprise software customer base that uses Klue for competitive intelligence.
The presence of cybersecurity vendors in the victim list attracted significant attention. Recorded Future is one of the world's most prominent threat intelligence platforms. HackerOne is a bug bounty and vulnerability disclosure platform that manages sensitive security research data. Huntress is an MDR provider whose entire business proposition is protecting organisations from the kind of supply chain attack they just experienced. The irony was not lost on the security community, but it is also genuinely instructive: supply chain attacks succeed because they target trusted relationships rather than defensive controls. An organisation with excellent internal security posture can still be compromised through a vendor relationship that was set up years ago and is maintained with less scrutiny than the organisation's own systems.
LastPass, which attracts heightened scrutiny given its history with serious security incidents including the 2022 breach in which encrypted vault data was stolen, confirmed to TechCrunch that the Klue attackers accessed its Salesforce environment and took customer support case data including customer names, phone numbers, email addresses, physical addresses, and sales-related data. LastPass was emphatic that customer password vaults, products, services, and core infrastructure were not affected.
The distinction matters enormously. Customer vault data, the encrypted collection of passwords that LastPass stores on behalf of its users, would be a catastrophic exposure if stolen, given the access it could provide to every account a user stores in LastPass. The fact that vault data was not in the Salesforce environment that was accessed reflects a deliberate architectural decision to keep vault data separate from the CRM and customer support infrastructure that integrates with third-party platforms like Klue. The data that was taken, support case records, sales data, contact information, is sensitive enough to require notification, but it does not give an attacker access to the passwords of LastPass users.
LastPass's response included disabling employee access to Klue, rotating the exposed API and OAuth tokens, and notifying law enforcement and potentially affected customers. The company said its products and customer vaults remained secure throughout the incident. For LastPass customers who are not involved in enterprise sales or support interactions, the practical risk from this specific incident is limited.
Salesforce's decision to temporarily disable the Klue app integration within its ecosystem is significant beyond the immediate incident response. It reflects a growing recognition that platform providers, the companies whose infrastructure underpins tens of thousands of SaaS integrations, bear a responsibility not just for the security of their own platforms, but for the security posture of the third-party applications that connect to their platforms on behalf of shared customers.
The Klue incident illustrates a specific risk in the Salesforce ecosystem: a third-party application that is authorised to access customer Salesforce data holds OAuth tokens that, if stolen, provide attacker access to that data without any interaction with Salesforce's own security controls. Salesforce's authentication succeeds because the token is valid. The compromise happened upstream, at the integration platform, not at Salesforce itself. For customers whose data was accessed, the experience was indistinguishable from a direct Salesforce breach even though Salesforce itself was not compromised. The hidden danger of credentials held by third-party platforms is rarely visible to the organisations whose data those credentials protect.
The practical takeaway from the Klue incident for every organisation that uses SaaS integration platforms is a question: do you know what OAuth tokens your integration platforms hold, what systems those tokens can access, and how quickly you can revoke them if one of your integration vendors reports a breach? For most organisations, the honest answer is that this information is not actively maintained. OAuth tokens are created at integration setup, forgotten, and often remain valid for years because no one is monitoring their lifecycle.
A first step is building an inventory of every OAuth token your organisation has issued to third-party platforms. Salesforce provides a mechanism to view all connected apps and their tokens in the Setup console. Other platforms offer similar views. This inventory should be reviewed periodically and tokens associated with integrations that are no longer in active use should be revoked. The 2022 Klue pilot credential that enabled this breach would have appeared in such an inventory review if Klue had conducted one.
A second step is implementing monitoring for Salesforce API activity from integration apps. Unusual data access patterns, large volumes of records accessed in a short window, access from unusual IP ranges, access to object types not normally touched by the integration, are indicators that a connected app's token may have been compromised and is being used by an unauthorised party. Salesforce Event Monitoring provides this data, but it requires active use rather than simply being enabled. The intelligence on emerging threat actors like Icarus, who target SaaS integration platforms specifically, is context that helps security teams understand why this monitoring is worth the operational investment. Dark web monitoring of your organisation's data appearing in extortion contexts, as Klue customer data did when Icarus listed Klue as a victim, is a complementary signal that provides warning outside your own infrastructure perimeter.
No. LastPass confirmed explicitly that customer password vaults, products, services, and infrastructure were not affected by the Klue breach. The access via the stolen OAuth token reached LastPass's Salesforce environment, which contains customer support and sales data, not the vault infrastructure where encrypted passwords are stored. If you are a LastPass user whose details appear in a support case or sales record, your contact information and support history may have been accessed, but your vault data was not.
An OAuth token is a credential that grants a specific application permission to access specific data in another platform on a user's or organisation's behalf. When Klue connected to your company's Salesforce environment, your Salesforce administrator authorised Klue by generating an OAuth token that says, in effect, "Klue is allowed to read and write the following data in our Salesforce org." If someone steals that token, they can access your Salesforce data directly without needing your Salesforce username and password. The token is functionally equivalent to a key to a specific part of your infrastructure, and like a physical key, losing it gives whoever holds it the access it was designed to provide.
Klue began notifying affected customers after discovering the breach on 12 June. If your organisation uses or has used Klue and you have not received a notification, you should contact Klue directly to confirm whether your OAuth tokens were among those accessed. Regardless of notification status, reviewing and rotating any OAuth tokens you have issued to Klue, and auditing your Salesforce connected app tokens more broadly, is a prudent step given the incident.
No. Salesforce's platform was not compromised. The attack accessed customer Salesforce data by using valid OAuth tokens that Klue legitimately held on behalf of those customers. From Salesforce's perspective, the requests appeared authentic because the tokens were genuine. Salesforce temporarily disabled the Klue app integration in its AppExchange ecosystem as a protective measure for customers, but Salesforce's own infrastructure was not the attack vector.
Cybersecurity companies compete for business like any other software vendor. Competitive intelligence tools like Klue help revenue teams track competitor product announcements, pricing changes, and messaging so they can position their own offerings more effectively. Security vendors are not exempt from the commercial realities that drive investment in these tools. The fact that Recorded Future, HackerOne, and Huntress were Klue customers illustrates that security expertise at the product level does not automatically translate into security-optimal decisions for every tool in the corporate sales technology stack.
If your organisation uses Klue, revoke the OAuth tokens Klue holds for your Salesforce environment and reauthorise only if and when you trust that Klue's remediation is complete. Audit all connected app tokens in your Salesforce org and revoke any that are associated with integrations no longer in active use. Review your Salesforce Event Monitoring logs for unusual access patterns during the June 12-19 window when the attacker had access via the stolen tokens. Notify your legal and privacy team if any personal data of customers or employees was accessible in the affected Salesforce org, as this may trigger breach notification obligations under GDPR or applicable state privacy laws.
Icarus is an extortion group that became publicly known in late April 2026. Unlike traditional ransomware groups that encrypt files and demand payment for decryption, Icarus appears focused on data theft and extortion, stealing data and threatening to publish or sell it rather than encrypting systems. The Klue attack is only their second publicly claimed victim, which means the group's full capabilities and typical targets are not yet well characterised. The sophistication of the Klue attack, specifically the identification and use of a four-year-old legacy credential, suggests the group includes experienced threat actors even if the group's public identity is new.
The Klue breach is not simply a story about one company's credential hygiene failure. It reflects a structural gap in how organisations think about the security of the integrations that connect their core business systems. Most enterprise security programmes have well-developed controls for the primary perimeter: endpoint protection, network monitoring, identity access management for internal systems, and monitoring of direct access to critical data stores. The integrations, the connections between SaaS platforms that are set up by revenue operations or marketing teams and maintained invisibly in the background, receive far less scrutiny.
Yet these integrations collectively hold enormous access. A Salesforce CRM integration might provide read access to every customer record in a company's database. A Gong integration holds recordings of every sales call. An HR system integration might access employee compensation data. In each case, the integration was authorised by a human who had the appropriate internal permissions, and the OAuth token or API key it uses is held and managed by the integration vendor, not by the company whose data is at stake. When that integration vendor is compromised, as Klue was, the attacker inherits all of the access that was legitimately granted to the vendor across every customer relationship.
The principle of least privilege, applied rigorously to integration tokens, is the right direction: each integration should have access only to the specific data objects and actions it needs for its stated purpose, not to the entire Salesforce org. Regular review and revocation of unused or overly broad integration tokens is the operational discipline that prevents a four-year-old pilot credential from becoming the entry point for a breach that touches a dozen organisations. Understanding the hidden risk in credentials held by third parties is the first step toward managing it systematically.
Incidents like these share a common thread: the attacker is already inside by the time the organisation realises something is wrong. Backdoor.Turn hid in Teams traffic for two months. The Icarus group held Klue's customer data for weeks before the full victim list became clear. In both cases, the early signal existed, credentials circulating on underground markets, infrastructure behaving abnormally, data appearing in places it should not be. Those signals reached the organisations through the news, not through their own monitoring.
Defendis monitors underground markets, leak forums, and dark web infrastructure continuously. When your credentials or data appear where they should not, your team receives an alert with the context needed to act, before the story makes the front page of BleepingComputer.
