JH← Back to blog

One Forgotten OAuth Token Exposed Salesforce Data at Four Security Vendors

The Klue breach didn't involve a zero-day. A dormant credential from an old prototype integration let attackers pull Salesforce CRM data from dozens of customers, including Huntress and Tanium.


Huntress, Recorded Future, Jamf, and Tanium — four companies whose entire business is detecting exactly this kind of intrusion — all confirmed their Salesforce environments were accessed through a breach at Klue, a competitive intelligence platform. The root cause wasn't a zero-day or a clever exploit. It was a credential from an old prototype integration that was never decommissioned.

How it actually happened

Klue detected the intrusion on June 12, 2026, and traced initial access to that legacy credential, which the threat group "Icarus" used to reach Klue's Battlecards integration infrastructure — the piece that connects to customers' Salesforce orgs via OAuth. From there, attackers didn't need to touch Salesforce's defenses at all. They used the legitimate OAuth tokens Klue's integration already held, running automated REST API queries that looked like normal integration traffic because they were authenticated with valid tokens. Roughly two dozen customers confirmed impact, with data exposed including business contacts, pricing and subscription details, and sales opportunity notes.

Salesforce disabled the Battlecards integration platform-wide while investigating, which stopped the bleeding but also broke the feature for every legitimate customer using it — the shared-fate problem that comes with any third-party app marketplace.

The part worth sitting with

A credential for a pilot that never shipped often outlives the memory of the person who created it, while remaining fully functional from an attacker's point of view. Most organizations have decent visibility into who has a login to Salesforce and almost none into which third-party apps hold standing OAuth grants and what those grants can actually do. A CRM with a marketplace of integrations can easily have dozens of tokens sitting active, most of them scoped more broadly than the integration needs, none of them reviewed since setup.

What I'd actually check this week

Pull the full list of connected apps in Salesforce — not just the ones your team uses regularly — and revoke anything tied to a project that never went to production. Don't leave dormant tokens active "just in case"; delete them. Where a vendor lets you scope permissions down, do it, because most integrations request more data access than they functionally need. And if your anomaly detection is tuned only to human login behavior, it will miss exactly this kind of exfiltration, because automated integration traffic doesn't look like a login at all.

This kind of breach is preventable with an afternoon of cleanup, which is also why it keeps happening — nobody schedules the afternoon until after the incident.