In early May 2026, the cybercriminal group ShinyHunters breached Instructure; the company behind the Canvas learning management system. They walked away with 3.65 terabytes of data covering an estimated 275 million students, teachers, and staff across 8,809 educational institutions. Australian schools, including the University of Melbourne and RMIT, were among the affected. what we know is around 200 million records have been exposed. It is the largest educational data breach on record.
Despite the scarcity of information about the breach, I decided to collect and collate what little information about that attack and draw on some simple lessons learnt
This wasn't ransomware in the traditional sense. ShinyHunters didn't encrypt files, they steal data and extort under a "pay or leak" model, and then they wiped out the tenancy data of nearly 8000 schools and education institutions.
Instructure detected the intrusion on 29 April. By 2 May they publicly stated the incident was "contained." On 7 May, ShinyHunters re-entered using the exact same vulnerability, this time defacing the login pages of roughly 330 institutions with a ransom note. The hackers' own message was blunt: "Instead of contacting us to resolve it, they ignored us and did some 'security patches."
It appears that Instructure had patched the issue (or some other vulnerability), however, the underlying design flaw was still live.
Their entry point into Canvas was a stored cross-site scripting (XSS) vulnerability inside the Free-For-Teacher (FFT) program, (a feature that allowed individual educators to create Canvas accounts without any institutional verification). ShinyHunters injected malicious JavaScript through user-generated content, rode an authenticated admin session, and crossed into the broader platform.
The architectural problem was that FFT accounts sat on the same underlying infrastructure as paid institutional tenants and share the same back-end database. The only separation was logical. Once attackers were inside the FFT boundary, they were effectively inside Canvas. Names, email addresses, student IDs, and private messages between students and staff were all accessible from there.
While we don't know for sure, but we assume that Instructure paid the ransom. Instructure claims the data was destroyed. There is no way to verify that, and we suggest that this "assurance" should be considered with a grain of salt.
Worth noting that this was ShinyHunters' second hit on Instructure in eight months. Their September 2025 compromise targeted Instructure's Salesforce environment through social engineering; a completely different attack class against different infrastructure. Two incidents in eight months from the same threat actor is a vendor maturity concern. It should have been a procurement red flag for anyone renewing Canvas contracts in 2026.
The Canvas breach isn't a single control failure; similar to all data breaches, the breach was a result of amalgamation of control failure accumulated during the months or years leading to the incident. Here is where I believe they have failed:
Patch management is necessary but you need to understand that rolling Microsoft Patch Tuesday patches is not sufficient. In this case, Instructure's own partial patches failed because they have a code vulnerability that allowed for the issue to appear.
For all of us, the lesson is a good reminder to all of us to ensure your own environment is patched against known vulnerabilities, and hold your vendors to the same standard (not just on infrastructure level patching, but also web application Patching too).
When a vendor tells you an incident is resolved, ask specifically: "Has the root cause been identified and remediated, or have you only addressed the immediate access vector?" Those are different things, and the Canvas timeline proves why the distinction matters.
For Canvas-connected environments specifically: rotate API keys, OAuth tokens, and SSO credentials now if you haven't already. The exposure window ran from 30 April to 7 May. Anything generated before that window should be treated as potentially compromised.
Standard vendor risk questionnaires don't ask the right questions. Asking a vendor for a SOC 2/ISO27001 compliance is not enough. After this incident, your vendor risk programme should include:
SOC 2 and ISO 27001 are a floor, not a ceiling. Treat your SaaS vendors as an extension of your own attack surface; because that is exactly what they are.
The XSS attack in this breach rode an authenticated admin session. That is the attacker's prize: a logged-in administrator interacting with content, their credentials and session tokens in play. Privileged Access Workstations (PAWs) directly reduce this risk.
A PAW is a hardened, dedicated device used exclusively for administrative tasks — it does not browse general web content, check personal email, or run standard user applications. Had Canvas administrators been operating from PAWs, the attack surface for an XSS payload delivered through user-generated content would have been substantially reduced. An admin browsing FFT content from their administrative session is exactly the scenario a PAW programme is designed to prevent.
For schools, this does not require an enterprise-grade physical device refresh. A Windows 365 Cloud PC with network isolation, constrained internet access, and Conditional Access policies enforcing device compliance can deliver the PAW model at manageable cost. The key principle is simple: your most privileged credentials should never touch the same device or session that interacts with untrusted content.
Schools should review which staff hold administrative roles in Canvas or connected platforms, and ensure those roles are accessed only from isolated, hardened sessions — not from the same laptop used to mark essays and open student email attachments.
Most school security teams — if they have a dedicated team at all — are investing heavily to have a 24/7 Security Operation Centre to monitoring their own on-premises or cloud environments. There is a need to hold SaaS vendors to the same standards! If school with their limited budget can find the money to spend on 24/7 SOC monitoring, so should their SaaS Providers.
In addition, third-party SaaS platforms like Canvas are rarely ingested into a SIEM. That needs to change. Canvas and similar platforms should provide audit logs and API event streams. Those logs should feed into your security monitoring capability so that anomalous administrative activity; unexpected login page modifications, bulk data exports, API token creation outside normal hours, generates an alert. In this incident, Instructure's own detection took four days. An independently monitored environment gives schools visibility that doesn't depend entirely on the vendor's alerting. While this step would not have prevented the breach, it is something we must surface and prioritise
For schools without an in-house SOC capability, this is exactly the use case for a a Virtual CISO (vCISO) . The objective isn't to rebuild Instructure's incident response function; it's to give your institution independent eyes on SaaS audit logs so you are not solely reliant on a vendor's "all clear" to know your data is safe.
This is the hardest recommendation to act on as a school, because it requires holding vendors to account before you sign the contract — not after the breach.
The Canvas FFT vulnerability was not a bug introduced in a recent release. It was a design decision: allow unverified users to onboard quickly, place their accounts on the same infrastructure as institutional customers, separate them logically. That decision was made years before May 2026, and it was never challenged at procurement. The certification bodies didn't flag it. The vendor questionnaires didn't surface it. It sat there until someone with bad intent looked for it.
Modern SaaS architecture should implement hard isolation between service tiers — separate tenants, separate control planes, separate data planes where the risk profile differs significantly. "Free tier" and "institution holding 300,000 student records" are not equivalent risk tiers. They should not share infrastructure.
As a customer, you can enforce this by making tenancy isolation architecture a documented contractual requirement at onboarding — not a checkbox, but a written obligation the vendor must describe and demonstrate. If a vendor cannot clearly explain their tenancy isolation model, treat that as a risk finding.
If your institution uses Canvas, the immediate priority list is:
Instructure has stated it reached an agreement with ShinyHunters and received confirmation of data destruction. That may be genuine. Your plan should not assume that your data is safe, you need to assume that the data is still out in the hands of attackers, I mean, do you really trust their word for it? I won't.
ShinyHunters are not a sophisticated nation-state actor. They don't need to be. They found an unverified account tier sitting on shared infrastructure, exploited a decade-old vulnerability class, and walked out with data on 275 million people. Then when their victim claimed the incident was over, they walked back in through the same door.
The controls that would have stopped this are not novel: proper application security reviews, multi-tenancy architecture that enforces hard isolation between tiers, privileged access management for administrative sessions, independent monitoring of SaaS audit logs, and a vendor risk programme that asks better questions.
Schools are not the natural home of mature security programmes. Budget is constrained, technical staff are stretched, and the pressure to prioritise education delivery over security investment is real. But the data inside an LMS — the messages between vulnerable young people and their teachers, the identities of minors, the academic records — carries serious obligations. After this breach, "our vendor has a SOC 2" is not a sufficient answer to those obligations.
Expect a secondary wave of spear-phishing and social engineering targeting staff and students from this data in the coming months. Make sure your people are ready for it.
If your institution needs support reviewing its SaaS vendor risk posture, standing up independent monitoring, or preparing for the next incident, Spartans Security's vCISO service, penetration testing, and incident response capability are built for exactly this.
