McGraw-Hill Data Breach: Salesforce Misconfiguration

McGraw-Hill Data Breach Tied to Salesforce Misconfiguration

Education publisher McGraw-Hill confirmed a data breach after the extortion group ShinyHunters listed the company as a victim on its dark-web portal. The breach stemmed from a Salesforce misconfiguration, not a direct attack on McGraw-Hill's own infrastructure. ShinyHunters claimed to hold 45 million Salesforce records containing personally identifiable information and threatened to leak the data by April 14 unless a ransom was paid.

McGraw-Hill pushed back on the severity. A company spokesperson told BleepingComputer the exposed data did not include Social Security numbers, financial account details, or student data from its educational platforms. The affected webpages were secured immediately after detection, and the company is working with external cybersecurity experts and Salesforce directly to close the gap.

How the Salesforce Misconfiguration Was Exploited

Salesforce hosts public-facing webpages for many of its enterprise customers. A misconfiguration in Salesforce's environment apparently left certain hosted pages accessible without proper access controls. McGraw-Hill described the incident as "part of a broader issue involving a misconfiguration within Salesforce's environment that has impacted multiple organizations."

This pattern is not new. When SaaS platforms manage hosted content on behalf of clients, the security boundary between the platform provider and the customer gets blurry. If Salesforce's shared hosting layer had improperly scoped access controls or unauthenticated endpoints, attackers could scrape or extract data from multiple tenants using the same technique, scaling a single misconfiguration into dozens of victims. ShinyHunters has already listed 39 organizations on a dedicated Salesforce data leak site.

What Developers and Security Teams Should Know

The McGraw-Hill breach is a concrete example of third-party SaaS risk. Your application security posture is only as strong as the weakest configuration in your SaaS stack. Even if your own code is clean, a misconfigured vendor-hosted page carrying your data is still your problem when it leaks.

McGraw-Hill generates $2.2 billion in annual revenue and operates K-12 and university platforms at scale. If a company with that profile and budget can get caught by a Salesforce hosting misconfiguration, smaller teams with less oversight are clearly at risk too.

ShinyHunters has been on a streak. Confirmed victims in 2026 alone include Rockstar Games, the European Commission, Telus Digital, Wynn Resorts, Canada Goose, Match Group, Panera Bread, CarGurus, and Infinite Campus, another K-12 student data platform breached in March. The group is systematically targeting the same class of misconfiguration across Salesforce-connected organizations.

How to Reduce Your Salesforce Misconfiguration Risk

Audit every public-facing asset your SaaS providers host on your behalf. That includes Experience Cloud sites, Community pages, and any Salesforce-hosted webpages that serve data from your org.

Specific steps worth taking now:

• Review Salesforce Experience Cloud guest user permissions and disable access to objects that should not be publicly readable.
• Run a Guest User security audit in Salesforce Setup and check which fields are exposed without authentication.
• Confirm that Salesforce-hosted pages are covered in your external attack surface monitoring.
• Test your own web applications for exposed endpoints that reference Salesforce data using a scanner like VibeWShield.
• Review vendor contracts to clarify who is responsible for configuring access controls on hosted pages.

Salesforce misconfiguration findings are often overlooked in standard DAST scans because testers focus on the application layer, not the SaaS hosting configuration beneath it. Pairing automated scanning with explicit checks on your Salesforce guest access settings closes that gap.

For a broader look at how SaaS misconfigurations translate into breach vectors, see our guide to third-party attack surface risks.

How did ShinyHunters access McGraw-Hill data through Salesforce? The group exploited a misconfiguration in Salesforce's hosting environment that exposed data on webpages Salesforce managed on behalf of its customers. McGraw-Hill's own Salesforce accounts were not directly compromised.

Does this affect other Salesforce customers? Yes. McGraw-Hill described it as a broader issue affecting multiple Salesforce-connected organizations. ShinyHunters has listed 39 victims on a dedicated Salesforce leak site, suggesting a systematic exploitation campaign.

What should I check if my company uses Salesforce-hosted pages? Audit guest user permissions in Salesforce Experience Cloud, verify which objects are accessible without authentication, and include Salesforce-hosted URLs in your external attack surface scans.

Scan your web application for exposed endpoints and misconfiguration risks at VibeWShield