Klue OAuth abuse shows how stale integrations expand SaaS blast radius

At a glance

What this is: This is Obsidian Security’s analysis of how a compromised Klue-Salesforce integration enabled large-scale CRM exfiltration through stale OAuth access, excessive privilege and anomalous integration behaviour.

Why it matters: It matters because SaaS-to-SaaS integrations are now part of the identity perimeter, and IAM teams need inventory, scope control and behavioural monitoring for third-party OAuth access.

By the numbers:

• One impacted organization lost approximately 13.9 million records in the Klue-linked exfiltration campaign.

Context

OAuth integrations are designed to keep access flowing without repeated sign-in, which means their risk lives in standing consent, token scope and the trust placed in third-party software. In this case, Obsidian Security describes a compromised Klue-Salesforce integration that was used to move from authenticated access to bulk CRM extraction.

For IAM and SaaS security teams, the governance gap is not simply whether an integration exists. The harder problem is whether the organisation can prove who authorised it, what privileges it retains, how long those privileges have existed and whether its runtime behaviour still matches the approved baseline.

Key questions

Q: What breaks when Salesforce integrations keep standing OAuth access?

A: Standing OAuth access turns a third-party integration into a persistent trust bridge. If that app is compromised, stolen, or over-permissioned, attackers can reuse delegated access to read, sync, or export sensitive records without stealing a user password. The failure is usually lifecycle control, not authentication alone, because the grant stays active long after the business need has changed.

Q: Why do stale third-party OAuth grants increase SaaS breach impact?

A: Because the grant already carries trust, the attacker inherits legitimate access, normal authentication and often broad API reach. That combination makes it easy to move from a compromised connector into high-value SaaS data with less friction than direct intrusion.

Q: What are the signs that an internal OAuth application is being abused?

A: Common warning signs include newly added credentials on an internal app, generic or suspicious app names such as oAuth or app, unusual mail-related scopes, and running locations that do not match normal organizational patterns. Security teams should also watch for compromised user accounts, inbox rule manipulation, and activity that suggests the app is being used to evade detection.

Q: When should teams revoke a third-party SaaS integration?

A: Revoke it when the app no longer has a clear business owner, when its permissions exceed the use case, when it was added outside approved governance, or when its behaviour changes in ways you cannot explain. If you cannot justify the access continuously, the safest answer is to remove it.

Technical breakdown

How stale OAuth grants become a durable exfiltration path

OAuth tokens let applications act on behalf of a user or service without repeated re-authentication, which is operationally convenient but governance-heavy. When a token is long-lived, over-scoped or retained after the original use case has faded, it becomes a standing access path into SaaS data. In the Klue case, the issue was not just token presence, but the combination of persistent consent, privileged scope and weak oversight of integration activity. That mix allows an attacker to blend into normal application traffic until the access is used for reconnaissance and bulk export.

Practical implication: Treat third-party OAuth grants as governed access objects, not one-time setup artifacts.

Why integration baselines matter for Salesforce detection

A healthy integration usually has a stable pattern: fixed infrastructure, predictable user agents, consistent API versions and narrow data access. Obsidian’s analysis highlights how deviations in source IP, user agent and Salesforce API version made the malicious activity stand out. Those signals matter because they distinguish routine application use from an abused integration that has shifted from business function to data theft. In practice, the security value comes from knowing the expected behavioural envelope before an incident forces you to infer it.

Practical implication: Build behavioural baselines for each OAuth app so unusual infrastructure or query patterns are visible early.

Schema discovery and QueryMore are export mechanics, not normal integration noise

The attack chain used Salesforce schema discovery followed by SOQL queries and QueryMore pagination to harvest complete result sets in batches. Schema discovery tells an attacker what objects exist and how they are structured, while QueryMore is a legitimate API mechanism that can be abused for high-volume extraction. At scale, tens to thousands of fetches indicate automation rather than human-led triage. That is why these patterns matter: they show that a trusted integration can be turned into a structured export pipeline without needing to exploit Salesforce itself.

Practical implication: Flag schema enumeration and high-volume pagination as suspicious when they come from non-developer integrations.

Threat narrative

Attacker objective: The objective was to abuse trusted SaaS integration access to steal large volumes of Salesforce CRM data from multiple victim organisations.

1. Entry occurred through a compromised legacy credential tied to a third-party integration, giving the attacker authenticated access into the Klue-Salesforce connection.
2. Credentialed access was then used to query Salesforce schema objects and discover available data structures, which prepared the environment for extraction.
3. The actor issued SOQL queries and QueryMore requests to paginate through records, turning trusted integration access into bulk exfiltration across multiple victims.
4. Impact was large-scale CRM theft, including one organization whose records were extracted over an extended period and across changing source infrastructure.

Breaches seen in the wild

• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
• Trivy supply chain attack 2026: A PAT stolen via a Trivy workflow and a botched rotation let TeamPCP poison Trivy releases and Action tags to steal CI/CD secrets.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Stale OAuth consent is a governance asset with an expiry problem: once third-party access outlives the business use case, it becomes a latent attack path rather than an integration convenience. Obsidian’s analysis shows that the compromise was not purely about token theft, but about a privileged grant that remained usable long enough to matter. Practitioners should treat consent age, scope drift and owner drift as first-class risk indicators.

Integration behaviour has become the new identity control plane for SaaS: traditional account-centric monitoring misses attacks that live inside approved application traffic. The Klue case shows why source IP, user agent, API version and query shape now carry governance value. If those attributes are not baselined and reviewed, the organisation cannot distinguish business automation from hostile automation.

Blast radius is determined before exfiltration begins: the combination of stale tokens, privileged scopes and weak segregation across SaaS apps defines how far an attacker can move once access is abused. The incident reinforces that least privilege for OAuth apps is not a design preference but the determinant of downstream loss. Security teams should think in terms of constrained integration authority, not just authentication success.

Vendor-managed integrations still sit inside the customer’s control boundary: outsourcing the software does not outsource the access decision. That means third-party SaaS links need the same lifecycle discipline as any other non-human identity, including ownership, review, revocation and anomaly detection. The practical conclusion is simple: if the organisation cannot govern the integration, it cannot safely trust the data path.

Third-party SaaS access is now an identity supply chain problem: the article shows how compromise of one trusted connector can fan out across many customer tenants. This is exactly where NHI governance, SaaS inventory and access telemetry converge. The lesson for practitioners is to treat every OAuth app as a supply-chain dependency, not a low-risk convenience layer.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Identity supply chain control is now part of SaaS governance: the Klue case shows that third-party integrations can carry the same blast-radius risk as compromised internal accounts. Security teams need to govern OAuth apps as durable access relationships, not disposable app connections.

Behavioural baselines are the practical control gap: once an integration can authenticate, the organisation still needs to know what normal looks like for source IP, user agent, API version and query shape. Without that baseline, suspicious access blends into ordinary SaaS traffic until records are already moving out.

Blast radius control is the decisive variable: the difference between a contained anomaly and a major incident is often the scope of the integration at the point of compromise. Tight scopes, rapid revocation and strong ownership reduce how far a trusted connector can carry an attacker.

For practitioners

• Inventory every Salesforce OAuth app Map each connected app to its owner, authoriser, scopes, last-use date and business purpose so stale grants can be identified before they become dormant access paths.
• Review and reduce OAuth scopes Remove unnecessary read, write and admin capabilities from third-party integrations, especially where the app can change code, query broad objects or persist access without re-consent.
• Baseline integration behaviour Track normal source IP ranges, user agents, API versions and query patterns for each trusted integration so deviations can be detected as soon as they appear.
• Revoke stale tokens on owner or purpose change When a vendor relationship changes, a connector is no longer used or the business owner cannot be identified, remove the token and force reauthorisation only through a reviewed process.
• Monitor schema queries and bulk pagination Treat Salesforce Global Describe calls, unusual schema enumeration and high-volume QueryMore activity as suspicious when they come from integrations that should not need broad discovery or export behaviour.

Key takeaways

• A compromised SaaS integration can turn approved OAuth access into a high-volume exfiltration path without exploiting the underlying platform.
• The attack’s scale and duration show that stale tokens and broad scopes create a larger blast radius than most teams assume.
• Governance has to cover ownership, consent age, privilege scope and behavioural monitoring, not just initial application approval.

Key terms

• Stale OAuth Authorization: A stale OAuth authorization is a consent grant that still works even though the business need, user, or vendor relationship has ended. These grants are dangerous because they preserve delegated access outside normal account lifecycle processes and often remain invisible until audited or abused.
• Configuration Baseline: The approved reference state for a system, policy, or controlled asset. A baseline defines what the environment should look like after a legitimate change. Security teams use it to compare current state against intended state and to spot drift, tampering, or incomplete implementation.
• Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.