Your Customers Gave Your App an OAuth Token. Attackers Want It More Than Your Database.

Quick Answer: Between August 2025 and June 2026, attackers used stolen OAuth tokens from three SaaS vendors, Salesloft Drift, Gainsight and Klue, to reach Salesforce data at hundreds of companies without exploiting Salesforce itself. If your product holds OAuth tokens to customer systems, you are that kind of vendor, and a penetration test should cover how those tokens are stored, scoped and revoked.

On 11 June 2026, someone logged into Klue, a competitive-intelligence SaaS vendor, with a credential that had been sitting unused for four years. Klue had created it to prototype an integration it later abandoned, and nobody deactivated it.

With that access, the attackers pushed a code update capable of harvesting customer OAuth tokens, then ran automated scripts against the Salesforce REST API for roughly 24 hours before Klue detected the intrusion on 12 June. The breach reached OAuth tokens for 195 Klue customer organisations, exposing Salesforce data at cybersecurity vendors Huntress and Recorded Future, among others.

Klue was not the first. It was the third.

In each breach, attackers compromised a SaaS vendor that already held trusted OAuth access to many customers, then used that access to pull customer Salesforce data. The Cloud Security Alliance research note from July 2026 links all three incidents to actors operating under the ShinyHunters brand, while noting that attribution across the campaign is still contested.

We mentioned the Drift incident briefly when we wrote about why identity is now the perimeter. That piece was about the customer side: how to govern the logins and tokens your own company hands out. This one is about the other side of the same token, the vendor who holds it.

Because nobody logged in.

According to the CSA analysis, standard Salesforce authentication and sign-in monitoring did not flag any of the three incidents. The malicious queries arrived through connected-app sessions that were already authorised, not through new logins. To the customer's security tooling, the attacker looked exactly like the vendor's legitimate integration doing its normal job.

That is the property attackers are exploiting. Once a connected application is authorised, it typically keeps its access indefinitely, independent of the person who approved it. A stolen OAuth or refresh token lets an attacker query an API at a volume and schedule that would trip alerts through a browser login, but that looks routine through an approved integration. In the Klue case the harvesting ran for about a day. In the Salesloft case the exfiltration window stretched across more than a week.

The CSA notes that Microsoft and Salesforce have only recently started closing this gap with connected-app risk scoring and OAuth scope visibility. Until those controls are everywhere, the strongest protection sits with the vendor holding the token.

Because one SaaS vendor holds the keys to hundreds of customers at once, so one break-in multiplies into hundreds of victims.

In the CSA's reading, the campaign looks like a deliberate pivot. In mid-2025 the same actors were voice-phishing employees one company at a time into authorising a fake Salesforce Data Loader app. Then they switched to compromising vendors that already held legitimate OAuth grants across hundreds of customers simultaneously.

The same research points to how common the underlying weakness is. In CSA's 2025 to 2026 State of SaaS Security survey of 420 security professionals, 58% of organisations said they struggle to enforce least-privilege access across their SaaS integrations, and 46% said they lack adequate visibility into non-human identities such as OAuth-connected applications.

Look at the root causes again: a forgotten test credential, a code repository that led into a cloud account, tokens reused from an earlier breach. None of them is a flaw in OAuth itself. Each is a flaw in how a vendor stored, scoped or retired access it had been trusted with.

If you sell a SaaS product that connects to customers' CRM, email, ticketing or collaboration tools, expect questions like these in your next security review. They follow from the weaknesses the CSA describes:

The CSA's strategic recommendation is to treat third-party OAuth grants with the same rigour as privileged human accounts: a defined owner, a documented business justification, a scheduled re-certification date and automatic revocation when an integration is retired. That guidance is public, and your customers' security teams can apply it to you.

A penetration test of your integrations should follow the token: where it is stored, who can reach it, what it is allowed to do and how fast it can be revoked. A standard web application test checks your login, your user roles and your API. That is necessary, and it is not enough for a product whose most valuable asset is a vault of other companies' tokens.

One honest limit. A penetration test will not find every forgotten credential your team created years ago, because some of them are only visible from the inside. That part is an access review: list every integration credential, give it an owner and kill the ones nobody claims. Do both. The test shows what an attacker can reach today, and the review removes what nobody remembers.

The three vendors in the CSA note were trusted enough to be wired into the Salesforce environments of security companies such as Cloudflare, Palo Alto Networks, Huntress and Recorded Future. The breaches did not come through their customers' front doors. They came through a test credential, a code repository and tokens nobody was watching.

If your product sits between your customers and their systems, your security posture is now part of theirs. The right time to find out what an attacker could do with your token store is before your largest customer's security team asks.