Notifications
Clear all
Topic starter
15/08/2026 6:07 pm
TL;DR: Attackers stole Klue’s OAuth tokens and used the trusted integration to bulk-extract Salesforce CRM data across multiple enterprise environments, exposing a SaaS supply chain access path that bypassed passwords and MFA, according to Obsidian Security. The incident shows why integration inventory, token revocation, and blast-radius mapping are now core identity controls, not afterthoughts.
NHIMG editorial — based on content published by Obsidian Security covering the Klue SaaS supply chain attack on Salesforce: stolen OAuth tokens and bulk CRM data exfiltration
Questions worth separating out
Q: What breaks when a stolen OAuth token is used against a trusted integration?
A: The trust model breaks because the system still sees a valid credential, even though the actor behind it is no longer trustworthy.
Q: Why do dormant SaaS integrations create so much identity risk?
A: Dormant integrations remain dangerous because they often keep valid secrets or delegated consent after the business process ends.
Q: How do security teams know if OAuth sessions are being abused?
A: Look for repeated token redemptions, unfamiliar geolocation, device changes, and abnormal application access immediately after a successful login.
Practitioner guidance
- Revoke and reissue exposed OAuth grants Identify every Salesforce OAuth grant associated with Klue or similar integrations, revoke the existing token grants, and reauthorize only after confirming scope, owner, and business need.
- Build a full SaaS integration inventory Create a living inventory of every connected application, the scopes it holds, the data it can query, and the business owner responsible for ongoing review.
- Baseline integration source infrastructure Track the normal hosting providers, IP ranges, and query patterns for each integration so deviations from the legitimate vendor footprint are detectable quickly.
What's in the full analysis
Obsidian Security's full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step response sequence for revoking Salesforce OAuth grants across affected tenants
- Exact activity-log indicators used to reconstruct the June 11 to 12 query window
- Detection logic for persistence attempts such as new OAuth apps, admin additions, and webhooks
- Inventory guidance for identifying other SaaS connectors with the same CRM access pattern
👉 Read Obsidian Security’s analysis of the Klue Salesforce OAuth token attack →
Klue OAuth token theft: what SaaS IAM teams need to fix now?
Explore further
15/08/2026 6:16 pm
SaaS integrations are non-human identities, not just app connectors. When an OAuth token authorises a third-party integration, it becomes a durable identity with standing access and broad tenant reach. That means governance must treat integration accounts as lifecycle-managed actors with owners, scopes, and revocation triggers. The practitioner takeaway is simple: if you do not inventory and certify integrations, you do not govern the identity plane they create.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when a third-party integration exfiltrates CRM data?
A: Accountability is shared across the business owner of the integration, the SaaS security team, and the vendor that issued or relied on the token. Governance frameworks should require named ownership, periodic access review, and clear offboarding for every connector that can reach sensitive records.
👉 Read our full editorial: Klue’s OAuth token theft exposes SaaS supply chain access risk
