Trust is a guiding value of Salesforce. The company’s culture and advertising maintain that its customers’ data is secure and is exclusively controlled by their owners. But a persistent string of cyber incidents, all aimed at customer instances, has raised another, sharper one: Is the world’s biggest CRM now at war with an ecosystem that’s eroding trust?
Security firms, national law enforcement, and affected brands describe a campaign that bypasses user awareness training and attacks the weakest seams between identity, connected apps, and machine-to-machine integrations. The FBI posted a warning about account attacks against Salesforce. Mandiant and Google Threat Intelligence have tracked clusters of activity, while researchers at AppOmni and elsewhere have documented the changing playbook.
The Salesforce Ecosystem’s Failure to Prevent Attacks
The path of invasion transited by several waves. First was the theft of credentials through phishing sites that masqueraded as single sign-on pages, then followed by vishing calls directing users toward lookalike domains. When those techniques encountered too much resistance, attackers shifted gears to social-engineer Salesforce users into approving malicious “connected apps,” which gave high-privilege API access in customer orgs. Activity has been tied to groups and unnamed clusters known as ShinyHunters, Scattered Spider, and UNC identifiers maintained by Mandiant.
The list of victims includes financial services, luxury retail, aviation, and technology. A number of the companies specifically identified Salesforce-connected environments as a vector; several more highlighted “third-party” in filings that were later linked by media and researchers to Salesforce interfaces. The modus operandi is a broken record: when a valid session, MFA token, or connected app authorization is compromised, high-value customer data is queried and hoovered at scale, and then extortion becomes the default.
The UberGate fallout and the OAuth token weak link
The most serious twist has been theft and reuse of OAuth tokens—bearer credentials that have the same effect as a password, but do not require a user’s password to use. Mandiant and Google Threat Intelligence said UNC6345 misused OAuth tokens connected to a well-liked third-party app stack that included Salesloft and Drift, to automate data exports across multiple Salesforce organizations. BleepingComputer reported that one hacker group, ShinyHunters, claimed to have stolen more than 1.5 billion records from hundreds of companies.
Security pros contrast the current campaign to previous supply-chain attack attempts against Microsoft 365 customers that saw tokens stolen from a service provider and used across multiple tenants.
The message is clear and it hurts: with SaaS-to-SaaS integrations, one compromised integrator can explode the blast radius across thousands of customer environments in minutes.
Salesforce’s Response And Closing the Shared Responsibility Gap
Salesforce has stressed that its core platform was not compromised and that recent breaches have occurred through phishing, vishing, and misuse of customer connected apps. The company has tightened defaults by reducing the number of entities that can install unapproved connected apps, and it has deprecated some device-based authorization flows for a specific set of utilities. It also recommends that customers enforce IP allow lists and review data export permissions.
Those measures can help, but they don’t immediately invalidate stolen OAuth tokens. Salesforce cut Salesloft off, then reconnected it partially as a reaction to the Drift engagement; that behavior protects the platform in the short term but delegates operational support to customers and partners. Some of Okta’s leadership has publicly advocated for the stance that IP allow listing may be imperfect for cloud-native, transient infrastructure, yet it still serves as a practical guard when vendors push stable egress ranges. Drift lists IPs like this in their official documentation, and Salesloft only serves to reinforce that multi-networking constraints are possible when planned accordingly.
The bigger picture is a well-known SaaS gray area. Salesforce offers the controls; customers and integrators have to implement them correctly, and fast. And when attacks spread across hundreds of orgs, all through one provider’s tokens, that shared-responsibility model can start to look misaligned with the scale and tempo of modern intrusion sets.
What would rebuild confidence in Salesforce’s ecosystem
Experts point to a number of technical shifts that would meaningfully mitigate the impact of token theft. First, constrain tokens by default. Some options would be IP pinning the OAuth tokens to whitelisted egress ranges — if a token comes from an out-of-planned network, the request should fail closed. Salesforce already has IP restrictions in place for user access — adding and enabling this by default for machine-to-machine traffic could also reduce replay risk.
Second, token binding at scale. Similarly, protocols like OAuth 2.0 DPoP (Demonstrating Proof of Possession) and Mutual TLS bind access tokens to the client’s key material, ensuring that stolen access tokens cannot be used at other entities. According to Okta, these controls are already working now in popular identity systems. Financial-Grade API (FAPI) profiles bring more security to high-value integrations through harder grant types and client restrictions.
Third, raise the ecosystem bar. Marketplace apps should be forced to publish and keep up to date their egress IPs via an API — as well as quick token rotation, scoping/updating of least-privilege on a schedule, security attestations (e.g., ISO/PCI/SOX/etc.), and anomaly detection to throttle abnormal data export patterns by default. If a partner can’t meet those requirements due to the fact that nine months is too long of a footprint, then customers should see an obvious risk label in place before they install.
The bottom line on trust, tokens, and Salesforce’s future
And Salesforce is far from alone in dealing with identity-based and integration-layer attacks, but it’s positioned at the nexus of tremendous flows of customer information. When attackers weaponize connected apps and bearer tokens, this is no longer tenant-specific damage, but rather a platform trust problem.
That trust in this case will be rebuilt by defaults, not advisories. And if Salesforce moves token binding, network pinning, and standards for an enforceable ecosystem into warp speed in the light of day, turned on by default, the platform can turn a tough season into a playbook for antifragile SaaS. If not, disclosures will continue to outpace defenses and a company built on trust will be known for the things it can’t see.
