In this article
April 2026 brought new disclosures and claims involving data exposed through Salesforce-related environments, including reports naming McGraw Hill, Medtronic, Amtrak, and Pitney Bowes. The incidents do not establish one continuous operation or a single confirmed victim count: some figures came from threat actors, and public reporting describes different access paths. The durable lesson is narrower and more useful. Connected applications, vendor tokens, and public-site permissions can expose data outside the protections organizations apply to human sign-ins.
Three Waves, One Blind Spot
Public reporting describes several waves of activity across 2025 and 2026. They share an ecosystem and a trust problem, but defenders should preserve the distinctions between campaigns, actors, and access methods.
Round one, in mid-2025, relied on voice phishing. Attackers called employees impersonating IT support and walked them through authorizing what looked like a legitimate “Salesforce Data Loader” connected app. Once approved, that app had persistent API access to enumerate data and hunt for embedded credentials — no password theft required. Confirmed victims included Google, Cisco, Adidas, Workday, Qantas, and LVMH subsidiaries, with ransom demands ranging from 4 to 20 Bitcoin and three-to-four-day deadlines attached.
Round two, in August and September 2025, moved a level up the supply chain. Rather than phishing individual employees, attackers compromised Salesloft's GitHub account and stole OAuth tokens belonging to Drift, a sales-engagement tool integrated into hundreds of corporate Salesforce environments. That single compromise gave attackers a path into 760 downstream Salesforce customer environments within a ten-day window. The victim list is notable for who's on it: Zscaler, Palo Alto Networks, Proofpoint, Cloudflare, and Tenable — cybersecurity companies themselves, breached not through their own defenses but through a CRM sales tool they'd connected.
Round three, running from September 2025 through March 2026, targeted misconfigured guest-user permissions on public-facing Salesforce Experience Cloud sites, using a weaponized version of a security research tool originally built to find exactly this kind of exposure. Attackers used GraphQL pagination techniques to bypass standard 2,000-record query limits, extracting far more data than the guest role was ever meant to expose — and requiring no authentication at all. This wave hit 300 to 400 organizations, including 7-Eleven and Instructure (the company behind the Canvas learning platform).
April’s disclosures add to a continuing stream of reports about SaaS data exposure. For current defenders, the key task is to establish which applications, identities, and permissions can reach their own tenant, then verify that access and monitoring match policy.
Why MFA Never Saw It Coming
MFA remains important, but it does not protect every access path. A user who authorizes a malicious connected app may create a token that can be used through an API. A stolen vendor token may be accepted without a new interactive sign-in. A misconfigured guest permission can expose data without authentication. These paths require controls such as consent restrictions, token governance, least privilege, guest-access review, and API monitoring alongside MFA.
What This Means
Modern SaaS platforms accumulate connected applications, service identities, and vendor integrations with access to business data. Treat these grants as an identity inventory: record the owner, purpose, scopes, expiration, and renewal decision, then remove access that is unused or broader than necessary.
What Penetration Testing Would Catch
- Connected-app and OAuth grant audits. Every third-party application with API access to a CRM or core SaaS platform should be inventoried, scoped, and periodically reviewed — including asking whether it should still exist at all.
- Guest and public-site permission testing. Experience Cloud, Power Pages, and similar portal-guest configurations need to be tested as unauthenticated attack surface in their own right, including whether query or pagination limits can be bypassed to extract more than the intended data set.
- Vendor OAuth risk assessment. Any SaaS vendor holding a persistent OAuth token into your core systems is effectively an extension of your own attack surface. A breach at that vendor becomes your breach the moment its tokens are stolen — Salesloft's GitHub compromise is the clearest possible illustration.
- Vishing-specific social engineering assessments. Consent-granting attacks are a different behavioral target than password-reset scams. Help desks and employees need training and testing specifically against being walked through authorizing a malicious connected app.
- Anomalous API activity monitoring. Since these attacks operate below the MFA and conditional-access layer, unusual query volume or data enumeration through an app's API access is often the only detection signal available.
What This Means for Your Organization
- Treat your connected-app inventory as a living attack surface, not a one-time IT checklist item. Review it on a recurring basis, the same way you'd review privileged user accounts.
- Extend the logic of least privilege to machine and service identities, not just human ones. An OAuth scope granted once during a vendor onboarding call rarely gets revisited — until it's the reason your CRM ends up on a leak site.
- Test guest and public-facing portal permissions as their own category of exposure. These are unauthenticated attack paths that a standard authenticated pentest scope can miss entirely.
- Vet a vendor's own security posture before granting it OAuth access to your systems. Their compromise is functionally identical to yours the moment a token is stolen.
- Train specifically against consent-phishing, not just credential-phishing. A vishing call asking someone to authorize an app is a different attack than one asking for a password, and it needs its own awareness track.
The 2026 Salesforce-related disclosures reinforce a current control gap across SaaS platforms: organizations often scrutinize human logins more closely than connected apps, vendor tokens, and public-site permissions. MFA cannot stop an access path that does not perform a human sign-in, so test those paths directly and review them whenever integrations or permissions change.
Sources and further reading
Salesforce security guidance for connected apps