If you’ve ever used a McGraw Hill product—student, parent, teacher, or admin—you’re probably wondering one thing: “Was my info in that leak?” Here’s what’s being reported: attackers linked to ShinyHunters got access through a Salesforce misconfiguration and leaked 100GB+ tied to roughly 13.5 million accounts . McGraw Hill’s message is narrow but important: this was unauthorized access to a limited set of data from a Salesforce-hosted webpage, and they say it did not impact core Salesforce accounts, courseware, customer databases, or internal systems . That’s the headline. The real risk now is the follow-up: targeted scams that use your real name, email, phone number, and address to sound believable.
What happened (and what McGraw Hill says wasn’t hit)
This story is getting lumped into the “Salesforce data breach” bucket, but the details matter because they change what you should worry about.
Based on reporting and McGraw Hill’s own statement, the reported path looks like this: a misconfiguration in McGraw Hill’s Salesforce environment was exploited, leading to unauthorized access and then a ShinyHunters extortion-style leak of the stolen data. McGraw Hill told BleepingComputer the activity “appears to be part of a broader issue involving a misconfiguration within Salesforce’s environment that has impacted multiple organizations that work with Salesforce” .
That wording is doing a lot of work. It suggests the problem wasn’t “someone guessed your password and logged in,” and it also wasn’t necessarily a break-in to McGraw Hill’s internal network. It points to a configuration issue tied to Salesforce-hosted infrastructure that exposed data in a way attackers could grab at scale.
The boundary McGraw Hill is drawing (and why you should care)
McGraw Hill’s spokesperson described the exposure as “unauthorized access to a limited set of data from a webpage hosted by Salesforce” .
They also said the incident didn’t affect:
- Salesforce accounts
- Courseware
- Customer databases
- Internal systems
If you’re a student or parent, that “not courseware” piece is a key distinction. It means this isn’t being described as someone breaking into learning content itself (grades, assignments, class materials) through McGraw Hill’s core platforms. If you’re an admin or teacher, it also suggests the blast radius is being framed as a specific web page/data set rather than “everything in McGraw Hill.”
Why this still counts as a real McGraw Hill breach
ShinyHunters reportedly claimed they stole 45 million Salesforce records and threatened to publish them unless paid . And while McGraw Hill hasn’t publicly confirmed the exact number impacted, the leaked material is being tracked as 100GB+ tied to about 13.5 million accounts .
So yes: even with a “limited set of data” explanation, this is still the kind of breach that creates downstream risk. Not because someone can magically access your McGraw Hill coursework, but because real-world contact data in the wrong hands is enough to set up convincing scams.
What data appears in the leak—and why that’s enough to scam you
When a breach involves contact data, the damage isn’t always an “account takeover.” It’s the follow-on messages that hit your inbox, your phone, and sometimes your mailbox.
Here’s what’s being reported about the leaked McGraw Hill dataset.
What data is reportedly in the leak
Have I Been Pwned (HIBP) describes the McGraw Hill incident as data that was publicly distributed in files totaling 100GB+, with 13.5 million unique email addresses across those files 【】.
HIBP also notes additional fields appearing across records (not always consistently), including:
- Name
- Physical address
- Phone number 【】
BleepingComputer similarly reports that the exposed information includes names, physical addresses, phone numbers, and email addresses, and that this can be used to target customers with spear‑phishing 【】.
Why this is enough to scam real people (students, parents, teachers)
Attackers don’t need passwords to cause trouble. They need credibility.
With a real name + email + phone + address, a scammer can write messages that look “verified” because they include details you don’t expect a stranger to know. That’s what makes spear‑phishing different from generic spam: it’s personal.
Common plays after leaks like this:
- “School account verification” emails/texts that ask you to “confirm” info or click a login link
- Parent-targeted billing scams (“your student license is expiring—pay now”)
- Teacher/admin impersonation (“can you review this roster / invoice / portal change?”)
- Support desk lookalikes that reference your address or phone number to push a reset
If you’ve ever received a weird message and thought, “How do they even know I’m connected to this school/program?”—this is how. Contact data turns cold outreach into something that feels specific, urgent, and legitimate.
Your next 60 minutes: a no-nonsense personal response checklist
If scammers have enough detail to sound convincing, your job is to cut off the easy wins: reused passwords, weak recovery settings, and “one click” approval habits.
1) Lock down accounts that matter (15–25 minutes)
- Change your McGraw Hill password (and any related school portal passwords if you reused it).
- Use a long passphrase (12–16+ characters). Random beats clever.
- Hunt for password reuse
- If you ever used that same password on email, banking, Apple/Google/Microsoft, or a parent portal, change those next.
- Turn on MFA anywhere it’s offered
- Prioritize: email, then school/work accounts, then everything else.
- If you can choose: authenticator app is usually safer than SMS.
2) Tighten account recovery (10–15 minutes)
Attackers love “forgot password” flows because they’re quieter than hacking.
- Check your recovery email and recovery phone on your primary inbox account.
- Remove old numbers/emails you don’t control.
- Add a second factor that you control (authenticator/security key) where possible.
- Look for email forwarding rules or “filters” you didn’t set up (a common way to hide alerts).
3) Treat incoming messages like evidence (10 minutes)
For the next few weeks, assume “helpful” messages are tests.
Watch for:
- Account verification or “security update” requests that push urgency
- Links that look right at a glance but aren’t (hover on desktop, long-press on mobile)
- Attachments labeled as rosters, invoices, consent forms, or “student documents”
- Calls/texts asking you to “confirm” details you didn’t offer up
Rule that saves people daily: don’t use the link they gave you. Open the site/app yourself from a bookmark or official portal.
4) Reduce future exposure (10 minutes)
If your real phone number and main inbox keep getting used on school or education-related forms, every future leak and every vendor list has the same problem: it points back to you.
A practical fix is to separate signups from your core contact info:
- Use a dedicated email for education accounts (not the one tied to banking and everything else).
- Consider a masked email/phone for “forms and signups” situations.
If you want an easy way to do that, Cloaked can generate masked emails and phone numbers you can hand out instead of your real ones. If that address/number gets spammed later, you can turn it off or replace it without changing your actual inbox or phone.
Quick “done right” checklist
- Changed password where it was reused
- MFA enabled on primary email + key accounts
- Recovery options cleaned up
- Checked for suspicious forwarding rules/filters
- Committed to “no clicking login links from messages”
- Set up a separate signup path (dedicated or masked contact info)
If you run Salesforce: what to audit right now (so this doesn’t become your headline)
This breach is being tied to a Salesforce misconfiguration . If you own a Salesforce org (especially anything public-facing), assume you have the same class of risk until you prove you don’t.
Hard checks (what’s exposed, who can see it)
1) Inventory anything public-facing
Make a list of every Salesforce-hosted surface that could be hit without a login:
- Experience Cloud sites / portals
- Public pages, forms, “contact us” pages
- Any flow that collects PII and writes it back into Salesforce objects
If you can’t name them, you can’t secure them.
2) Guest/public access: reduce it to the minimum
Misconfigurations often show up here.
- Find any Guest User / unauthenticated access paths.
- Verify exactly what objects/fields those paths can read/write.
- Remove anything that doesn’t need to be public.
- Sanity check “helpful” settings like broad sharing, permissive profiles, or public file access.
3) Least privilege, but for real
If a page or integration only needs to create a lead, it shouldn’t be able to read a directory of users.
- Tighten profiles/permission sets to task-specific access.
- Review sharing rules and “who can view all” type permissions.
- Confirm PII fields aren’t exposed by default through APIs or page components.
Detection + response (catch weird access before it turns into a 100GB export)
Breach reporting around McGraw Hill notes large-scale distribution of data (100GB+) and millions of records . You can’t stop what you don’t notice.
4) Turn up logging and alerting on the stuff attackers actually do
Focus on signals that match data theft patterns:
- Spikes in record reads
- Bulk exports / report downloads / mass queries
- Unusual API usage volumes
- Access from new geographies or odd hours for service accounts
Set alerts that page a human, not a dashboard.
5) Audit third-party access like it’s an exposed password
A lot of orgs forget this part until it’s too late.
- Enumerate connected apps, OAuth tokens, API users, and integrations
- Disable anything unused
- Rotate secrets/keys on anything you keep
- Confirm vendors aren’t storing data in places your team doesn’t monitor
6) Write down the incident steps you’ll follow at 2 a.m.
If you’re hit with an extortion threat, clarity matters. ShinyHunters-style operations are built on pressure and deadlines .
Have a short, executable plan:
- Contain: kill public access paths, disable compromised users/tokens
- Preserve logs: don’t overwrite the evidence you’ll need
- Scope: what objects/fields were accessed, and when
- Communicate: internal owners + legal/compliance + customer comms
- Remediate: fix misconfig, rotate secrets, tighten permissions, add alerts
If your team can run that list without a meeting, you’re already ahead of most orgs.
