How the Instructure Canvas breach placed 9 000 schools in regulatory crosshairs

Most institutions treat third-party dependency as an operational problem. You map the outage scenarios. You write the disaster recovery plan. You agree on a recovery time objective with the business and test the failover once a year. All of it is built around one assumption: that the event has an end date.

In May 2026, thousands of schools and universities had all of that in place. And while Canvas came back online inside a week, the data-protection consequences are still developing. No recovery plan will make up for the schools' poor dependency choices, or protect them against the regulatory fallout.

This article covers how the breach happened, what it now exposes those institutions to, and how software escrow protects against similar operational and compliance failures.

TL;DR

• What happened: ShinyHunters exploited cross-site scripting flaws in Canvas's free teacher tier to hijack administrator sessions, reaching names, email addresses, student ID numbers, and private student–faculty messages held for paying institutions.

• Why it matters: Nearly 9 000 institutions must notify students and regulators about a breach they cannot investigate. FERPA puts that duty with the schools, and the Department of Education could enforce it by withholding federal funding.

• What to do: Hold less in any single platform, and keep an independent copy of the code, data, and environment you run on through SaaS Escrow.

A free Canvas tier exposed student data across nearly 9 000 institutions

Canvas is Instructure's learning management platform, used by over 30 million students and teachers worldwide to submit coursework, check grades, and message instructors. ShinyHunters didn't need a customer account to get in. They registered for Free-for-Teacher, the free self-service tier, and planted malicious JavaScript in features where users post their own content. This gave them administrator access that enabled them to jump from the free tier and access the data of paying institutions.

So the exposure of all the schools on Canvas was set by a product surface unrelated to what the schools had bought or even reviewed. Any of your vendor's products, free tiers included, fall inside your risk boundary whether you use them or not.

Instructure followed the right protocol at first. It disclosed publicly within days of detection, brought in third-party forensic investigators, and revoked the unauthorized access. It negotiated on behalf of every affected customer at once, stating that no customer needed to engage the attackers directly.

It wasn't enough. While Instructure finally declared the intrusion resolved on May 6, 2026, ShinyHunters were back the very next day (using the exact same vulnerability), defacing login pages with ransom notes and taking the platform down mid-finals. Educational institutions around the globe had resumed operations on the faith of Instructure's declaration, with no way to test if it was truly safe first.

The University of Illinois postponed every final exam and assignment through May 10. Baylor delayed its May 8 exams and asked faculty to hand out study materials from local computers. Institutions were forced to postpone assessment, but migrating to another service wasn't an option, since all the coursework, submissions, and gradebooks lived on the Canvas platform.

Then there's what left the building. Instructure admits to compromised names, email addresses, student ID numbers, and messages between students and faculty. While passwords and financial data were untouched, the rest is more than enough to impersonate a school to its own students, and the FTC warned that scammers would do exactly that.

Over two dozen federal lawsuits followed, the lead case seeking more than $5 million, with owner KKR named alongside Instructure. Every one of those proceedings runs against the vendor. The educational institutions carry a separate exposure, for third-party dependency management and data handling.

» Uncover how much risk your systems carry with this quick risk assessment.

This is how improper due diligence leads to regulatory non-compliance

The exploited vulnerability was Instructure's fault. But the schools are responsible for the volume of data exposed in the breach. It came down to their internal decisions to consolidate so much under one vendor.

It's not unfair finger-pointing either; these educational institutions had options: 

• Course records identified by student numbers alone, with the file linking those numbers to real identities held on a separate admin platform.

• Message histories downloaded and archived to satisfy retention periods, but scrubbed from the external platform.

• Administration split from coursework across separate systems, ensuring independent copies of student records and submissions.

And there's public guidance detailing those measures for exactly this reason. The US Department of Education defines data minimization as "only collecting personally identifiable information that is directly relevant and necessary to accomplish the specified purpose(s)," and describes keeping the file that links direct identifiers to student ID numbers in separate secure storage.

That lack of due diligence is why the people in those records had no agency in what happened to them. Students spent finals week posting things like "I'm locked out of my exam." Holding data on someone else's behalf raises the security standards and protocols you need to adhere to. Merely entrusting that to a single third party isn't a responsible choice, which is exactly why regulatory liability remains with the educational institutions.

An over-reliance on third parties to manage data security is exactly why attackers targeted the platform itself. Mandiant's M-Trends 2026 puts it plainly: "By compromising third-party SaaS vendors, attackers steal hard-coded keys and personal access tokens, using those secrets to seamlessly pivot into downstream customer environments to execute large-scale data theft."

One compromise yields many downstream environments, which means consolidation raises your value as a target even if your own software security measures are airtight. Damon Linker, a senior lecturer at the University of Pennsylvania, reached the obvious conclusion: "I'm starting to rethink whether this is really a wise way to proceed."

And this issue isn't unique to education. On January 22, 2026, one Microsoft 365 incident took Outlook, Exchange Online, Teams, and SharePoint down together for nine hours and 22 minutes, because they share routing architecture. Reports peaked at over 30 000 users, on a platform carrying more than 450 million commercial paid seats.

Holding only what's needed in each system you run is a best-practice security choice backed by the incident findings we see every day. Just in the first half of 2026, one vendor's breach accounted for 58% of all data breach notice issued worldwide. This isn't groundbreaking news, which makes not planning for it outright negligence.

The regulatory consequences could outlast the outage by years

The operational damage comes down to whatever it cost to delay most of the term and get students back on track. The non-compliance consequences could run for years.

Every US school that puts student records into a platform like Canvas does so under FERPA, and the Department of Education is explicit about what that means: when personally identifiable information (PII) from education records is disclosed to a provider, FERPA still governs its use, and the school or district is responsible for its protection.

The only lawful exception to that arrangement is called "school official," which requires the provider to be under the direct control of the institution for those records. Since none of the schools controlled the vulnerability, the remediation, the resolved declaration, or the ransom negotiation, the condition the exception rests on wasn't met.

Under 34 CFR § 99.67, the Secretary of Education can withhold payments under any applicable program or terminate an institution's eligibility for federal funding. The Department also states it prioritizes formal investigations by the severity of risk to student privacy and the number of students affected — the two axes this event maxes out.

Where a third party is found responsible for a violation, the institution may not allow that third party access to personally identifiable information from education records for at least five years. For a school in that position, that means porting every record and workflow into a new system while banned from the vendor its entire operation was built around.

The clocks make it harder. The University of Sussex told its community it would contact affected individuals "once we receive this information" — a UK institution under a 72-hour notification duty, waiting on a US vendor to say whose data was exposed, and against a ceiling of £8.7 million or 2% of worldwide turnover — that's not a situation that plays out well.

So far, none of these institutions have been hit with the consequences they're now liable for. The Department of Education has, in fact, never withdrawn funding for a FERPA violation or imposed the five-year ban. What makes this incident different is the sheer number of students affected and the degree. For many of these schools, pulled federal funding or a forced migration would be ruinous.

» Learn how to ensure your compliance amidst the changing regulatory climate.

How to protect your business against attack-driven non-compliance

The first thing to get out of the way is to take an option off the board. The FBI advises against paying a ransom in response to a ransomware attack. Paying "doesn't guarantee you or your organization will get any data back," it "encourages perpetrators to target more victims," and it "offers an incentive for others to get involved in this type of illegal activity."

That means you have three jobs to lessen the impact of an attack. Reduce your reliance on any single vendor. Practice safer data handling with everything on a need-to-know basis, because the less data in one system, the better. And ensure recovery avenues for all your operations.

The first two are a matter of due diligence. For the latter, you need software escrow. 

• Attacks: Canvas went down and took the school term with it, and the University of California's only lever was instructing every location to block access. Our SaaS Escrow service holds source code, documentation, software data, deployment infrastructure, dependencies, and credentials on daily automated syncs, stored outside your provider's environment, so you can run a clean version of an application you depend on with all your data intact.

• Failure: A regulator can bar you from a provider, and a provider can go insolvent or drop support. Either way, the relationship ends while your operations still need the software. Our Software Escrow service guarantees you get the source code, documentation, and build instructions, so the end of a contract doesn't decide whether your business keeps running.

• Non-compliance: GDPR, ISO 27001, DORA, NIS2, and CPS 230 all require tested continuity to recover from incidents. Our Verification service runs a full build and deployment test of your deposits, then issues a Software Resilience Certificate that satisfies auditors under ISO 27001, DORA, and NIS2.

• Broken: Remediation failed twice here, and in July, Instructure paused delivery of breach findings because the third-party platform chosen to deliver them may itself have been subject to a security threat. With Software Backup, your code, databases, configurations, and documentation sit in an immutable, versioned vault that no fix or failure inside your provider can reach.

Mandiant explains why it's necessary to keep recovery avenues separate from your (or your provider's) other operations: "Ransomware groups are no longer just encrypting data; they are actively destroying the ability to recover."

If this happened to your business

You found the platform that finally did everything. Records, customer management, billing, scheduling, internal comms, one login, all of it connected. It worked. So every year you moved something else in, and every year that felt like the sensible call.

Then the breach lands. Most of what your business does day to day is behind a login that isn't responding. Every personal record you hold is now a line in someone else's incident report, and you can't tell your customers which of them are in it.

Your regulator's clock starts on the day you found out. Your customers' lawyers start on the day after. And the platform holding the operations you'd need to recover into is the one you can't enter, can't fix, and may not be permitted to keep using.

Data portability is now a compliance control

Most recovery plans assume you need to go back to the platform you came from. For US schools, the Department of Education's five-year rule is what removes that assumption. They could be forced to fully recover, data intact, on a competitor's systems.

And that penalty isn't unique to education. Under DORA, EU authorities can require financial entities to "temporarily suspend, either in part or completely, the use or deployment of a service" from a critical ICT provider, or terminate the contract outright. Under GDPR Article 58, a supervisory authority can impose "a temporary or definitive limitation including a ban on processing."

So your recovery plan and exit strategy can't be treated as two separate projects. A migration forced by a regulatory body will require a full data recovery too. Holding separate copies of all your data, workflows, and the systems you depend on is the only way to escape both jaws of that trap.

Make sure you can migrate and recover when you need to with Codekeeper's Software Escrow. 

» Book a call with our escrow experts to learn how you can ensure a third-party dependency doesn't become a compliance nightmare.