ShinyHunters breached McGraw-Hill and extracted data on 13.5 million users: unique email addresses, full names, physical addresses, and phone numbers. After extortion demands were not met, they published over 100GB. The attack vector was a Salesforce platform misconfiguration that left customer data accessible without appropriate access controls. No zero-day exploit. No persistent malware. No sophisticated intrusion. Improperly secured data, found and extracted.
This is the third major ShinyHunters claim in the April to May 2026 window that involved Salesforce as a breach vector, with the ADT breach via an Okta and Salesforce integration being another prominent example. A pattern this consistent is not coincidence. ShinyHunters has built operational capability specifically around finding and exploiting Salesforce misconfigurations at scale.
How Salesforce Gets Misconfigured at Scale
Salesforce is one of the most complex enterprise platforms in active use. Its sharing and visibility model involves dozens of interlocking settings: organization-wide defaults (OWDs), sharing rules, profile field-level security, permission sets, guest user access, Apex code sharing declarations, and community or Experience Cloud public access settings. Getting this right requires sustained expertise. Most Salesforce implementations accumulate configuration debt over years of customization by admins, developers, and consultants with varying levels of security awareness.
The specific misconfiguration class most commonly exploited by groups like ShinyHunters involves one of the following:
- Guest user profiles with access to standard or custom objects containing customer PII
- Apex REST endpoints or Visualforce pages with insufficient authentication enforcement
- Experience Cloud (Community) sites where object visibility is not properly restricted from unauthenticated users
- Connected Apps with overly broad OAuth scopes combined with token leakage
- Sharing rules that make records visible across all internal users, combined with a compromised low-privilege account
Misconfiguration breaches do not require vulnerability research, zero-day development, or malware. They require the ability to probe a Salesforce org's sharing model, identify where access controls are missing, and make API calls that the platform permits. This is well within the capability of any organized threat group with Salesforce knowledge.
Why McGraw-Hill Data Is High-Value
McGraw-Hill's user base spans students, educators, institutional partners, and corporate training customers. The exposed data profile, including email addresses, names, physical addresses, and phone numbers, creates specific downstream risk profiles. For the student population: academic fraud targeting young people, FAFSA or student aid phishing, and identity theft against individuals who may have limited credit monitoring in place. For educators and institutional contacts: targeted phishing against educational institutions, which tend to have weaker security controls than enterprise environments. The data is also valuable for credential stuffing given that email and phone combinations enable account takeover attempts across other platforms.
Salesforce Security Review: Where to Start
Salesforce provides native tooling to audit these configurations, but most organizations do not run these checks regularly. The Salesforce Health Check tool provides a baseline scoring of security settings against Salesforce's own recommended baseline. It does not catch all misconfiguration classes, but it surfaces common problems including password policy gaps, guest user access, and session security settings.
Beyond Health Check, organizations should run Salesforce's own Security Review for Experience Cloud and Community sites specifically, since public-facing Salesforce sites with improperly scoped object access are the highest-risk surface. Query the Guest User profile directly to understand exactly what object access it has. Enumerate sharing rules and look for any rule that makes records visible to all internal users across objects that contain PII.
Run Salesforce Health Check and export the results. Audit guest user profile object and field permissions. Review Experience Cloud sites for unauthenticated record access. Check OWD settings for objects containing contact or customer data. These four checks cover the most commonly exploited misconfiguration classes in active ShinyHunters campaigns.
The McGraw-Hill breach requires no novel attacker capability. It requires a Salesforce misconfiguration and an attacker willing to look for it. At the volume ShinyHunters is operating, systematic Salesforce scanning is part of their workflow. Organizations running Salesforce with customer data should treat a misconfiguration audit as a routine security control, not a one-time project.