A Salesforce Misconfiguration Scales to 13.5 Million Accounts
McGraw-Hill publicly confirmed on April 14, 2026 that it “identified unauthorized access to a limited set of data from a webpage hosted by Salesforce on its platform.” The confirmation came only after the extortion group ShinyHunters threatened to publish a claimed 45 million stolen records unless a ransom was paid. ShinyHunters then did publish — and the spillover was independently measurable: Have I Been Pwned reports 13.5 million accounts added to its index from over 100GB of leaked files, per coverage from BleepingComputer and The Register.
The gap between ShinyHunters’ 45M claim and the 13.5M independently verified number is typical of extortion-group reporting — attackers inflate counts, defenders under-count. The important fact is not which figure is correct, but that a single misconfigured Salesforce-hosted page fed millions of records into a public leak.
What the Exposed Data Actually Contains
The Record from Recorded Future News summarizes what McGraw-Hill says is exposed: names, physical addresses, phone numbers, and email addresses. TechRepublic’s breakdown specifies what is not exposed: Social Security numbers, financial account information, and student data from educational platforms. That boundary matters. Breach severity depends heavily on whether the stolen data is regulated personal data (requiring formal notification and fines) or contact data (which enables phishing but triggers fewer legal consequences).
For McGraw-Hill’s business, the pragmatic risk is multi-staged phishing: attackers already know the victim uses McGraw-Hill products, know their contact information, and can craft highly credible invoice fraud, password-reset phishing, or vendor-impersonation emails. “Low sensitivity” data is only low-risk until an adversary combines it with other leaks.
Why the Salesforce Ecosystem Is the New SaaS Crisis
This is not an isolated McGraw-Hill problem. The Record notes the Salesforce misconfiguration “impacted multiple organizations” in recent weeks — ShinyHunters has been systematically scanning for exposed Salesforce pages across their customer base. Rescana’s incident analysis frames this as a structural issue: Salesforce customers routinely deploy Experience Cloud pages, community portals, and public-facing forms without appreciating that they are exposing records from the underlying CRM database.
The classic Salesforce misconfiguration recipe, recurring across breaches over the past three years:
- Overly permissive Guest User profiles that grant unauthenticated access to too many objects.
- “Without sharing” Apex classes exposed to public endpoints.
- Public community pages that inadvertently surface record IDs via API calls.
- No rate limiting or anomaly detection on aggregated reads from public endpoints.
When those conditions combine, a public scanner can enumerate large volumes of CRM data without breaking any authentication system.
Advertisement
Governance Lessons for Enterprises Running Salesforce
Security Magazine’s coverage emphasizes that McGraw-Hill “secured the affected webpages immediately” after detection. That is the right incident response but the wrong governance signal — the misconfiguration existed at all because no pre-publication security review caught it. Four governance items every Salesforce-heavy enterprise should enforce now:
- Mandatory Salesforce security posture review before any community/Experience Cloud page goes live. Use Salesforce’s own tooling (Health Check, Security Center) plus a third-party posture-management tool (AppOmni, Obsidian, Adaptive Shield).
- Quarterly Guest User audit. The Guest User profile should have the absolute minimum object access. Most breaches exploit permissions that should never have existed.
- CSPM-equivalent tooling for SaaS. Cloud Security Posture Management concepts (configuration baselines, drift detection, continuous scanning) now apply to SaaS platforms — not just AWS and Azure.
- DLP on SaaS egress. Microsoft Defender for Cloud Apps, Netskope, or Varonis can detect bulk reads from Salesforce endpoints and alert before full exfiltration completes.
How ShinyHunters Fits the 2026 Extortion Landscape
ShinyHunters has evolved from credential-stuffing opportunist to a systematic extortion operation that treats SaaS misconfigurations as an industrialized attack surface. SC Media’s report frames McGraw-Hill as one in a sequence of Salesforce-related incidents tied to the same campaign. The National CIO Review catalogs the broader ShinyHunters pattern: pick a SaaS platform with systemic misconfiguration issues, scan at scale, extort at the top end.
The strategic implication for CISOs is clear: the next major breach in your environment will likely come not from a sophisticated zero-day but from a SaaS page someone in marketing or product deployed last quarter without involving security review.
What This Means for Enterprise Risk Management
The McGraw-Hill incident will accelerate three shifts already underway. First, SaaS Security Posture Management (SSPM) will move from nice-to-have to baseline enterprise tooling. Second, Salesforce and its competitors will face pressure to ship safer defaults — fewer permissions granted by default to Guest profiles, more aggressive warnings on public page publication. Third, cyber-insurance underwriters will add SaaS configuration attestation to their questionnaires, creating financial incentives for enterprises to document their posture.
ShinyHunters did not hack into McGraw-Hill. A public page did the work for them. That is the 2026 SaaS security problem in one sentence.
Frequently Asked Questions
Why did a Salesforce misconfiguration expose so many records?
The Salesforce platform lets customers publish community and Experience Cloud pages that draw data from the underlying CRM. If those pages grant overly permissive Guest User access, use “without sharing” Apex classes, or expose record IDs via public API calls, an unauthenticated attacker can enumerate large volumes of data without breaking any authentication. That is the pattern ShinyHunters exploited at McGraw-Hill and across other Salesforce customers.
What data did McGraw-Hill actually lose?
According to McGraw-Hill and reporting by The Record and TechRepublic, the exposed data includes names, physical addresses, phone numbers, and email addresses. It does NOT include Social Security numbers, financial account information, or student data from McGraw-Hill’s educational platforms. While that boundary limits formal regulatory impact, the leaked contact data still fuels highly targeted phishing campaigns because attackers know the victims are McGraw-Hill customers.
What is SaaS Security Posture Management (SSPM) and do we need it?
SSPM is a category of tools (AppOmni, Obsidian, Adaptive Shield, Salesforce’s own Security Center) that continuously scan SaaS configurations — permissions, public pages, integrations, OAuth grants — for risky deviations from baseline. It applies Cloud Security Posture Management concepts to SaaS. Any enterprise running Salesforce, Microsoft 365, Google Workspace, or large SaaS estates with community/public features should evaluate SSPM: configuration drift is the dominant breach cause in SaaS, and manual audits miss it.
Sources & Further Reading
- Educational company McGraw Hill says Salesforce misconfiguration led to data leak — The Record from Recorded Future News
- Data breach at edtech giant McGraw Hill affects 13.5 million accounts — BleepingComputer
- McGraw Hill linked to 13.5M-record data leak — The Register
- McGraw-Hill Confirms Data Exposure, Hackers Claim 45M Salesforce Records Leaked — TechRepublic
- McGraw Hill Data Breach Caused by Salesforce Misconfiguration — Security Magazine
- McGraw-Hill Salesforce Data Breach 2026 — Rescana
- McGraw-Hill downplays Salesforce misconfiguration-related breach — SC Media
- 13.5 Million Accounts Affected in Latest ShinyHunters Campaign — The National CIO Review
