Salesloft Drift OAuth Token Breach (2025)

Drift is a conversational marketing and chat platform acquired by Salesloft in 2024. Customers use Drift to engage website visitors, capture leads, and route conversations to sales teams. To do its job, Drift integrates deeply with downstream systems: Salesforce for CRM updates, Google Workspace and Microsoft 365 for calendar and email, Slack for team routing, marketing automation platforms, and others. Those integrations are wired up through OAuth.

OAuth, in this context, is the standard mechanism for one SaaS application to be granted scoped, long-lived access into another on a customer's behalf. When a user clicks "Allow", an access token and a refresh token are issued to the requesting application. The refresh token is the durable secret. It is quiet, often valid for months or years, and lets the application keep working without prompting the user again.

That durability is the whole reason OAuth is convenient. It is also the reason a single SaaS vendor compromise can produce a cascading third-party breach across every customer that ever integrated it.

Based on public disclosures from Salesloft, Drift, Salesforce, Mandiant, and Google Threat Intelligence Group, the publicly reported timeline runs roughly as follows.

Early intrusion. A threat actor publicly tracked as UNC6395 gained access to systems associated with the Drift integration, including OAuth refresh tokens that Drift held on behalf of its customers for downstream SaaS platforms.

Token reuse against downstream SaaS. The actor used the stolen refresh tokens to authenticate to customer Salesforce tenants, Google Workspace tenants, and other connected SaaS systems as if they were Drift, with all the scopes the customer had originally granted.

Targeted data theft. Public reporting indicates the actor focused on querying Salesforce objects, downloading support cases and case attachments, and searching mailbox content for secrets, including credentials, API keys, and access tokens for other systems. The attackers were after secondary access, not just CRM records.

Salesloft and Drift disclosure. In August 2025, Salesloft and Drift publicly confirmed unauthorized activity involving Drift's OAuth integrations and began rotating tokens and notifying customers. Salesforce issued guidance to customers using the Drift integration.

Mandiant and GTIG public analysis. Mandiant and Google Threat Intelligence Group published technical analysis of UNC6395 activity, including indicators and observed targeting patterns.

Widening downstream impact. Over the following weeks, named downstream victims acknowledged data exposure through the same OAuth path, with class actions and regulatory scrutiny following. The full downstream footprint will keep being disclosed through 2025 and 2026.

Industry response. Salesforce, Google, and other connected SaaS providers reviewed integration security controls. The broader industry accelerated work on OAuth scope minimization, app governance, and integration monitoring.

In plain English: the attackers stole the keys a chat integration had been given. Those keys let the integration act inside customer CRM, email, and calendar systems on demand. Once the attackers had the keys, the downstream SaaS platforms could not tell the difference between the integration doing its job and the attackers doing theirs.

More technically, the publicly disclosed elements include:

• OAuth refresh token theft at the vendor. The long-lived refresh tokens Drift held on behalf of customers were exposed to the attacker through compromise of Drift-side systems.
• Token reuse from attacker infrastructure. The attacker used the tokens to obtain new access tokens from downstream SaaS providers, authenticating as the legitimate Drift integration. To Salesforce, Google Workspace, and other targets, the traffic looked like Drift.
• Broad scopes magnified the blast radius. Many customers had granted Drift broad read scopes during installation. Once the tokens were in attacker hands, those scopes defined how much could be read or downloaded.
• Secret hunting inside SaaS data. Public reporting describes the attacker searching Salesforce case data and mailbox content for embedded credentials, API keys, cloud access keys, and tokens for other systems. The objective was lateral access through secrets stored inside SaaS, not merely CRM data exfiltration.
• Limited customer-side telemetry. Most customers did not have detailed visibility into per-OAuth-app query patterns. The activity blended into normal integration behaviour from the SaaS audit log perspective.

The technical control failures that mattered most:

• OAuth integrations were treated as install-once, forget-after rather than as continuous privileged third-party access.
• Scopes granted to integrations were rarely revisited or reduced.
• Refresh tokens at the vendor side did not have aggressive rotation or scoped expiration.
• Secrets, API keys, and cloud credentials were routinely embedded inside Salesforce cases and email content, turning SaaS systems into searchable secret stores.
• Detection on integration behaviour, particularly bulk query and export patterns, was thin.

No exploit code is included here. The defensive lesson is more useful than the offensive one.

Salesloft Drift was a textbook example of how integrations quietly become the largest third-party access surface in an organization.

• OAuth integrations were not on the vendor inventory.The team that approved the Salesforce contract often did not know which integrations were authorized inside it. Drift, like many integrations, was installed by a marketing or sales admin, not by procurement or TPRM.
• Scopes were never minimized. Default installation scopes stayed in place for years. No periodic review reduced them as the integration's role narrowed.
• Vendor token custody was not assessed. Few customers asked Drift, in writing, how refresh tokens were stored, rotated, and protected.
• The fourth-party effect was invisible. Many affected organizations never had a contract with Drift; they installed it from a marketplace inside a SaaS platform. The compromised vendor never appeared on the standard third-party list.
• SaaS data became a secret store. TPRM programs rarely audited Salesforce, support cases, or mailbox content for embedded credentials. That gap turned a CRM breach into multi-system lateral movement.
• Detection lived in the wrong place. Most monitoring focused on user logins. The actual attack rode on integration tokens that bypassed user authentication entirely.
• Notification chains were ambiguous. When the vendor that owns the integration is compromised, the chain to the affected end customers is long. Few contracts specified SLAs for that path in detail.

The Drift incident had immediate and structural impact across the SaaS ecosystem.

For Salesloft and Drift. Trust in the integration took a measurable hit. The company executed wide-scale token revocation and customer notification, and was forced to rebuild trust through public technical disclosure and tighter integration controls.

For downstream customers. Specific consequences included:

• Bulk rotation of OAuth tokens, API keys, and any credentials that may have been embedded in Salesforce cases or mailbox content.
• Forensic effort to determine what was actually accessed via the integration tokens, frequently complicated by limited per-app audit logs.
• Disclosure obligations under multiple regimes for affected personal data and customer support content.
• Reassessment of every OAuth integration installed across Salesforce, Google Workspace, Microsoft 365, Slack, and similar platforms.
• Renewed pressure on engineering teams to remove embedded secrets from SaaS data and to enforce secret management discipline.

The Salesloft Drift incident reshaped how the industry thinks about SaaS-to-SaaS access.

• SaaS platforms accelerated work on app governance, including per-app activity views, anomaly detection on integration behaviour, and easier bulk revocation.
• Customers began requiring OAuth scope minimization, integration inventories, and periodic review as standard vendor assessment items.
• Class actions and regulatory inquiries opened against named downstream victims; settlements and additional disclosures are expected to continue.
• The campaign was widely cited in CISA, NCSC, and ENISA guidance on SaaS supply chain risk.
• Engineering practice around secret management inside SaaS data tightened, with new tooling targeted at detecting and removing credentials embedded in support content and email.

Some consequences are confirmed and measurable. Others, such as the long-term shift in how OAuth integrations are governed and the legal precedent on vendor token custody, will keep unfolding well into 2026 and 2027.

1. Treat every OAuth integration as a third-party access relationship, with the same review rigor as any vendor contract.
2. Build and maintain an inventory of all OAuth applications authorized in Salesforce, Google Workspace, Microsoft 365, Slack, and equivalent platforms.
3. Minimize granted scopes. If an integration only needs read access to opportunities, do not grant full Salesforce admin.
4. Periodically review and re-approve integrations. The right cadence is annually for general apps and quarterly for any app with broad scopes.
5. Require vendors providing integrations to disclose, in writing, how they store and rotate refresh tokens.
6. Stop using SaaS data as a secret store. Audit Salesforce cases, ticketing systems, and mailbox content for embedded credentials and remediate aggressively.
7. Monitor per-app activity inside SaaS platforms, particularly bulk query and export patterns from integrations.
8. Pre-build a "kill switch" runbook to revoke OAuth tokens at scale during an integration compromise.
9. Require notification SLAs that explicitly cover integration compromise, not just account compromise.
10. Add OAuth and integration inventory to board reporting as a measurable, named third-party surface.

Most summaries call Salesloft Drift a "Salesforce breach" or a "SaaS breach". Both miss the structural lesson.

The first thing people miss is that the attack rode on integration tokens, not user accounts. MFA, conditional access, and SSO did nothing here because nobody logged in. Refresh tokens issued long ago to a third-party integration were used from new infrastructure and downstream SaaS platforms had no built-in reason to treat that as suspicious.

The second thing people miss is the secondary objective. The attackers were not primarily after CRM contacts. They were looking for credentials and tokens stored inside Salesforce cases, support content, and mailbox text. SaaS systems have become unintentional secret stores. Anyone who has pasted an API key into a support ticket has put their organization on the wrong side of that lesson.

The third thing people miss is that the integration vendor was never in many TPRM inventories. Marketplace installs bypass procurement. The compromised vendor was a fourth-party for most of the affected organizations. The breach travelled through relationships nobody had mapped.

Connected apps and tokens are third-party access paths. They are quieter, longer-lived, and broader than the user accounts your security team watches most carefully. Salesloft Drift was the year SaaS-to-SaaS OAuth stopped being a productivity convenience and started being a vendor risk category in its own right. The integrations you forgot about are the ones that will breach you.