COMMENTARY: In late April, hackers broke into Instructure's Canvas Learning Management System.By the time it was over, ShinyHunters had defaced login pages at hundreds of institutions, knocked students offline during finals week at thousands of schools, and claimed to have made off with 3.65 terabytes of data – roughly 275 million records spanning 8,809 institutions worldwide.[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]Instructure paid the ransom on May 11 and says it has confirmation the stolen data was destroyed. The company calls the issue resolved.That's a generous reading of events. The institutions caught up in this had no say in Canvas's security architecture, no way to audit the platform, and no seat at the table during incident response, and they're the ones left holding the legal, regulatory, and reputational bag.Most institutions have a decent handle on their own directory and their own SSO logs. Almost none have real visibility into how a vendor's internal account tiers, API integrations, and service accounts stretch that environment well past their control. Canvas runs 41% of North American higher ed, and a design flaw in one freemium tier turned into a global incident because that tier was never actually separate from the rest of the platform.There's no single product or one-time vendor audit that fixes this. It takes treating vendor-extended identities as part of the institution's real attack surface, discovering them, prioritizing them by actual exposure, and acting on them with the same rigor as internal accounts, instead of discovering them only after a login page has already been defaced.Bassam Al-Khalidi, co-founder and chief innovation officer, AxiadSC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
What actually happened
The entry point was Canvas's Free-For-Teacher program, a freemium tier that let individual educators spin up accounts with almost no institutional verification, running on the same back-end infrastructure as every fully-licensed institutional deployment. Public technical reporting traces the breach to stored cross-site scripting flaws in user-generated content within that free tier; Instructure has not yet published a full root cause report.So an attacker was abke ti inject code, hijack an authenticated session, and climb from a throwaway, unverified account straight into the platform's core, where the real institutional data lives. Instructure has since permanently discontinued Free-For-Teacher, which is about as clear a concession as a vendor can make that the tier itself was the problem.It's worth being precise here because this wasn't a story about weak passwords or missing MFA. It was a trust boundary failure. A low-privilege, barely vetted corner of the system was wired directly into environments holding sensitive customer data. Instructure first disclosed the incident on May 1 and declared it resolved on May 6, but the underlying design flaw hadn't actually been fixed yet. ShinyHunters proved that within 24 hours, defacing login pages at roughly 330 institutions with a second ransom note. It was the group's second confirmed breach of Instructure in eight months, following a September 2025 compromise of the company's Salesforce environment.What got exposed: names, email addresses, student ID numbers, and private messages between students and teachers. Instructure says there's no confirmation that passwords, dates of birth, government IDs, or financial data were taken. That helps, but it doesn't count for much when what was taken is exactly what someone would need to run a convincing impersonation campaign against students, faculty, or a financial aid office.Why "resolved" doesn't mean "safe"
A ransom payment and a vendor's word that the data's been destroyed don't hand institutions their control back. Affected schools are still on the hook for breach notification, still exposed under FERPA and the 130-plus state student privacy laws now on the books, and still dealing with insurance implications that don't just go away because a criminal group emailed over a "shred log."The courts are already making this point: more than half a dozen proposed class actions have been filed against Instructure in federal courts in Utah, New York, and California. And two months after the ransom payment, the response has still not been finished. As of late June, Instructure was still finalizing customer-specific data findings and asking institutions to designate a security contact to receive them.The recompromise represents the real lesson here, and it applies well outside higher ed. When a vendor says "contained," that's a description of what they observed, not a guarantee of what's actually true. Two breaches of the same company by the same attacker in eight months, through two completely different attack surfaces: that's not a story about one unpatched control. It's a story about nobody having a full picture of how trust and privilege move through the environment.What security leaders should do now
If organizations using touches Canvas, or those running any SaaS platform with a tiered account structure, treat this as a template, not a one-off:- Rotate credentials and API keys for any Canvas integration, and audit which service accounts and third-party tools have standing access.
- Inventory free or low-verification account tiers connected to primary systems, and set policy prohibiting their use for institutional activity going forward.
- Issue phishing and vishing advisories. The exposed data gives attackers real names, real institutional emails, and real conversational context, enough to make a fraudulent call or email from "IT support" or "financial aid" highly convincing.
- Notify the cyber insurance carrier, even without an obvious claim yet; most policies condition coverage on timely notice.
- Move toward phishing-resistant authentication, credentials cryptographically bound to a specific application, such as FIDO2/WebAuthn passkeys or hardware-backed certificates, for any workflow tied to sensitive student or institutional data. Traditional MFA (push notifications, SMS codes, TOTP codes) are easily defeated by a user who's been socially engineered with exactly the kind of context this breach handed attackers. Phishing-resistant credentials remove that human judgment call from the credential itself.
