Salesforce OAuth token theft shows the cost of over-scoped integrations

At a glance

What this is: A supply-chain style Salesforce intrusion used stolen OAuth tokens from a third-party integration to drain business data, mine secrets, and widen access into connected systems.

Why it matters: IAM teams need to treat OAuth scopes, third-party consent, and token lifetime as governance controls across NHI, autonomous, and human-linked workflows, because trusted integrations can become silent high-privilege pathways.

By the numbers:

• An estimated 700 companies were affected, including Cloudflare, Zscaler, and Palo Alto Networks.
• Attackers attempt access within an average of 17 minutes when AWS credentials are exposed publicly, and as quickly as 9 minutes in some cases.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase.

👉 Read SlashID's analysis of the Salesforce OAuth token theft campaign

Context

OAuth for SaaS integrations is supposed to reduce friction while preserving delegated access, but that model breaks when third-party apps are granted broad, long-lived scopes that outlast the original trust decision. In this case, Salesforce became the target surface because it often holds the most operationally useful business records and the secrets people paste into those records.

For identity programmes, the core issue is not just stolen credentials. It is delegated access without enough lifecycle control, scope restriction, and post-consent monitoring. Once an integration can query records, harvest embedded secrets, and pivot into adjacent services, the identity problem becomes a blast-radius problem across NHI governance and SaaS access governance.

The starting point here is typical, not exceptional: many enterprises rely on the same app-consent and token patterns that made this campaign viable. The scale of the breach comes from how normal those trust relationships have become.

Key questions

Q: What breaks when third-party OAuth integrations are over-scoped?

A: Over-scoped integrations turn delegated access into an attacker-controlled session with too much reach. The failure is not only data exposure, but also the ability to query records, harvest secrets, and pivot into adjacent systems without triggering interactive-login defenses. Teams should treat app consent as a privileged access decision and review it as tightly as they review admin access.

Q: Why do SaaS-to-SaaS compromises create such a large blast radius?

A: Because a single trusted integration often connects multiple business systems, one stolen token can inherit access across several services. That means compromise in one app can become data theft in another, then pivot into collaboration or cloud platforms. The risk grows with every downstream connector that shares trust but lacks separate lifecycle governance.

Q: How do security teams know when OAuth access is operating outside its intended boundary?

A: Watch for bulk object enumeration, unusual query shapes, repeated exports, and token use from cloud infrastructure or Tor exit nodes that do not match normal integration behaviour. The key signal is not a failed login, but a trusted token doing more than the integration’s documented purpose requires.

Q: Who is accountable when a third-party integration is used to steal business data?

A: Accountability is shared, but the enterprise still owns the trust decision. Security, IAM, and application owners must review consent scopes, token lifetimes, and vendor offboarding because delegated access is part of the company’s identity perimeter. If a platform can retain access after the relationship changes, the governance failure remains internal.

Technical breakdown

How stolen OAuth tokens become a trusted session

OAuth tokens let an application act on behalf of a user or service without re-authenticating for each request. When attackers obtain those tokens, they inherit the application’s delegated privileges, not a new login event, which is why many authentication controls never fire. In this campaign, the issue was not password theft or MFA bypass. It was abuse of a valid delegated session with enough scope to query Salesforce objects and move laterally into adjacent integrations. The token itself became the bearer of trust, and the trust survived the compromise.

Practical implication: review OAuth consent as privileged access, not convenience, and restrict scopes before the token exists.

Why Salesforce becomes a secret graveyard

Salesforce often holds structured business data, but it also accumulates unstructured secrets in case notes, support threads, and ad hoc operational fields. Attackers can query that data at scale, search for credential formats, and extract AWS keys, Snowflake tokens, and VPN references that were never meant to be durable secrets. This is not a vulnerability in Salesforce alone. It is a data placement problem combined with permissive query access and weak secret hygiene across the business workflow.

Practical implication: classify Salesforce fields and records for secret exposure, then block high-risk data from being stored there at all.

How integration pivoting widens the blast radius

Once a trusted integration is compromised, downstream systems often inherit its trust assumptions. Drift Email access into Google Workspace shows how one OAuth relationship can open a second, narrower but still consequential access path without ever touching the primary perimeter. Attackers also used Tor and cloud-hosted infrastructure to obscure source patterns, which makes reputation-based detection far less reliable. The architecture lesson is simple: when integrations chain together, the blast radius is defined by the weakest consent boundary in the chain.

Practical implication: map every third-party integration chain and disable any downstream scope that is not explicitly required.

Threat narrative

Attacker objective: The objective was to turn a single compromised SaaS integration into broad access to customer data, reusable secrets, and follow-on cloud footholds across multiple victim organisations.

1. Entry occurred when attackers compromised the trusted third-party integration environment and stole Drift OAuth tokens, giving them valid delegated access into downstream tenant systems.
2. Credential access followed through authenticated Salesforce sessions, where the attackers enumerated objects, ran bulk SOQL queries, and harvested embedded secrets such as AWS keys and Snowflake tokens.
3. Escalation and impact came from using those secrets to widen access into adjacent cloud and collaboration services, including scoped Google Workspace accounts, while deleting query jobs to slow detection.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing OAuth trust was designed for stable delegation, not silent post-compromise reuse. This campaign worked because the integration’s delegated access remained valid after the trust boundary changed. The practical lesson is that consent, not authentication alone, is the durable control plane for SaaS-to-SaaS identity risk.

Over-scoped SaaS integrations create identity blast radius faster than perimeter controls can absorb. Once an app can query core objects and adjacent records, the attacker’s objective shifts from login bypass to data harvesting and secret recovery. That makes scope review, token lifetime, and app offboarding part of core identity governance, not optional hygiene.

Secret sprawl inside business systems is now a governance failure mode, not just a developer mistake. Salesforce case notes, support records, and exports can function as hidden credential stores when operational teams paste sensitive material into workflow tools. The implication is that NHI control boundaries must extend into SaaS content, not stop at source code or vaults.

Third-party consent chains are becoming the dominant weak point in NHI governance. The campaign shows how a single downstream integration can inherit trust from multiple systems and expand into a broader estate without any one system looking abnormal in isolation. Practitioners need to assess the chain, not the app.

Identity security is shifting from account compromise to delegated abuse detection. Traditional alerting is built to spot failed logins, MFA prompts, and unusual interactive sessions. This breach bypassed those assumptions by using valid tokens, which means teams must re-centre detection on token issuance, scope drift, and bulk API behaviour.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase, according to the Guide to the Secret Sprawl Challenge.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• For the breach pattern in this post, the control response should align with the 52 NHI Breaches Analysis, which shows how exposed credentials and trusted access chains repeatedly drive downstream compromise.

What this signals

Secret sprawl will keep turning SaaS records into attacker infrastructure. When business systems store API keys, tokens, and operational passwords, the identity programme inherits a data-placement problem that conventional IAM cannot see on its own. Teams should expect more incidents where the first compromise is an application token and the second is a secret harvested from a workflow record.

The practical shift is toward consent-chain governance. If a third-party app can reach Salesforce, then Salesforce data can expose cloud credentials, and those credentials can in turn expose more systems. That is a lifecycle and blast-radius problem, not just a vendor risk problem.

Delegated access must now be reviewed as continuously as human privileged access. Once integrations can move laterally through collaboration and cloud tooling, the security boundary is the scope grant itself. IAM programmes that do not model downstream connectors will miss the real attack surface.

For practitioners

• Re-scope every third-party OAuth grant Inventory SaaS integrations, identify over-broad delegated permissions, and remove any scope that is not required for the integration’s exact job. Prioritise apps that can read core business objects, export records, or access adjacent collaboration tools.
• Treat tokens as privileged credentials Set shorter token lifetimes, rotate refresh tokens, and alert on token reuse from unfamiliar infrastructure. Tokens should be governed with the same care as service account credentials, including ownership, expiry, and revocation triggers.
• Block secrets from business systems Prevent AWS keys, Snowflake tokens, passwords, and VPN URLs from being stored in Salesforce records, case notes, or exports. Apply content inspection and DLP rules where business workflows routinely carry sensitive text.
• Monitor bulk API behaviour and query shape Alert on high-volume object enumeration, broad SELECT patterns, unusual user agents, and query bursts tied to third-party integrations. Reconstruct behaviour from logs even when attackers delete jobs or other visible artefacts.
• Offboard integrations as lifecycle events When a vendor relationship changes, revoke OAuth grants, disable unused app links, and verify that downstream connectors cannot retain access through another path. Use lifecycle review to close the trust chain completely.

Key takeaways

• This breach shows that valid OAuth tokens can function as stealth privileged access, bypassing the normal signals teams rely on for interactive account compromise.
• The scale matters because large SaaS platforms often contain both business records and hidden credentials, creating a compound theft opportunity from one trusted path.
• The limiting control is not just rotation, but strict consent scope, integration offboarding, and detection of bulk API abuse across connected systems.

Key terms

• OAuth Delegated Access: OAuth delegated access lets an application act on behalf of a user or service within a defined scope. In NHI governance, that scope is the real control boundary, because a valid token can outlive the original trust decision and continue to operate until revoked or expired.
• Consent Chain: A consent chain is the sequence of app approvals, token grants, and downstream connectors that allows one service to reach another. The chain matters because compromise at any link can inherit all upstream trust, turning a narrow integration into a wide blast-radius problem.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials, tokens, and keys across systems that were never meant to store them. It becomes dangerous when business platforms, tickets, chats, and exports accumulate reusable secrets that attackers can mine after gaining legitimate access.
• Delegated Abuse Detection: Delegated abuse detection focuses on spotting valid tokens being used in ways that do not match the intended integration behaviour. For non-human identities, the signal is not failed authentication but excessive querying, odd user agents, unusual infrastructure, and scope drift across linked systems.

Deepen your knowledge

OAuth trust relationships and SaaS integration governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls around delegated access and token lifecycle, it is worth exploring.

This post draws on content published by SlashID: LLMjacking and OAuth token theft in Salesforce-connected environments. Read the original.