On April 7, 2026, ShinyHunters posted McGraw-Hill to its dark web extortion site. On April 14, with the ransom deadline expired, the group published more than 100 gigabytes of data containing records on 13.5 million McGraw-Hill users. The same group, on the same deadline, published 78.6 million records from Rockstar Games after the game publisher refused to pay. Two companies, one threat actor, two attack chains — and one regulatory dimension that the gaming industry coverage largely missed.

McGraw-Hill is not a consumer technology company. It is one of the largest educational publishers in the world, providing curriculum materials, learning management platforms, and digital content to K-12 schools and higher education institutions across the United States. The data it holds is not primarily commercial customer data. It is, in significant part, educational records — data about students, their academic performance, their platform usage, and their institutional affiliations.

That distinction triggers the Family Educational Rights and Privacy Act. And FERPA’s notification obligations do not flow from McGraw-Hill to affected individuals directly. They flow from McGraw-Hill to the educational institutions that contracted with it, and from those institutions to the students and parents whose records were exposed. The downstream notification chain in a FERPA-covered breach is longer, more complex, and potentially more consequential than the standard commercial data breach notification framework.

Two Attacks, Two Supply Chains

Understanding the McGraw-Hill and Rockstar incidents requires separating two technically distinct attack chains that share an attacker and a deadline.

The McGraw-Hill Attack: Salesforce Experience Cloud Misconfiguration

McGraw-Hill’s breach trace to a misconfiguration in Salesforce Experience Cloud — specifically, a guest user permission that had been left open, granting unauthenticated access to data that should have required authentication to retrieve.

Salesforce Experience Cloud is an enterprise platform that organizations use to build customer-facing portals, partner portals, and community sites. Its guest user functionality is a feature designed to allow unauthenticated visitors to access limited, public-facing content. When organizations misconfigure the guest user profile — granting it access to objects or data intended for authenticated users — they create a pathway for anyone on the internet to query their Salesforce data without credentials.

This misconfiguration class is not new. Salesforce published guidance on guest user security configuration in 2021 and has updated it periodically since. Security researchers have documented the pattern across multiple incidents going back to 2020, including high-profile breaches at state governments and healthcare organizations. The pattern persists because Experience Cloud implementations are often managed by teams with deep Salesforce configuration expertise but weaker security review practices, and because the default security posture for guest user profiles has historically been more permissive than most organizations would choose if they reviewed it explicitly.

For McGraw-Hill, the guest user misconfiguration provided ShinyHunters access to records that the company characterized as “limited and non-sensitive” — a characterization that has been contested by security researchers who reviewed the published data. The published material contains names, email addresses, phone numbers, and addresses for 13.5 million accounts, alongside what appears to be institutional affiliation data and platform usage records.

The Rockstar Games Attack: Anodot-to-Snowflake Pivot

The Rockstar Games breach followed a different chain. ShinyHunters compromised Anodot, an AI-powered business intelligence and anomaly detection platform that Rockstar used for analytics. Through the Anodot compromise, the group acquired authentication tokens that provided access to Rockstar’s Snowflake cloud data warehouse environment.

From Snowflake, they exfiltrated 78.6 million records before issuing the ransom demand on April 7. When Rockstar declined to pay by April 14, the full dataset was published.

The Anodot-to-Snowflake chain is structurally similar to the 2024 Snowflake campaign that affected Ticketmaster, Santander Bank, AT&T, and dozens of other organizations. In that campaign, ShinyHunters and related actors used credentials stolen from vendor environments to access Snowflake tenants that lacked multi-factor authentication. The 2024 campaign prompted Snowflake to enforce MFA for all customer accounts and to issue guidance on authentication token security. The Rockstar breach in 2026 demonstrates that the pattern — vendor credential theft enabling cloud storage access — has not been eliminated. It has adapted to target vendors (like Anodot) whose access to client Snowflake environments was not governed under the same scrutiny as direct Snowflake credentials.

What FERPA Requires — and Why McGraw-Hill’s Breach Is Different

The Family Educational Rights and Privacy Act, 20 U.S.C. § 1232g, governs the privacy of student education records. FERPA applies to educational agencies and institutions that receive funds under programs administered by the Department of Education — meaning essentially every public school district, every state university, and most private colleges and universities in the United States.

McGraw-Hill’s role under FERPA. McGraw-Hill is not itself an educational institution. It is a vendor — in FERPA terminology, a “school official” acting under the direct control of the institution with a legitimate educational interest. Schools can share student data with vendors like McGraw-Hill without parental consent, but only within a defined framework: the vendor must use the data only for the purposes for which the institution disclosed it, and the vendor is prohibited from re-disclosing the data to third parties or using it for its own purposes.

When a vendor that has received student data under this framework experiences a breach, FERPA’s notification obligations activate — but they activate at the institutional level, not the vendor level. FERPA does not require McGraw-Hill to notify students or parents directly. It requires McGraw-Hill to notify the educational institutions that contracted with it, and it creates obligations for those institutions to evaluate whether the breach constitutes a disclosure that requires notification to students or parents under FERPA and applicable state law.

The cascading notification chain. McGraw-Hill serves K-12 schools, school districts, and higher education institutions across the United States. The 13.5 million records in its database include students from potentially thousands of institutional clients. Under FERPA, each of those institutions must:

  1. Determine whether student records from their institution were within the scope of the breach
  2. Assess whether the exposure constitutes a FERPA-covered disclosure
  3. Determine whether state law requires notification to students or parents independent of FERPA
  4. If notification is required, provide it in compliance with applicable timelines and content requirements

This notification chain is more complex than a commercial B2C breach because the responsible party — the educational institution — is two steps removed from the incident, may lack detailed information about which of its students’ records were in McGraw-Hill’s environment, and is subject to overlapping obligations under both FERPA and state privacy laws that vary significantly across jurisdictions.

Theoretical Liability: The $750 Per Record Figure

Security researchers assessing the McGraw-Hill breach have cited a potential liability of $750 per record based on FERPA’s statutory framework — an analysis that produces a theoretical exposure in the billions of dollars and that has received significant coverage.

The $750 figure requires unpacking.

FERPA itself does not provide a private right of action. The Supreme Court’s 2002 decision in Gonzaga University v. Doe confirmed that FERPA’s protection of student privacy is enforceable only through the Department of Education’s administrative process — specifically, the Family Policy Compliance Office — and that individual students cannot sue for FERPA violations in federal court.

The $750 per record analysis draws on state consumer protection statutes, state student privacy laws (California’s SOPIPA, for example), and common law negligence and breach of contract theories, none of which carry a per-record statutory damages figure of $750 directly. The figure is a reference to the general range of per-record litigation outcomes in data breach class actions, not a statutory minimum under FERPA.

What is accurate: the practical exposure from a breach of educational records at this scale involves multiple overlapping legal theories, and the combination of FERPA, state student privacy laws, state breach notification laws, and common law tort claims creates a litigation landscape that is difficult to predict and potentially significant. The fact that FERPA lacks a private right of action does not mean the breach has no legal consequences — it means the legal consequences flow through different channels.

Department of Education enforcement. The Family Policy Compliance Office can investigate FERPA violations and, in cases of repeated or willful non-compliance, can terminate an institution’s eligibility for federal education funds. For McGraw-Hill’s institutional clients that received student data and did not adequately oversee the vendor relationship — if the breach is found to result from McGraw-Hill’s failure to implement appropriate controls — the question of institutional liability under FERPA’s direct control framework becomes relevant.

The Salesforce Misconfiguration Compliance Framework

For organizations using Salesforce Experience Cloud — and there are tens of thousands of them, across every sector — the McGraw-Hill breach is a direct prompt for a configuration audit.

The guest user profile review. Every Salesforce Experience Cloud implementation should have a documented review of the guest user profile that answers: what objects does the guest profile have access to? What fields are visible? What CRUD permissions are granted? The answer should be limited to exactly what public-facing functionality requires — nothing more.

Salesforce’s own Security Health Check tool within the platform provides automated assessment of guest user permissions against recommended security baselines. Running this check takes minutes. Addressing findings takes longer, but organizations that have not run it should do so immediately.

Object-level permission review. Beyond the guest profile, the McGraw-Hill pattern suggests that broader object-level permission audits are warranted. Salesforce implementations frequently accumulate permission sets and profiles over years of configuration changes, and it is common for objects containing sensitive data to have broader access than is currently necessary.

The “public access” test. A practical test for Experience Cloud security posture: can an unauthenticated visitor to your Experience Cloud site access any data through Salesforce APIs by manipulating the requests your site makes? If your implementation has not been penetration tested or security reviewed in the past 12 months, the answer is uncertain.

The Snowflake Authentication Chain: Still Not Closed

The Rockstar Games breach via Anodot-to-Snowflake demonstrates that the third-party authentication token problem that drove the 2024 Snowflake campaign has not been resolved. Snowflake’s 2024 response — enforcing MFA for all customer accounts and issuing guidance on authentication token security — addressed direct Snowflake credential exposure. It did not address the pattern of vendors and tools with API-level access to customer Snowflake environments whose credential security is not managed under the same standard.

Every Snowflake tenant has a list of users and service accounts with access to its environment. Each of those users and service accounts has credentials managed somewhere — within the Snowflake tenant, within a vendor environment, within an integration platform. The attack surface is not the Snowflake credentials themselves; it is the full chain of systems that hold those credentials.

Vendor access audit for Snowflake environments. Organizations using Snowflake should maintain an inventory of all external vendors, tools, and services with access to their Snowflake environment, the credentials those parties hold, and the security controls governing those credentials. Any vendor in that inventory whose security posture has not been assessed in the past 12 months is an unassessed risk.

Token revocation procedures. Rockstar’s breach via Anodot-to-Snowflake followed the same pattern that enabled the Vercel breach via Context.ai-to-Google Workspace: a third party’s compromise provided tokens that retained access to downstream systems. Token lifecycle governance — expiration, rotation, revocation on vendor incident — is the control that breaks this chain.

McGraw-Hill’s “Non-Sensitive” Characterization: A Compliance Concern in Itself

McGraw-Hill’s public response characterized the exposed data as “limited and non-sensitive” — language that has drawn criticism from security researchers who reviewed the published material.

From a compliance perspective, this characterization creates its own risks. The educational institutions that are McGraw-Hill’s institutional clients and that hold FERPA compliance obligations for their students have an interest in accurate characterization of what was exposed, because their own notification analysis depends on it. A vendor’s minimization of breach scope — if that minimization is later contradicted by independent analysis of the published data — creates liability exposure for the vendor and erodes the trust of institutional clients.

For educational institutions that use McGraw-Hill products and have not yet received formal breach notification, the appropriate posture is to:

  1. Request a direct, written briefing from McGraw-Hill on the scope of the breach, the specific data categories exposed, and whether your institution’s student data was within the affected environment
  2. Conduct your own assessment of whether the breach constitutes a FERPA-relevant disclosure
  3. Consult your institution’s privacy counsel on whether your state’s student privacy laws require notification independent of FERPA
  4. Document the assessment and your conclusions, regardless of whether notification is ultimately required

What This Wave of ShinyHunters Activity Means for Third-Party Risk Programs

April 2026’s ShinyHunters activity — McGraw-Hill via Salesforce misconfiguration, Rockstar Games via Anodot-to-Snowflake — follows the Booking.com and Adobe BPO vendor incidents covered earlier this month. Taken together, this cluster of supply chain breaches represents a sustained focus on vendor-pathway attacks as the preferred methodology for accessing large-scale consumer and enterprise data.

The pattern has practical implications for third-party risk management programs:

Attack surface mapping extends to vendor-to-vendor relationships. A vendor that has API-level access to your cloud environment may itself use sub-vendors or platforms with access to those credentials. Your vendor inventory should capture not just direct vendor access but the tools and platforms your vendors use to provide their services.

Security questionnaires are lagging indicators. The Anodot-to-Snowflake chain was not stopped by Rockstar’s vendor management program, assuming one existed. Annual or periodic security questionnaires do not detect configuration drift, new vendor integrations, or credential exposure in real time. Continuous monitoring tools — SSPM (SaaS Security Posture Management) for Salesforce, CSPM (Cloud Security Posture Management) for cloud environments, and CAASM (Cyber Asset Attack Surface Management) for vendor-to-vendor access mapping — provide detection capabilities that questionnaire-based programs cannot.

The cost of “non-material” characterizations. Both McGraw-Hill (“limited and non-sensitive”) and Rockstar Games (“limited amount of non-material company information”) characterized their breaches minimally. Both characterizations have been contested. From a compliance program perspective, minimizing a breach’s characterization in public statements before the investigation is complete creates risk — for regulatory credibility, for litigation posture, and for the institutional client relationships that depend on accurate information to meet their own compliance obligations.

Immediate Actions for Educational Technology Vendors and Institutions

For educational technology vendors using Salesforce Experience Cloud:

  • Run the Salesforce Security Health Check immediately — focus on guest user profile permissions
  • Review all object-level permissions for data categories covered by FERPA and COPPA
  • Engage a Salesforce security specialist for a penetration test focused on unauthenticated access vectors

For educational institutions using McGraw-Hill platforms:

  • Request written confirmation from McGraw-Hill on whether your institution’s student data was within the scope of the April breach
  • Review your DPA (Data Processing Agreement) with McGraw-Hill for breach notification timelines and obligations
  • Assess your FERPA notification obligations under your state’s student privacy law independently of McGraw-Hill’s characterization

For all organizations with Snowflake environments:

  • Inventory all vendors, tools, and service accounts with access to your Snowflake environment
  • Enforce MFA for all human users; implement IP allowlisting for service accounts where operationally feasible
  • Establish token expiration and rotation policies; include token revocation in your vendor offboarding and vendor incident response procedures

The Compliance Through the Supply Chain Problem

Both the Salesforce misconfiguration and the Snowflake authentication chain attacks succeed for the same structural reason: organizations have built significant data infrastructure on cloud platforms and have granted third-party vendors access to that infrastructure, but the governance of that access — who has it, what it covers, how it’s revoked, and how it’s monitored — has not kept pace with the growth of the access itself.

FERPA, GLBA, GDPR, and SOC 2 all require that organizations govern third-party access to sensitive data. None of them require that governance be perfectly executed. All of them require that it be attempted seriously and that the attempt be documented.

The McGraw-Hill and Rockstar incidents are not failures of technology. They are failures of governance — in one case, a configuration mistake that should have been caught in review; in another, a vendor access relationship whose security posture was not monitored. Both are correctable. Neither should recur in a program that has taken the April 2026 supply chain wave seriously.

This article draws on reporting from BleepingComputer, Cybernews, The Record (Recorded Future News), Tom’s Hardware, and security analysis from Rescana and Shieldworkz. It draws on regulatory text from FERPA, 20 U.S.C. § 1232g, Department of Education guidance on vendor relationships, and Salesforce’s Security Health Check documentation. This article is provided for informational purposes only and does not constitute legal advice.