The most dangerous credential in your environment is the one nobody remembers creating. That is the lesson buried in the Klue breach, and it is worth sitting with before we get into the mechanics. A market-intelligence vendor that hundreds of enterprises trusted to sync competitive battlecards into their CRM became the entry point for data theft across some of the best-resourced security teams in the industry. The intrusion did not start with a zero-day. It started with housekeeping that never happened.
Here is the shape of what has been reported. In mid-June 2026, Klue disclosed that attackers had compromised its integration infrastructure, obtained OAuth access tokens that customers use to connect Klue to their own SaaS platforms, and used those tokens to pull data out of customer Salesforce and Gong instances. Public reporting points to Salesforce detecting unusual activity tied to the Klue app integration in mid-June, Klue identifying the unauthorized activity shortly after, and customers receiving extortion emails within days. A threat group has reportedly claimed responsibility and is running a data-extortion campaign against victims. As with any incident still being pieced together, treat the specific dates and attribution as provisional.
One credential, a code push, and a token harvest
The initial access vector is the part every security team should internalize. According to Klue's own account, the attacker leveraged a long-disused but still-active credential, one originally created to prototype a third-party integration that was later abandoned. The integration got shelved. The credential did not. It sat in the environment with live access and, evidently, enough privilege to matter.
With that foothold, the attacker pushed a code update into Klue's integration service. That code was built to do one thing: collect the OAuth tokens customers had granted Klue to connect their downstream systems. This is the detail that separates the Klue breach from a garden-variety credential leak. The attacker did not steal one customer's token. They positioned themselves at the point where every customer's tokens flowed through, and harvested them in bulk.
Once you hold a valid OAuth access token, you do not need a password, you do not trigger MFA, and you frequently do not trip the login-anomaly alerts that defenders lean on. The token is the authorization. To the Salesforce or Gong API, automated queries arriving with a legitimate Klue token look exactly like Klue doing its job. By the time defenders noticed, the attacker appears to have been querying connected environments through automated API calls. That is why the window between compromise and data exfiltration was reportedly measured in days, not weeks.
The SaaS-to-SaaS pivot is the whole story
We spend enormous effort hardening the front door: identity providers, MFA, conditional access, endpoint controls. The Klue breach went around all of it by abusing trust that was already established and already approved. This is a software supply chain attack, but not the dependency-poisoning kind we usually write about. There was no malicious npm package. The compromised component was a SaaS vendor sitting inside the integration mesh, and the blast radius was every OAuth grant that vendor held.
Think about what an OAuth grant to a tool like Klue actually authorizes. Read access to Salesforce objects, sales communications, opportunity notes, pricing, contact records. Connectivity to revenue-intelligence platforms like Gong, where the raw substance of deals lives. The scope you approve for a battlecard integration is, in practice, a standing key to your commercial crown jewels. The data reported stolen reflects exactly that: business contacts, sales communications, pricing information, and opportunity notes pulled from customer Salesforce environments.
What makes this a pivot rather than a single breach is the topology. Klue is one node. Each OAuth grant is an edge to a customer's most sensitive SaaS estate. Compromise the node, and you inherit every edge at once. Reporting suggests the affected customers include well-known security and SaaS vendors, which is the uncomfortable punchline: being good at security does not protect you from a third party's forgotten credential.
Why this keeps happening to Salesforce ecosystems
If the pattern feels familiar, it should. Over the past year, OAuth-token abuse against connected Salesforce apps has become a recurring theme, with several campaigns attributed to or compared with groups like ShinyHunters and the activity tracked as UNC6395. Salesforce's own framing of the Klue incident is worth quoting in spirit: the problem did not stem from a platform vulnerability, but from unauthorized access to customer data through the app's connection. That is technically accurate and strategically inadequate as a comfort. The platform was not breached, yet customer data left through a door the customer voluntarily opened.
The structural issue is that OAuth grants in SaaS ecosystems are frequently long-lived, broadly scoped, and poorly inventoried. Tokens rarely expire on a sensible cadence. Scopes are requested generously and approved once, then never reviewed. And the connected-app list in a large Salesforce org is the kind of thing nobody owns until an incident forces the question. Klue moved to revoke affected tokens and disable impacted integrations, and Salesforce disabled the Klue integration on its side, which is the correct containment. But containment after token harvest is cleanup, not prevention.
What defenders should actually do this week
Three concrete actions, in priority order.
First, inventory your connected SaaS apps and the OAuth grants behind them, especially anything touching Salesforce, Gong, and other revenue systems. You cannot govern what you have not enumerated. Treat every third-party OAuth grant as a standing credential into your environment, because that is what it is.
Second, scope down and time-box. Reject the default of broad read access where a narrower scope works, and push vendors and platforms toward shorter token lifetimes and refresh requirements. A token that expires is a token that an attacker cannot reuse indefinitely.
Third, monitor token-authenticated API behavior, not just logins. The Klue attacker never logged in as your users; they queried your data with valid tokens. Anomalous query volume, off-hours bulk reads, and unusual object access through a connected app are the signals that mattered here. Defenders watching only authentication events were always going to miss this.
And the quiet one underneath all three: kill dormant credentials. The entire chain started because a prototype credential outlived the prototype. Credential hygiene is unglamorous, and it is exactly where this began.
How Safeguard Helps
Safeguard treats third-party SaaS connections as part of your software supply chain, because the Klue breach proves they are. Our vendor policy registry and vendor scorecard let you inventory which suppliers hold OAuth grants and how risky each connection is, our TPRM workflows turn that into ongoing review rather than a one-time approval, and policy gates flag broad or dormant grants before they become someone else's entry point. The multi-agent TAOR Deep Think engine and Griffin AI run model-agnostic, so verification and orchestration live above whichever model you bring, cutting false positives so your team chases verified third-party risk instead of noise. If forgotten credentials and over-scoped integrations are a blind spot, reach out.