In June 2026, a vendor’s GitHub token was used to pull data out of the CRMs of companies that had connected to its integration. The entry point was not the customers’ software. The door was a single vendor token that had already been compromised.
The short version
Klue sells competitive-intelligence software. To do its job, it connects to its customers’ own systems — Salesforce, HubSpot, Gong, Slack, Zoom, SharePoint, Google Drive — through OAuth. Klue’s infrastructure ends up holding a live token for the customers that connect to it.
On June 11, 2026, someone used a previously compromised GitHub personal access token (PAT) to introduce unauthorized code into Klue’s integration service. That unauthorized code collected the OAuth tokens Klue used to connect to third-party platforms. On June 12, Salesforce notified Klue of suspected unauthorized third party activity originating from Klue’s API integration service. Klue disabled the compromised PATs and the affected GKE pods, and rotated the OAuth credentials the same morning.
The stolen tokens had already been used to query customer CRMs directly — the data left through a side door, under a credential that was still valid — and by June 16 extortion emails were reaching some Huntress staff. A separate extortion party later claimed it would publish sample information about nearly 200 companies — a claim Huntress reports as unverified. Companies that published statements of their own include Huntress, Jamf, Tanium and Recorded Future, plus HackerOne and LastPass.
Fix the popular retelling first
The credential type is the whole lesson. Klue’s own CrowdStrike summary is specific: it was a GitHub personal access token, not a generic API key. Huntress’s post-mortem adds a separate detail: the credential it describes was reportedly long-disused but still active, and Huntress does not name its type — originally created to prototype an integration that was later abandoned.
That matters because “rotate your API keys” was never the fix. Rotation issues a new secret; revocation is what retires the old one. That credential was reportedly still live long after the prototype it was built for was abandoned.
Why one token reached so many customers
This is a story about credential concentration. An integration service like Klue’s is, structurally, an imposter with standing access to the customers it serves. Compromise the service once and you inherit all of its identities at once.
Then add the part that made it quiet: against customer CRMs, the attacker read. Bulk reads against a CRM API look a lot like reporting. No dropped tables, no ransom note on boot, nothing that trips the “something broke” alarms most teams actually watch.
Four failures, stacked
- A credential that outlived its project. A PAT carries whatever scopes it was granted, for as long as nobody revokes it.
- Writing to production through a personal token. The PAT was used to introduce unauthorized code into Klue’s integration service. A token that can push code into the service holding your customers’ keys is not a developer convenience — it’s a master key with a friendly name.
- Bearer tokens with no binding. The stolen credentials were used to query customers’ CRM tools directly. Whoever holds the token is the integration.
- Read-only blindness. Salesforce notified Klue of the suspected unauthorized third-party activity on June 12. The reads against customer CRMs were the crime.
| party | the gap | the control that closes it |
|---|---|---|
| Klue (vendor) | previously compromised PAT | block PATs; GitHub Apps with short-lived tokens |
| Klue (vendor) | stolen OAuth tokens usable directly against customer CRMs | sender-constrained tokens; per-tenant isolation; CI egress filtering |
| Klue (vendor) | one PAT could introduce code into the integration service | credential inventory; named owner; tested revocation |
| Customers | the vendor held live OAuth tokens for our CRMs | least-privilege scopes; alert on read spikes; know what vendors hold |
| Ecosystem | the entry credential was a compromised legacy credential | mandatory expiry; secret scanning push protection |
Containment is not done when the door is shut
Disabling the credential that let the attacker in may not reach the credentials they already copied — Huntress notes that revoking the integration may be insufficient for remediation. Huntress advises that customers consider revoking all active sessions across the affected services — because revoking the integration may be insufficient for remediation.
The bit worth internalising
The token isn’t necessarily a PAT — a service account key, an integration API key, a robot user with a password. The pattern is identical: something with a long or infinite lifetime, broad reach, and nobody who can confidently say what it can touch or how to kill it in 60 seconds.
Pure lifetime without reach is survivable — an eternal key to a sandbox is a chore, not a breach. Pure reach without lifetime is survivable too — a token that touches every tenant but expires in ten minutes can’t be harvested and hoarded. The breach lived in the corner where the two meet.
The architectural answer is to refuse the combination: per-tenant credentials that expire in minutes, so no single secret is ever both broadly reachable and long-lived. If a credential has to be one of those two things, it must not be the other.
Five questions I’d ask any team
The useful output of a breach like this isn’t a shopping list of products. It’s a set of questions you can answer in an afternoon — and that most teams discover they can’t.
- Which of our credentials never expire? Every PAT, service account key, integration API key and robot-user password. If the honest answer is “we don’t have a list,” that is the finding.
- What can each one reach? If any single credential can reach more than one customer’s or team’s data, it’s a crown jewel and should be treated like one.
- Who can revoke it, and how fast? Walk the path — and confirm it is revocation, not rotation. A new secret does not retire the old one. If revocation needs a ticket, an owner who is on holiday, or a vendor’s support desk, it isn’t a control.
- Do we alert on reads? Exfiltration is reads. If our alerting covers writes, errors and logins but not reads, then a bulk CRM export wouldn’t page anyone — and neither would this attack.
- If a vendor were breached tomorrow, which tokens do they hold for us? And can we rotate them without breaking a dozen workflows? That inventory is the difference between a bad day and a Klue.
Answer those honestly and you’ve done the post-mortem Klue had to do publicly — before you had to.
Sources
- Klue — An Update on the Recent Klue Security Incident (18 June 2026) and CrowdStrike Investigation Summary and Security Improvements (1 July 2026).
- Huntress — Cybercrime Breaches Klue: Salesforce Data Impacted for Many Victims, including Huntress (June 2026), including the extortion-timeline and IOC detail.
- HackerOne — Security Advisory: HackerOne’s Response to the Klue Breach (last updated 19 June 2026), https://www.hackerone.com/security-updates/klue-2026-06
- LastPass — Klue Supply Chain Incident & LastPass Response (22 June 2026), https://blog.lastpass.com/posts/klue-supply-chain-incident-and-lastpass-response