Key Takeaways
- The attacker never touched McGraw Hill’s systems. ShinyHunters didn’t breach McGraw Hill directly but they exploited a misconfiguration in Salesforce, a platform McGraw Hill relied on to serve its users. The vendor’s environment became the entry point.
- It was extortion, not ransomware. ShinyHunters set a ransom deadline of April 14, 2026. McGraw Hill didn’t pay. Over 100 GB of data went public, including names, email addresses, phone numbers, and physical addresses across 13.5 million accounts.
- This was a campaign, not a targeted attack. The same automated scanner swept hundreds of organizations. Rockstar Games appeared on the same leak site. McGraw Hill was one of many caught in the same net.
- The root cause was visibility, not a zero-day. A guest user permission left open in a Salesforce Experience Cloud portal made this possible — and Salesforce itself confirmed its platform was not compromised. The configuration gap was entirely on the customer side. Proactively auditing account permissions and access settings would have caught it before any attacker did.
- Stolen contact data fuels the next attack. Names, addresses, and emails at this scale become infrastructure for spear-phishing, vishing, and credential stuffing, each attack more convincing because it’s built on real information.
13.5 Million Records. No Hack Required. One Misconfigured SaaS Portal.
In April 2026, education giant McGraw Hill lost data on 13.5 million users. No sophisticated exploit. No zero-day. No intrusion into McGraw Hill’s own systems. Just a door left open inside a third-party SaaS platform and an attacker with a script fast enough to find it before anyone on the inside did.
This is what a modern SaaS supply chain attack looks like.
What Happened
McGraw Hill is one of the largest education publishers in the world, with $2.2 billion in annual revenue and platforms used by millions of students and educators.
ShinyHunters, a prolific extortion group, breached the company’s Salesforce environment and exfiltrated data on 13.5 million user accounts. They didn’t attack McGraw Hill’s core systems. Instead, they exploited the gap between a SaaS platform’s configuration and the customer’s actual responsibility for it.
This isn’t a theoretical risk. Salesforce’s own shared responsibility model explicitly states that while Salesforce secures the infrastructure, customers are responsible for their configuration choices, access controls, and data governance on top of it. That boundary exists in writing. The problem is that most organizations never audit whether their configuration actually honors it.
Their tool was a modified version of AuraInspector — software that Mandiant originally built to help companies find misconfigurations in Salesforce. ShinyHunters turned it into an automated scanner and used it to sweep the internet for exposed Salesforce Experience Cloud portals across hundreds of organizations. No malware. No credential theft. No command-and-control infrastructure. Just a configuration gap and a script.
Why This Is a Supply Chain Problem
Traditional supply chain attacks compromise software before it reaches you — think SolarWinds or XZ Utils. This attack worked differently, but the logic is the same: the attacker didn’t go after the target directly. They went after a dependency the target trusted.
When McGraw Hill adopted Salesforce, they inherited its entire configuration surface. Every permission setting, every guest user profile, every API endpoint became part of their attack surface — even though it lives on someone else’s infrastructure. Salesforce secures its servers. McGraw Hill was responsible for every configuration choice made on top of them. That gap — between what the vendor secures and what the customer configures — is the SaaS supply chain attack surface.
McGraw Hill confirmed that this “appears to be part of a broader issue involving a misconfiguration within Salesforce’s environment that has impacted multiple organizations.” The attack method was replicable. The targets were many. And no single organization had visibility into the shared risk they were carrying.
What Data Was Exposed and What Attackers Do With It
Have I Been Pwned confirmed that the breach exposed names, phone numbers, email addresses, and some physical addresses. McGraw Hill maintains that Social Security numbers, financial data, and student records were not included.
That sounds limited. It isn’t. Contact data at this scale becomes infrastructure for the next wave of attacks.
- Spear-phishing becomes far more convincing when the email uses your real name, real employer, and real address.
- Credential stuffing takes email addresses from this breach and matches them against passwords leaked in older breaches, any account where someone reused a password is immediately at risk.
- Vishing campaigns use real personal data to impersonate institutions at industrial scale. And data layering means this dataset gets combined with other breached records to build richer profiles over time, making every subsequent attack harder to detect.
The breach is the starting point, not the end.
What to Do Right Now
Audit guest user permissions in Salesforce Experience Cloud
Check what your guest profile can access without authentication. If it can read records without a login, that is an open door.
Audit your SaaS accounts and access configurations (not just at onboarding but continuously)
Major SaaS vendors like Salesforce already publish shared responsibility frameworks. The gap isn’t awareness of the model; it’s the lack of systematic auditing of what’s actually provisioned. Connect your SaaS platforms via their APIs to review which accounts exist, what permissions are active, and which access grants have drifted from their intended state. A guest profile with read access to live records isn’t a theoretical risk, it’s a gap waiting to be scanned.
Map the access and permission footprint of your SaaS stack
Most SaaS vendors don’t expose internal asset visibility and that’s the point. What you can audit is what’s provisioned: which users have access, which roles are assigned, which public-facing portals are active, and which third-party integrations are authorized. Start with the access layer, because that’s where attackers start too.
Move from point-in-time audits to continuous monitoring
Configurations drift. Integrations get added. Developers make quick fixes. A yearly review cannot catch what changes daily.
Implement structured case management for findings
Before you can manage findings, confirm that your SaaS platforms support the integrations that make management possible.
- Does the platform expose APIs for configuration auditing?
- Does it support automated log ingestion into your SIEM?
- Can access controls be governed through your identity provider, for example, via SAML integration with Okta or Entra ID?
Organizations that do this groundwork at onboarding (the way mature security teams already do) create the foundation for structured remediation workflows. Every finding that surfaces through that pipeline then needs an owner, a deadline, and a close date. Without the integration layer in place, case management has nothing reliable to work from.
How Secure.com Detects and Manages This Automatically
The AuraInspector-based scanner ShinyHunters used runs in seconds. A yearly audit or a manual review cycle cannot compete with that speed. The only adequate response is continuous monitoring that operates at the same cadence as the threat.
Secure.com is built specifically for this problem.
- Pentest Teammate for SaaS exposure assessment: Most SaaS platforms don’t provide the level of internal access needed for traditional misconfiguration scanning and that’s a deliberate architecture choice, not a gap. What Secure.com’s Pentest Teammate does instead is assess your SaaS environment from the outside in, the same way an attacker would. It probes your public-facing portals, exposed APIs, and authentication boundaries across your SaaS stack to surface what’s accessible without credentials and what access paths exist. A setting drifted open at 2am gets flagged based on what it exposes externally before it becomes Monday’s incident report.
- Attack path identification goes beyond flagging that a door is open. Secure.com maps where that door leads: which records are accessible, how far an attacker could move through the environment, and what the business impact would be. This turns a list of findings into a prioritized understanding of actual risk.
- Structured case management tied to your access layer: When Secure.com’s Account & Access Management module connects to your SaaS platforms via their APIs, every access anomaly, over-provisioned account, or drifted permission becomes a tracked case — with context, severity, and an assigned owner. Remediation workflows move findings through closure, and where your SaaS platform supports it (SAML federation, SCIM provisioning, API-driven deprovisioning), remediations can be executed directly rather than through a spreadsheet someone has to remember to check. The workflow is only as automated as the integrations your platform supports — which is exactly why those integration decisions matter at onboarding.
- SaaS attack surface mapping gives you visibility into every SaaS tool, integration, and public-facing portal your team uses, including shadow IT and unmanaged permissions that aren’t on anyone’s radar yet.
The McGraw Hill breach was preventable, not with a patch, but with persistent visibility into configuration state and a workflow that moves findings to closure automatically.
FAQs
Was Salesforce itself breached?
No. Salesforce confirmed there is no indication that its platform was compromised and said the activity is not related to any known vulnerability in its technology. The issue was in how McGraw Hill’s Salesforce environment was configured — a customer-side responsibility under the shared responsibility model.
How does this qualify as a supply chain attack?
The attacker’s entry point was not McGraw Hill’s own systems — it was a third-party SaaS platform McGraw Hill depended on. The trust relationship between McGraw Hill and Salesforce became the attack vector. That is the defining characteristic of a supply chain attack: exploiting a dependency, not the target directly.
Could this happen to my organization?
Yes, if you use Salesforce Experience Cloud or similar public-facing SaaS portals without continuous configuration monitoring. The scanner ShinyHunters used was automated and swept hundreds of organizations. McGraw Hill wasn’t uniquely targeted — it was one of many caught by the same scan.
How does Secure.com’s approach differ from a periodic security audit?
A periodic audit gives you a snapshot of a moment that has already passed. Configurations change constantly. Secure.com monitors continuously, identifies attack paths from every misconfiguration it finds, and manages remediation through structured case tracking — so every finding has an owner, a deadline, and a close date rather than a row in a spreadsheet nobody revisits.
