June 30, 2026
Posted by Refael Angel
In mid-June 2026, attackers breached Klue, a market intelligence and competitive enablement platform, and used that foothold to walk into dozens of enterprise Salesforce environments. They didn’t gain access through a zero-day or phishing campaign, they entered through a door that was already open. How? A test credential for an integration that was abandoned before launch was still active.
According to Klue, attackers used that compromised legacy credential to obtain OAuth tokens connecting Klue with third-party platforms, including Salesforce. Those tokens let them use Klue’s trusted integration path to reach customer CRM data. The confirmed count of companies affected now numbers over two dozen, including Huntress, Recorded Future, Jamf, Tanium, Gong, Sprout Social, and LastPass.
The broader lesson is clear: every SaaS integration is also a non-human identity. Whether it uses an OAuth token, API key, service account, certificate, or secret, any delegated authority that outlives its purpose becomes standing privilege.
How the Attack Unfolded
The mechanics are worth understanding in some detail, because they reveal exactly where the security model failed.
- The entry point was a credential that should no longer have existed. Klue had created it to prototype a third-party integration. The project was abandoned. The credential was not. Months, possibly years, later, it was still active and valid when attackers found it. Klue has not publicly detailed how that credential was compromised.
- From there, attackers deployed a malicious code update to Klue’s integration infrastructure. The malicious code harvested the OAuth tokens customers used to connect Klue with Salesforce and other SaaS platforms. Their target wasn’t Klue’s own data. It was the delegated access those tokens provided into customer environments.
- With those tokens in hand, they didn’t need passwords, MFA, or any further exploitation. From Salesforce’s point of view, the requests looked exactly like Klue. The tokens were valid. Access was granted. Automated scripts ran bulk API queries against customer CRM environments for roughly 24 hours, exfiltrating contacts, sales communications, pricing data, and opportunity records.
- Salesforce wasn’t the vulnerability, the integration was. Salesforce confirmed no issue in its own platform. The breach surface was the trusted connection between Klue and its customers’ environments, and roughly two dozen organizations inherited the exposure.
That even security-focused companies like Huntress and LastPass were caught this way makes the point clear. In a SaaS supply chain attack, your posture is only as strong as the credentials held by the integrations you trust.
A Familiar Playbook
We saw a similar attack pattern last August, when threat actor UNC6395 exploited OAuth tokens tied to Salesloft’s Drift integration to reach Salesforce environments across more than 700 organizations. It hit companies across every segment of the enterprise technology market, not because their defenses failed, but because a vendor they trusted held persistent, broadly-scoped tokens that worked perfectly for an attacker once stolen.
The Klue attack followed the same structure: compromise a vendor, harvest the OAuth tokens connecting that vendor to customer environments, use those tokens to move laterally through SaaS APIs at scale. It requires finding one weak link in a chain that enterprises have spent years making longer and more interconnected.
What makes this pattern particularly durable is its asymmetry. An attacker who compromises a single mid-market SaaS vendor inherits authenticated access to dozens or hundreds of downstream enterprise environments simultaneously: no firewall to defeat, no MFA to bypass. A valid OAuth token is proof of identity by design; once obtained, it works exactly as intended.
The Klue incident is still evolving. Reports as of publication indicate that Icarus, the extortion group that claimed responsibility, may now be deleting the stolen data, but a second threat actor has surfaced with separate demands. Once data leaves the environment, the organization that owned it loses control of what happens next.
Two Structural Failures: Both Are Non-Human Identity Problems
Credentials that outlive their purpose. This is not a failure of attention. It is a failure of architecture. When credential lifecycle is managed manually, credentials accumulate: test credentials, deprecated service accounts, API keys no one remembers creating. They persist indefinitely. Attackers are patient; they find them.
OAuth tokens with unlimited shelf lives and broad scopes. The tokens connecting Klue to customer Salesforce environments were persistent and permissive; once stolen, they required no further authentication. They worked for 24 hours of automated bulk extraction because that is what they were designed to do. A short-lived, tightly scoped token gives attackers far less time and reach than one that remains valid for months.
Together, these failures define the core non-human identity (NHI) problem. Human identity gets provisioned, governed, and deprovisioned with reasonable rigor. Machine identity is typically provisioned once, scoped broadly, and left to accumulate: the 2026 State of AI Agent Identity Security Report found that 69% of organizations still authenticate machine identities with long-lived API keys.
The problem will only get worse as AI agents become embedded in enterprise workflows, each requiring its own credentials and adding to an already sprawling surface. The same research found that 61% of organizations have already had to revoke or rotate AI agent credentials due to suspected exposure. The Klue breach is just a preview of what happens when that surface goes unmanaged.
What the Fix Looks Like
The fix is architectural: remove the category of risk entirely. For every credential in your environment, ask one question. What happens if an attacker finds this? If the answer is “quite a lot, for quite a long time,” the architecture has a problem.
| Failure in the Klue attack | Capability that removes it |
|---|---|
| Dormant test credential never decommissioned | Dynamic Secrets generate ephemeral, just-in-time credentials with a TTL. Created on demand and auto-revoked at expiry. There is no standing credential to forget, leak, or rediscover. |
| Long-lived OAuth tokens worked long after theft | Zero Standing Privileges (ZSP) mean any stolen credential is already worthless by the time it is replayed. A token that expired 60 seconds ago cannot exfiltrate anything. |
| The integration held the secret | Secretless authentication (SPIFFE, OIDC, Universal Identity) lets workloads and integrations authenticate without ever holding a static secret. An integration that holds no secret has nothing to steal. |
| Sprawling, ungoverned third-party connections | Multi-Vault Governance centralizes visibility, policy, rotation, and audit across every vault, cloud, and integration, so dormant credentials are discovered and deprovisioned, not forgotten. |
This is the model the Akeyless platform is built on: patented Distributed Fragments Cryptography (DFC™) and a Zero-Knowledge architecture in which secrets are never stored whole, and even Akeyless cannot access customer keys. The result is that there is no long-lived secret sitting in a vendor’s integration infrastructure waiting to be harvested, because the credential ceases to exist the moment its purpose ends.
A Checklist for Security Teams Now
Regardless of whether your organization used Klue, the breach is a useful prompt for an audit that most teams are overdue for.
- Inventory every OAuth grant and third-party integration connected to Salesforce, HubSpot, and other high-value SaaS platforms.
- Revoke unused, ownerless, or unclear integrations.
- Identify credentials with no expiration, especially those tied to CRM, financial, or customer data.
- Rotate active vendor-held tokens.
- Reduce OAuth scopes to the smallest workable set.
- Identify legacy credentials tied to pilots, tests, and abandoned projects.
- Add API-layer logging for bulk queries, unusual exports, and suspicious automation.
- Tie credential decommissioning to project and vendor lifecycle processes.
- Move high-risk integrations toward short-lived, policy-bound access.
- Require vendors to explain how they store, rotate, scope, expire, and revoke customer tokens.
Conclusion
The Klue breach is still unfolding, and the root cause is neither complicated nor new: a credential that should not have existed, tokens that should have expired, an integration with standing access that became the attack surface. Once data leaves the environment, it cannot be recalled.
You can’t steal a credential that doesn’t exist. You cannot replay a token that has already expired. . The question is not whether a vendor you trust will be breached, it’s whether your secrets will be the payload when they are.
To see how Akeyless helps eliminate long-lived credentials from your environment, request a demo.
