Klue OAuth token compromise shows third-party access risk in Salesforce

At a glance

What this is: Commvault describes how compromised Klue OAuth tokens enabled access to downstream Salesforce tenants, showing how third-party integrations can become a direct access path into core business systems.

Why it matters: IAM, PAM, NHI, and cloud security teams need to treat connected applications as governed identities with lifecycle, scope, and revocation controls, not as passive integrations.

Context

OAuth-based integrations extend trust across organisations, which means a compromise in one connected application can become an access problem in many downstream environments. In this case, the security issue is not Salesforce itself but the delegated trust path created by a third-party app and the tokens that authorized it.

For IAM and NHI practitioners, the important governance point is that third-party access behaves like a machine identity with scope, lifetime, and revocation requirements. The incident is a typical example of what happens when integration trust is broader than the business need and is not continuously reviewed.

Key questions

Q: What breaks when an OAuth-connected app is compromised in Salesforce?

A: When a Salesforce-connected app is compromised, the token becomes a trusted identity that can query data, export records, and search for embedded secrets without bypassing MFA. The failure is not the login flow, but the assumption that approved integrations are low-risk. Teams should treat each token as a governed NHI with explicit scope, ownership, and revocation controls.

Q: Why do third-party app tokens create more risk than direct user logins?

A: Because tokens can persist beyond the immediate user session and are often reused by automation, refresh workflows, or multiple tenants. A stolen token can therefore create repeated access opportunities without another prompt for authentication. The risk grows when scope is broad and oversight over connected apps is weak.

Q: How can teams tell whether access governance is actually working?

A: Look for short revocation times, low rates of stale entitlements, and repeatable access review outcomes across systems. If accounts remain active after role changes or offboarding, governance is not effective. Good measurement focuses on whether access is removed when it stops being justified.

Q: Should teams treat SaaS-to-SaaS integrations as privileged access?

A: Yes. A connected app can function like a privileged service identity if it can read, write, or export business data through APIs. Treating it as ordinary application plumbing leaves no clear place for certification, offboarding, or incident revocation, which is exactly where shared blast radius emerges.

Technical breakdown

Why OAuth tokens create cross-tenant trust chains

OAuth authorizes an application to act on a user or system's behalf without sharing the underlying password. In practice, that token becomes a bearer credential: whoever holds it can use the granted scope until expiry or revocation. When a SaaS integration is connected to many customer tenants, a compromise of the upstream app can turn a single token theft into many downstream access events. The security risk is not merely authentication failure, but delegated trust that outlives the security of the source application.

Practical implication: Treat OAuth tokens as governed credentials with explicit scope, short lifetime where possible, and fast revocation paths.

How third-party integrations become non-human identity risk

A connected app often functions like a non-human identity because it authenticates, is authorised, and accesses business data without a person present. That makes it subject to the same governance questions as service accounts, API keys, and workload identities: who owns it, what can it reach, how is it monitored, and when is it removed. If those answers are missing, the integration becomes an unmanaged trust extension rather than a controlled access relationship. The attack surface is the relationship, not just the software package.

Practical implication: Inventory connected apps with the same discipline used for NHI ownership, scope review, and offboarding.

Why containment depends on token revocation and integration offboarding

Once a token is suspected compromised, containment is about closing the trust path, not waiting to see whether the attacker uses it again. That means disabling the integration, revoking the associated authorisation, and validating whether the application had any broader delegated access than intended. This is especially important in SaaS-to-SaaS chains because each connection may inherit permissions, refresh tokens, or API access that are easy to overlook. Without rapid offboarding, the compromise persists as long as the token remains valid or refreshable.

Practical implication: Build revocation playbooks for third-party access before an incident occurs and test them regularly.

Threat narrative

Attacker objective: The objective was to exploit trusted third-party access to obtain business data from downstream Salesforce environments at scale.

1. Entry occurred through compromised OAuth tokens tied to Klue, which had been authorised to sync data into Salesforce environments.
2. The attacker used the trusted delegation path created by those tokens to reach downstream Salesforce tenants rather than attacking each tenant directly.
3. Impact was limited to business relationship and sales information in the affected Salesforce environment, while customer backup data, product data, product metadata, operational logs, and Commvault services were not indicated as affected.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• 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.

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

Third-party OAuth access is now a machine identity governance problem: The compromise of an integration token is operationally closer to NHI abuse than to a simple SaaS breach. The credential is delegated authority, not just a login session, so the real question is who owns the integration, what scope it carries, and how quickly it can be revoked. Practitioners should manage connected apps as identities with lifecycle controls, not as static vendor dependencies.

Delegated trust creates a shared blast radius that most organisations still under-model: A single compromised upstream app can expose many downstream tenants without any one victim having a direct control failure at the perimeter. That means internal segmentation alone cannot contain the risk if authorisation was already granted upstream. Security programmes need to measure how much privilege is inherited through third-party connections and whether that inheritance is justified.

Integration offboarding is the control gap this incident exposes: The failure mode is not lack of authentication, but persistence of authorised access after the trust relationship has become unsafe. If applications and tokens remain active until business teams remember them, exposure windows stay open far longer than most identity teams assume. Practitioner implication: build offboarding as a first-class access control process for external integrations.

Salesforce-connected apps should be governed like privileged pathways, not ordinary SaaS add-ons: Once an external app can move data into a core CRM, it deserves the same scrutiny as a privileged administrator path because it can touch sensitive business context at scale. This is where IAM, PAM, and NHI governance overlap. Teams should set explicit owner, purpose, scope, and revocation standards for every connected application.

Transparency after compromise matters because third-party risk is cumulative: Incidents like this are not only about one vendor or one tenant. They show how trust extends through an ecosystem, and why disclosure, scope validation, and continuous review are necessary to stop one integration from becoming a repeated source of exposure. Practitioners should use each incident to tighten connected-app governance across the estate.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: OAuth 2.0 and OpenID Connect Guide for Identity Teams

What this signals

Third-party access now behaves like an extended identity perimeter: Organisations cannot assume that security ends where their own infrastructure ends, because delegated OAuth trust can carry access into downstream systems they do not directly control. That changes the governance unit from the application to the integration relationship.

Integration trust gaps are becoming a measurable NHI problem: When external apps authenticate into core platforms, they inherit the same lifecycle risks as service accounts and API credentials. Teams should inventory those integrations, define ownership, and make revocation a standard control, not an emergency exception.

OAuth token compromise is a reminder that supply chain exposure often starts with authorisation, not malware: The attack path depends on trust already granted across organisations. The most effective programme response is to narrow inherited access, shorten token lifetimes where feasible, and remove unused integrations before they become incident paths.

For practitioners

• Audit every Salesforce-connected OAuth integration Identify each connected app, document its business owner, and verify the exact data and API scope it can access. Remove any integration with unclear purpose, excessive privilege, or no current business justification.
• Revoke and re-authorise risky third-party tokens Create a revocation process that can disable tokens immediately when a connected service is compromised, retired, or no longer trusted. Re-authorisation should require a fresh business review rather than automatic renewal.
• Treat connected apps as governed NHIs Assign lifecycle ownership, access review cadence, and offboarding criteria to every external application that authenticates into core systems. Do not leave token supervision to the vendor that issued it.
• Test third-party incident response before exposure occurs Run tabletop scenarios that assume an upstream SaaS integration is compromised and confirm who disables the integration, who validates scope, and who signs off on restored trust.

Key takeaways

• The incident shows that a compromised third-party OAuth token can become a downstream access path into core business systems even when the target platform itself is not breached.
• The impact described by Commvault was limited to business relationship and sales information, which underscores how quickly delegated access can expose sensitive context without touching production systems.
• The control gap is integration governance: ownership, scope review, and fast revocation for connected applications need to operate like identity controls, not procurement afterthoughts.

Key terms

• OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
• Third-Party Integration Risk: Third-party integration risk is the chance that external services, APIs, or partner accounts create an unintended route into internal systems. These connections often bypass traditional perimeter assumptions, so they need the same identity, segmentation, and review discipline as internal access.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Vendor offboarding: Vendor offboarding is the controlled removal of a third party's access, data paths, and operational dependencies when the relationship ends or changes. It is a lifecycle control, not an administrative closeout, because any surviving credentials or integrations remain active security exposure.

Deepen your knowledge

NHI Foundation Level course covers NHI governance, machine identity security, and secrets management in practical terms, including how to govern third-party access paths. It is designed for practitioners who need to turn identity risk into operating controls across modern environments.