The Canvas LMS breach.
What higher-ed CISOs
should do this week.

The largest educational security breach on record.

Between April 30 and May 7, 2026, the threat actor ShinyHunters exfiltrated approximately 3.65 TB of data — roughly 275 million records — from Instructure's Canvas LMS. [1][2]

The exposure spans 8,809 universities, school systems, education ministries, and other institutions worldwide, including major US universities. Harvard, Columbia, Rutgers, Princeton, Kent State, and Georgetown have all issued statements alerting their communities. [3][4]

The attack vector was Instructure's Free-For-Teacher (FFT) program, which allowed educators to create Canvas accounts without institutional verification. ShinyHunters exploited this self-service onramp to obtain database access. [5][6] Instructure has since paused or restricted the FFT program and is working with affected institutions.

For context on scale: Canvas runs on 39% of US higher-education institutions and 50% of student enrollment across North America as of Spring 2025 (Edutechnica). [8] This is not a niche LMS breach. It is a structural exposure of the dominant learning platform in US higher education.

The breach is not the attack. It is the fuel.

Most data-breach response playbooks assume the exposed information is the threat. Passwords leak, you rotate credentials. Card numbers leak, you reissue cards. The Canvas breach does not fit that pattern. No passwords were exposed. No payment data. No government IDs.

What was exposed is something more useful to attackers: the scaffolding of trust. The real names of every person at your institution. Their official email addresses. Their student IDs. And the private messages they sent each other, including specific course references, instructor names, assignment context, and the linguistic patterns of how your community actually talks.

This is the raw material for spear phishing that is indistinguishable from legitimate institutional mail. An attacker can now send an email that:

• Comes from a plausible institutional-looking address
• Addresses the recipient by their real name and student ID
• References the specific course they are currently enrolled in
• Quotes language from a real private message in that course
• Drives the recipient toward a credential-harvesting page, a tuition redirect, or a wire request

Trend Micro's assessment is direct: the weeks following the breach will bring spear-phishing campaigns “nearly indistinguishable from legitimate institutional communications.” [1]

Your signature-based email gateway, including Defender for Office 365 and traditional secure email gateways, was not designed to catch this. The signatures the gateway looks for, malicious URLs, known-bad attachments, sender reputation failures, will not fire on a well-crafted message from a freshly registered domain that references a real student's real course. Your security-awareness training, including KnowBe4 simulations, was not designed for messages this specific either. Teaching people to spot generic phishing does not prepare them for an email that quotes back something they actually wrote last week.

The defense surface that catches this is the conversation itself: does the email behave like an authentic institutional communication, given everything we know about how your community communicates? That is a different question than “is this URL on a blocklist.”

Five operational actions, in priority order.

1. 01

   Send the breach notification yourself, before students hear about it elsewhere.

   If your institution is on the exposure list and you have not already communicated, do it today. Templated language is fine. State what was exposed, what was not, what to expect (phishing using real course context), how to report suspicious mail, and the single canonical channel for verifying institutional communications. Silence cedes the narrative to attackers, and to the first student who posts the breach to a campus subreddit.

2. 02

   Brief your high-value targets in person or by phone, not by email.

   Bursar, financial aid, payroll, accounts payable, registrar, advancement, sponsored research, IT helpdesk leads. The combination of real names, real course context, and quoted private messages turns these individuals into specifically engineerable targets. Walk to their desk. Call them. Send a Signal message. Do not brief them about an impersonation risk by sending email that itself can now be impersonated.

3. 03

   Pre-stage abuse-mailbox triage capacity.

   Phishing reports are about to spike. Whoever currently processes abuse@your-institution.edu likely cannot handle the volume alone. Route all reports through a single inbox, add additional triagers, and consider automation to deduplicate and cluster reports by attacker template. The point is not to read every report. The point is to detect campaigns within hours, not days.

4. 04

   Tighten email authentication. Set DMARC to p=reject if you have not already.

   Confirm SPF and DKIM alignment for every legitimate institutional sender, including any third-party platforms that send on behalf of your domain. Audit your subdomain DMARC policies. Block close-spelling lookalike domains aggressively for the next 30 days. None of this is new advice. It is unfinished work that becomes urgent now.

5. 05

   Audit Canvas-adjacent integrations and session-token lifetimes.

   The breach did not include passwords, but it included a great deal of identity scaffolding. Anywhere Canvas authentication ties into SSO, payment systems, or sensitive administrative tooling, shorten session lifetimes and re-prompt for authentication on sensitive actions. Review API tokens issued to integrations that read from Canvas. The next attack will not be a brute-force login. It will be a session that quietly looks correct.