Klueless: How A Four-Year-Old Credential Led To A Major Hack

Name: ISMS.online
Address: Nile House, Nile Street, Brighton, East Sussex, BN1 1HW, GB
Telephone: +441273041140
Price range: ££

By Danny Bradbury • 14 July 2026 • 5 min read

Last month, attackers used a stolen credential to hack competitive intelligence SaaS provider Klue. But the seeds of the attack apparently started four years earlier.

Klue executives said that in 2022, the Vancouver-based company issued a credential to an unnamed third party for a limited pilot. An investigation by Crowdstrike later revealed the credential to be a GitHub Personal Access Token (PAT), which enables developers to access software development repositories.

When the pilot ended, the token remained active because no one revoked it. It sat somewhere, invisible to customers who gave Klue access to their innermost secrets. It was a ticking time bomb.

The investigation didn’t determine how Icarus (a new group, active only since April 2026) got the PAT, but on June 11 it used the token to push new code into Klue’s integration service layer.

That layer is where Klue pulls data from its customers’ systems, hosted on services like Salesforce and Gong. It uses this data to perform competitive intelligence analysis for its customers, enabling their salespeople to go into negotiations better prepared.

The code update harvested the OAuth tokens (persistent session tokens for repeated passwordless access) that Klue retained to access its customers’ data on those systems. The attackers then used those tokens to grab data from those customers’ Salesforce and Gong instances.

OAuth Tokens as Legitimacy Laundering

The attack wasn’t easy to spot because the use of stolen OAuth tokens doesn’t look like an intrusion until those tokens are revoked. Icarus fired direct REST calls against Salesforce and Gong instances just as any legitimate customer would.

It was Salesforce that told Klue what had happened on June 12, prompting the competitive intelligence company to rotate its OAuth tokens.

The confirmed victim list included HackerOne, Huntress, Jamf, Recorded Future, Snyk, and LastPass. It reads like a directory of companies whose day job is telling other companies how to manage exactly this risk.

The effect on victims is written all over the web, as they had to post updates on how Klue’s problem had affected them. Salesforce confirmed the incident was “limited to Klue’s app connection and does not arise from a vulnerability within the Salesforce platform” — placing monitoring responsibility squarely on the customer who authorized the integration. It also said “organizations will not be able to connect to Salesforce via this app until further notice”. Gong said the same. And Tanium also blocked Klue.

LastPass disclosed that customer names, email addresses, phone numbers, physical addresses and support case details and sales-related data had been exposed. The company discontinued all employees’ access to Klue.

Huntress carried detailed updates, explaining that Icarus had published a data dump to its dark web site, and had threatened to release more data, citing over 200 victim companies. It identified the data leak site as being hosted in Russia.

None of the downstream victims had a plausible way of seeing what was happening inside Klue’s infrastructure; their vendor-risk programmes had presumably approved the integration and moved on. For many security teams, audits of SaaS companies seem to be a moment-in-time affair. Once the vendor has completed the questionnaire and been approved, it’s considered done.

Why This Makes ISO 27001 More Valuable

ISO 27001’s supplier and access-management controls are designed to protect against the failures Icarus exploited.

Control A.5.16 requires organizations to manage the full lifecycle of every identity from provisioning through deprovisioning, while A.5.18 extends the same discipline to authentication credentials, mandating documented rotation schedules for API keys and tokens.

Applied consistently, either of these would have surfaced a four-year-old PAT long before Icarus did. Klue’s current woes are a textbook illustration of what a failure to apply those principles costs downstream.

But that’s something that Klue could have done internally, not something that its customers can control. What can a company do to protect itself against a supplier’s missteps?

Controls A.5.19 through A.5.23 govern the supplier relationship itself. A.5.22 requires organizations to regularly monitor, review and audit supplier services.

A.5.21 pushes the obligation further, requiring that security requirements flow to sub-processors and that sub-processor usage be recorded in supplier agreements.

An information security management system operationalizes these clauses, converting an annual questionnaire into a live register of integrations, credentials and token grants. It forces the deprovisioning conversation when a pilot ends. It also gives compliance managers an audit trail to prove that both the vendors they rely on, and their sub-processors, get the same continuous oversight as the direct vendors they contract with.

To its credit, Klue has taken several steps to ensure that this won’t happen again, including banning the use of PATs and migrating to different authentication mechanisms. It has enhanced its audit logging and introduced tighter control over its software development pipelines. Better late than never.

An ISMS is how compliance managers make sure that they don’t become the next headline, either as the direct target of a data breach, or as the customer of a compromised victim.