The Klue breach, how a token forgotten since 2022 hit 200 companies

The article on APIs explained that an API key deserves the same caution as a password. The Klue incident, revealed in June 2026, shows what happens when a key like that stays active for years after it's stopped being useful.

What happened

Between June 11 and 24, 2026, attackers used an old integration credential, an OAuth token issued in 2022 for a limited pilot project and never revoked since, to access the integration infrastructure of Klue, a company specializing in competitive-intelligence software. From that initial access, attackers pushed a malicious code update designed to harvest other OAuth tokens, the ones letting Klue connect to its own customers' platforms, notably Salesforce. With those stolen tokens, the attackers were able to impersonate Klue directly inside the Salesforce environments of nearly 200 client organizations, and extract data from them. Companies affected include several well-known cybersecurity firms, including Huntress, Recorded Future, Tanium, and Jamf.

The OAuth token, an API key people forget to cancel

An OAuth token works exactly like the API key described in the dedicated article: a digital authorization letting one service act on behalf of another, without having to re-share a password on every connection. The core problem in this incident doesn't come from any weakness in the OAuth mechanism itself, but from something far more mundane: this particular token had been created for a limited pilot project in 2022, and nobody had revoked it once that pilot ended. It stayed active and functional for more than four years, a standing access point nobody was actively watching anymore, until an attacker found it and used it.

The cascading attack: one breach becomes 200

The most telling part of this incident is how it spread: none of the 200 affected organizations were attacked directly. The attackers compromised a single vendor, Klue, then relied on the trust already granted between Klue and each of its client platforms to reach every one of those organizations at once, with no need to break through each one's own defenses. This is the very principle of a software supply-chain attack: rather than attacking a well-defended target directly, the attacker goes after a smaller, less-watched intermediary that's connected, with a high level of trust, to dozens or hundreds of organizations at the same time.

The irony: cybersecurity companies themselves affected

The fact that several companies specializing in cybersecurity are among this breach's victims illustrates a point already seen this week on this site (see the article on the Aura hack): no organization, whatever its security expertise, is safe from a breach happening at a third-party vendor it had placed its trust in. A company can perfectly well secure its own systems while remaining exposed by a weaker link elsewhere in its vendor chain, a link it doesn't control and often can't even see.

The twist: hackers hacked by other hackers

This incident took an unusual turn afterward. The cybercriminal group Icarus claimed the initial breach and threatened to publish the stolen data if Klue didn't pay a ransom. A second group then claimed to have itself compromised Icarus and stolen the data that first group had already taken, a rare twist showing that a cybercriminal group isn't itself safe from being hacked in turn, with the result that data already exfiltrated once can end up in the hands of a third actor, completely unpredictable from the start.

What this actually changes

For an organization granting access to a third-party service, even temporary or limited to a simple trial, this incident is a reminder that an integration token or key needs to be actively revoked once its use is over, rather than assumed to expire or be forgotten on its own. Keeping a real inventory of still-active third-party access, not just recently created ones, would have been enough to prevent this exact breach. For an everyday user, it's one more reminder that data entrusted to a service can leak through a technical partner that's completely invisible and never chosen directly, one more reason to limit, where possible, the information shared even with services that seem trustworthy on their own.