ShinyHunters Hits McGraw-Hill via Salesforce Misconfiguration: 13.5M Records and a Warning Saudi Financial CISOs Must Heed

On April 14, 2026, McGraw-Hill confirmed a data breach affecting 13.5 million accounts — not through a zero-day exploit, not through credential stuffing, and not through a supply-chain attack. The entry point was a misconfigured Salesforce-hosted webpage. The ShinyHunters group found it, extracted over 100GB of records containing names, email addresses, phone numbers, and physical addresses, and then added McGraw-Hill to their dark web leak site alongside Rockstar Games. The lesson for Saudi financial institutions is unambiguous: cloud misconfiguration is no longer a technical hygiene issue — it is an active breach vector being systematically hunted by organized threat actors.

How ShinyHunters Turned a Configuration Error Into 13.5 Million Records

The McGraw-Hill breach illustrates a pattern that has defined ShinyHunters' campaigns since 2020: the group does not break into systems — it finds doors that have been left open. In this case, a Salesforce-powered webpage was inadvertently configured to surface internal data to unauthenticated or low-privilege external sessions. No exploit code was required. The attacker simply queried an API endpoint or browsed a URL that should have required authentication but did not.

McGraw-Hill attempted to minimize the incident by claiming the issue reflected "a broader misconfiguration within Salesforce's environment impacting multiple organizations" rather than a vulnerability in their own configuration choices. Salesforce disputed this characterization. The technical reality is straightforward: Salesforce's Guest User profile, Experience Cloud sites, OmniStudio configurations, and Visualforce pages can all expose data to unauthenticated external parties when sharing rules and object-level permissions are not correctly defined. This is not a Salesforce vulnerability — it is a configuration responsibility that falls entirely on the implementing organization.

Across the 100GB dataset, 13.5 million unique email addresses were found alongside inconsistently populated fields including physical addresses, phone numbers, and names. The data scope suggests the misconfigured endpoint had broad access to Salesforce objects, not merely a single page's records — a hallmark of OWD (Organization-Wide Default) settings that have been left on "Public Read" or "Public Read/Write" for sensitive objects.

Saudi Financial Institutions Are Running the Same Platforms With the Same Risk Profile

Salesforce Financial Services Cloud is deployed across a significant portion of Saudi Arabia's retail banking, wealth management, and insurance sectors. Microsoft Dynamics 365, ServiceNow, and HubSpot are similarly embedded in corporate banking, compliance, and customer operations workflows. Each of these platforms carries the same configuration complexity — and each holds data categories that are orders of magnitude more sensitive than an edtech company's student records: full KYC profiles, transaction histories, credit risk assessments, beneficial ownership records, and financial product portfolios tied to NIC numbers.

A data breach of this nature at a SAMA-regulated institution carries consequences that extend well beyond reputational damage. Under Saudi Arabia's Personal Data Protection Law (PDPL), Article 23 requires mandatory breach notification to the National Data Management Office (NDMO) within 72 hours of discovery. If the misconfiguration has been live for months — as is typical in these cases — the gap between exposure onset and discovery creates significant legal exposure. Additionally, SAMA's Cyber Security Framework requires financial institutions to demonstrate continuous monitoring and control over third-party cloud platforms. A misconfiguration breach that persists undetected is a direct audit finding under the SAMA CSCC's Detect and Respond domains.

Why Salesforce Misconfigurations Are Invisible to Standard Security Programs

The most operationally dangerous aspect of this attack class is that it bypasses nearly every traditional security control in a SAMA-compliant financial institution's stack. A firewall does not block a legitimate Salesforce API call. A WAF does not flag a guest user reading records they should not have access to. A SIEM rule tuned for anomalous login activity will not trigger when an attacker is using an unauthenticated guest profile that is working exactly as configured. Endpoint detection plays no role when the data leaves through Salesforce's own servers.

Standard annual penetration tests almost universally exclude Salesforce configuration review from their scope. Network penetration testing, web application testing, and social engineering assessments are the standard deliverables — but none of these methodologies will find an overly permissive Salesforce sharing rule or an Experience Cloud site that surfaces internal Account and Contact objects to guest sessions. This is a gap that persists in the majority of Saudi financial institutions' security assessment programs and one that regulators have not yet formally mandated in explicit assessment criteria.

The NCA ECC and SAMA CSCC Controls That Apply — and Are Frequently Missed

Both NCA's Essential Cybersecurity Controls (ECC-1:2018) and SAMA's Cyber Security Framework contain direct requirements that apply to Salesforce configuration security. NCA ECC Control 3-1-4 requires organizations to implement a secure configuration baseline for all systems, including cloud services, and to maintain evidence of regular configuration review. SAMA CSCC's "Protect" domain — specifically controls P.2 (Secure Configuration) and P.8 (Third-Party and Cloud Security) — requires financial institutions to define and enforce security baselines for cloud platforms and to conduct periodic compliance audits against those baselines.

In practice, "cloud security baseline" is typically interpreted by compliance teams as applying to IaaS infrastructure (AWS, Azure, GCP) and not to SaaS platforms like Salesforce. This interpretation gap means that the most data-rich cloud environments in a bank's technology stack — the CRM platforms holding every customer interaction and financial profile — are often operating with no formally documented security baseline and no periodic configuration audit. The McGraw-Hill incident makes clear that threat actors understand this gap and are targeting it deliberately.

Four Immediate Actions for Saudi Financial Security Teams

1. Run the Salesforce Health Check and export the results today. Navigate to Setup → Security → Health Check within your Salesforce org. The Health Check scores your configuration against Salesforce's baseline recommendations and flags High Risk, Medium Risk, and Informational findings. Export the report, route it to your security team, and treat any "High Risk" finding as an open vulnerability requiring remediation tracking. If your organization has never run this, the results will be instructive.
2. Audit your Guest User Profile and Experience Cloud site permissions. In Salesforce, identify every active Experience Cloud site (formerly Community Cloud) and every Salesforce Site. For each, review the Guest User Profile assigned to it: what objects does it have Read access to? What sharing rules include the Guest user? Unauthenticated guest access to Salesforce objects is the primary mechanism through which the McGraw-Hill class of exposure occurs. Revoke all Guest User access that is not operationally required for public-facing functionality.
3. Enumerate your Organization-Wide Defaults (OWD) for sensitive objects. Review the OWD setting for your most sensitive Salesforce objects — Accounts, Contacts, Financial Accounts, Cases, and any custom objects holding KYC or transactional data. Any object set to "Public Read" or "Public Read/Write" at the OWD level is accessible to all internal users by default and potentially to guest users depending on your site configuration. Apply the principle of least privilege at the OWD level and layer sharing rules on top for legitimate access requirements.
4. Include Salesforce configuration review in your next SAMA-mandated assessment scope. Brief your security assessment provider that your next engagement must include a Salesforce (or equivalent CRM) configuration review covering OWD settings, sharing rules, profile and permission set audits, Connected App OAuth grants, and API access policies. Document this in your assessment scope and retain the results as evidence for SAMA CSCC audit purposes. If your provider cannot deliver this capability, engage a specialist who can.

Conclusion

The ShinyHunters campaign against McGraw-Hill cost the company 13.5 million records and a public extortion incident — and the root cause was a configuration setting. In Saudi Arabia's financial sector, the same platforms hold KYC records, banking profiles, and personal financial data protected under PDPL and subject to SAMA oversight. The attack surface is not hypothetical. ShinyHunters and groups like them are actively scanning for misconfigured cloud endpoints across every industry vertical, and financial services remains a high-priority target. The question is not whether your Salesforce or Dynamics 365 environment has configuration risk — it almost certainly does. The question is whether your security program is designed to find it before a threat actor does.

Is your organization prepared? Contact Fyntralink for a complimentary SAMA Cyber Maturity Assessment — including a cloud configuration review of your CRM and SaaS platforms against SAMA CSCC and NCA ECC requirements.