In April 2026, attackers exfiltrated 13.5 million records from McGraw Hill through a misconfigured Salesforce-hosted webpage. According to The Register, the Salesforce platform itself was not compromised. The breach is part of a wider ShinyHunters campaign exploiting customer-side configurations and identity workflows in third-party SaaS rather than platform vulnerabilities.
- The architectural lesson centers on SaaS data sovereignty: the more sensitive data sits in third-party platforms, the larger the trust dependency chain that customers cannot fully see or control.
Why It Matters
The McGraw Hill incident illustrates the dominant SaaS breach mode in 2025 and 2026: attacks that exploit no software vulnerability at all. According to Bleeping Computer, ShinyHunters has been mass-scanning Salesforce Experience Cloud sites using a customized version of the open-source AuraInspector tool, originally released by Mandiant in January 2026 to help administrators audit access control misconfigurations. Mandiant publicly confirmed the misuse. The group claims to have compromised between 300 and 400 organizations through this method, with roughly 100 described as high-profile.
A separate ShinyHunters playbook, documented by Obsidian Security, uses voice phishing (vishing) to trick employees into approving malicious OAuth Connected Apps, granting persistent API access to Salesforce data without further authentication. Confirmed victims of this campaign include high-profile enterprises. Both playbooks bypass platform security entirely and look like authorized activity from inside the SaaS environment.
What Happened
McGraw Hill appeared on the ShinyHunters leak site in April 2026, with the group claiming to hold 45 million Salesforce records and demanding a ransom by April 14. After non-payment, over 100 GB of data was published online. Have I Been Pwned verified 13.5 million unique email addresses across the leaked files.
McGraw Hill described the source as a "limited" Salesforce-hosted webpage and stated the activity appears to be part of a broader misconfiguration issue affecting multiple organizations. Salesforce has maintained that the campaign exploits customer-configured guest user settings, not a platform vulnerability, and has issued specific remediation guidance to customers on disabling guest user API access and tightening Experience Cloud sharing settings, according to Help Net Security. McGraw Hill confirmed that core internal systems, primary customer databases, and courseware were not impacted.
Technical Cause
Modern SaaS breaches commonly exploit layers of trust that customers must extend to third-party platforms. Salesforce-linked breaches in 2025 and 2026 have followed this pattern across hundreds of organizations.
Once any of these layers is compromised, bulk data exfiltration looks like normal API activity. According to Obsidian Security, this is precisely why ShinyHunters has prioritized SaaS targets: cloud compromise no longer requires a CVE when identity, consent, and API access are weakly governed.
| Trust layer | Where exposure typically occurs |
|
Customer configuration |
Overly permissive Experience Cloud guest user profiles, public API access, and default permissions exposing more than intended |
| Identity workflows | Voice phishing, helpdesk impersonation, and SSO credential theft bypass platform authentication entirely |
| OAuth and Connected Apps | Malicious or compromised third-party integrations granted persistent API access via user-approved consent |
| Federated SSO | A single compromised identity provides access across all SaaS platforms connected through the same identity provider |
| Data residency and jurisdiction | Customer data physically resides in the platform vendor's environment, under the platform vendor's legal jurisdiction |
Governance and Risk Implications
1. Shared responsibility now means shared exposure
SaaS providers secure their platform. Customers secure their configuration, their identities, their integrations, and the trust they extend to third parties. The most active breach activity now sits on the customer side of this line, where security teams have less visibility and fewer detection tools than they have inside their own networks.
2. Data placed in third-party SaaS inherits jurisdictional dependencies
For governments and regulated operators, sensitive data placed in US-jurisdiction SaaS becomes subject to US legal compulsion frameworks including the CLOUD Act and FISA Section 702, regardless of where the customer is based. The procurement question is no longer just whether the platform is secure, but who can be compelled to disclose data sitting on it.
3. Detection inside third-party SaaS is structurally limited
When attackers use valid credentials, valid OAuth tokens, or legitimate configurations, the platform itself sees authorized activity. Customer-side detection requires telemetry the customer often does not directly own. Closing the gap requires either platform-side instrumentation the vendor controls, or moving sensitive data out of third-party SaaS into infrastructure where the customer owns the full visibility stack.
Secure Architecture Response
For data sensitive enough that misconfiguration would constitute a serious incident, the architectural question is whether that data should sit in third-party SaaS at all. Two Entropya solutions address the layered exposure the McGraw Hill incident illustrates.
Data Vault is a private encrypted storage server operating under organizational control rather than on a third-party platform. Sensitive customer, operational, or regulated data lives in infrastructure the organization owns and administers, outside the configuration models, OAuth integrations, and jurisdictional frameworks of multi-tenant SaaS environments. Data Vault uses NIST FIPS 203-compliant post-quantum cryptography, addressing harvest-now-decrypt-later exposure: data exfiltrated and held until quantum computers mature can be decrypted retrospectively if protected only by current encryption standards.
EEN - Entropya Encrypted Network provides the encrypted access layer for that data. EEN complements or replaces conventional VPN, firewall, and proxy perimeters with an encrypted network carrying no open ports, randomized IP addresses, and zero trust enforced every session. No third-party processors handle data in transit, and the network is infrastructure-agnostic across fiber, cloud, cellular, satellite, and legacy systems.
For organizations and governments requiring sovereign infrastructure, Entropya's Swiss headquarters and no-third-party-processor architecture matter operationally. Switzerland sits outside US and EU compelled-disclosure frameworks, which has made Swiss-domiciled infrastructure a credible sovereignty option for organizations that cannot or will not route sensitive operations through major-power-bloc jurisdictions.
Best Practices
- Inventory which SaaS platforms hold sensitive data, and reassess whether that placement is necessary or default
- Audit OAuth Connected Apps in every SaaS platform: who authorized them, what permissions they hold, and continued need
- Review Experience Cloud and equivalent guest user configurations for overly permissive defaults; disable guest API access where possible
- Implement vishing and identity-workflow training specifically targeting helpdesk and SSO-credential workflows
- For data with multi-decade confidentiality value, ensure post-quantum cryptography is in place before the next breach, not after
Sovereign Data Belongs in Sovereign Infrastructure
Entropya provides encrypted storage and networking under full organizational control, with no third-party processors handling data in transit.
Frequently Asked Questions
Most recent Salesforce-linked breaches do not involve any vulnerability in the platform itself. According to Bleeping Computer, ShinyHunters exploits two main paths: scanning public-facing Experience Cloud sites for misconfigured guest user permissions using a weaponized version of the AuraInspector tool, and voice-phishing employees into authorizing malicious OAuth Connected Apps. Both bypass platform authentication. The platform sees authorized access; the customer often sees nothing until the data appears on a leak site.
The Salesforce Aura campaign refers to ShinyHunters' coordinated and ongoing mass-scanning of public-facing Experience Cloud sites since September 2025, accelerated by their weaponization of Mandiant's AuraInspector tool from January 2026. According to Help Net Security, the group has claimed between 300 and 400 affected organizations. Salesforce's official position is that this is a customer-configuration issue rather than a platform vulnerability, and the company has issued specific remediation guidance for guest user profile permissions.
Data sovereignty in SaaS procurement means knowing where customer data physically resides, who processes it, under which legal jurisdiction it can be compelled to be disclosed, and what trust dependencies the platform's architecture creates. For governments and regulated organizations, sensitive data placed in US-jurisdiction SaaS becomes subject to the US CLOUD Act and FISA Section 702 regardless of customer location. The relevant procurement questions: where is the vendor headquartered, who handles data in transit, and what compelled-disclosure exposure applies.
The first step is data classification: most organizations have a tier of customer or operational data that does not need to live in third-party SaaS at all. For that tier, sovereign storage approaches keep data in infrastructure the customer owns and administers. Entropya's Data Vault is one such approach, providing private encrypted storage with NIST FIPS 203 post-quantum cryptography and no third-party processors. The SaaS environment can then be reserved for non-sensitive workflows, with Entropya's EEN encrypted network providing the sovereign access layer.
Harvest-now-decrypt-later refers to attackers exfiltrating encrypted data today to decrypt it once quantum computers mature enough to break current encryption. Data leaked in 2026 is often assumed to be safe if encrypted, but encryption schemes that hold today may not hold in five to ten years. Data with long-term confidentiality needs (government, Intellectual property, personal records) requires post-quantum protection before breach, not after.