Inside the 2026 Canvas breach

On 2 May 2026 Instructure said the breach of Canvas, its learning platform, was contained. Five days later the attacker was back in through a second bug of the same kind, and roughly 300 organisations found a ransom note on their Canvas login page¹. The first hole had been closed. A second one, in the discussions feature, was still open¹.

For UTS Tech Fest 2026, two teammates and I took the incident apart. UTS was among the universities that issued statements about it¹⁰, so this was close to home. We rebuilt the timeline, mapped each step to MITRE ATT&CK, and wrote the response plan we think Instructure should have followed, using the Australian Cyber Security Centre's guidance and the rules an Australian company would have to report under.

This post is that project, updated with what Instructure has since published about the root cause and the data that was taken. It starts with the response, because that is the part we think went most wrong.

Where the response went wrong

Reported. Instructure detected the activity on 29 April and revoked the attacker's access^4,6. It disclosed the incident on its status page on 1 May, and on 2 May said the issue was contained⁴.

Reported. On 7 May the attacker regained access through a second stored XSS bug, in the discussions feature. Instructure says that bug was still unpatched, and that the attacker got around the earlier fix by using the OAuth flow to generate a token¹. The attacker then pushed CSS through Canvas's custom themes feature, which put a ransom note in front of roughly 300 organisations^1,3,5. Students were posting screenshots on Reddit by the early afternoon, US time, and Instructure took Canvas down, during finals for many institutions^1,4. Instructure says it detected and disabled this second attack about 10 minutes after it began, and has found no evidence that data was taken on 7 May¹.

Reported. On 11 May, a day before the attacker's new deadline, Instructure said it had reached an agreement with the attacker, apologised for the lack of transparency on its incident page, and said it had been given evidence that copies of the stolen data were deleted^1,4,6. In Australia the announcement landed on 12 May, local time⁶. A proposed class action was filed in the US District Court for the Southern District of California on 13 May⁴.

Reported. Instructure has not announced a payment. Its customer FAQ does, in an undated entry, answer the question of why it "decided to pay the ransom", defending the decision without disputing the premise or giving an amount¹. A figure of US$10 million has circulated only as an unconfirmed rumour⁴.

Our analysis. Three things went wrong in the response, and none of them needed new technology to avoid. "Contained" was declared on the strength of one fix while a second bug of the same class was still open. The public account stayed thin enough that Instructure ended up apologising for it. And the payment has been acknowledged by implication rather than stated, which leaves schools and students to guess what was agreed on their behalf.

How they got in

What Instructure has confirmed

Reported. Instructure's incident page sets out the root cause, though that explanation carries no publication date¹. It started with a free account. Canvas ran a Free-For-Teacher programme whose accounts could be created without institutional verification. Bitdefender's analysis is that those accounts shared infrastructure with paying institutions².

On 22 April the attacker used one of those accounts to lodge a support ticket with what Instructure called "a linked file with hidden code"³. On 25 April a customer service agent opened it, and the code ran inside the agent's logged-in session. This is stored cross-site scripting (XSS): the script is saved on the server and runs later, in someone else's session. Instructure says it gave the attacker an authorization token and elevated access within Canvas¹.

Between 28 and 30 April the attacker used that access to pull data out through Canvas's APIs: usernames, email addresses, course names, enrolment information and messages^1,3. Instructure says the messages are still under forensic review, and that none of the data fields involved were designed to hold passwords, dates of birth, financial details or grades¹. On 21 May it gave Canvas administrators preliminary findings on which data fields were taken, and on 26 July it began delivering the exfiltrated user and provisioning data to each affected institution's named security contacts¹.

What ShinyHunters claimed

Claimed. ShinyHunters posted a ransom note on 3 May claiming the breach⁴, with a deadline of 7 May that it later moved to 12 May². It said it had taken 3.65 TB of data on about 275 million users across nearly 9,000 schools⁴. Instructure has not confirmed these figures². The count of 8,809 affected institutions comes from Reuters, as cited by Wikipedia, not from the attackers⁴.

Day by day

The Source column says whose account each row rests on. The technique IDs are our mapping to MITRE ATT&CK Enterprise⁷, not Instructure's.

Why it worked

Our analysis. There was no clever zero-day here. XSS has been in the OWASP Top 10 for over a decade. What made it so costly was four gaps sitting on top of each other:

• Unverified accounts on shared infrastructure. A Free-For-Teacher account needed no institutional verification, and by Bitdefender's analysis it shared infrastructure with paying institutions².
• Untrusted content opened in a trusted tool. A ticket from an anonymous user was rendered inside a staff session. Scott Helme, who infers that the session could reach across customers, calls the ticket "the back door to your admin console"³.
• One token was enough. A single token lifted from a browser gave elevated access inside Canvas¹. On Reuters' count, data from 8,809 institutions followed⁴.
• "Contained" before the bug class was fixed. The first XSS bug was closed. A second one, in discussions, was not¹. Helme argues a strict, nonce-based Content Security Policy could plausibly have stopped both scripts from running, while saying this is analysis rather than a tested result, and that CSP would not necessarily have stopped the CSS defacement³.

What we'd have done

Our analysis. We built our plan on the ACSC's incident response guidance⁸ and split it into six phases. Everything in this section is our recommendation, not a description of what Instructure did. The dashed box is where the real response went wrong.

1. Prepare

Treat anything a free user submits as hostile. Clean user HTML with an allowlist sanitiser like DOMPurify, and set a strict Content Security Policy so an injected script doesn't run even when the filter misses it. Open support tickets in a sandboxed viewer, not in a session that can touch customer data. Put the free tier on its own infrastructure, and keep tokens short-lived: eight hours at most, with keys rotated every 30 days.

2. Identify

Alert on bulk API reads, logins from new locations and off-hours activity. Flag any token that touches more than one tenant, or that's been in use for eight hours without re-authenticating. Collect CSP violation reports too. A blocked script inside a staff session is a loud signal.

3. Protect

Once the intrusion is confirmed, revoke every admin token, API key and session, not just the ones you know were used. Freeze Free-For-Teacher signups, throttle outbound data, and put admin settings, themes included, behind break-glass access.

4. Respond

Hunt for the whole bug class before saying "contained". Instructure fixed one XSS bug and missed a second, and the attacker was back through it in five days. Bring in forensics early, keep the logs, report to the ASD's ACSC, and have one person speak for the company.

5. Recover

Restore from backups taken before 25 April, rebuild login pages and themes from a known-good copy, and reset every admin and service credential. Bring services back in stages, least sensitive first, with monitoring turned up.

6. Learn

Run a blameless review within 30 days. Give every XSS fix a named owner and a deadline, and write what you learn into the runbooks and drills. Treat free-tier users as untrusted until they're verified.

What Instructure says it has changed

Reported. Instructure's incident page lists the changes it has made, mostly without dates. It has permanently discontinued Free-For-Teacher, restricted administrative access to trusted locations, locked down sensitive admin paths and tightened API access, rotated API keys and authentication tokens, and cycled all employee sessions and internal access tokens. It is also rolling out enforced token expiry and an end to lifetime tokens¹. Former Free-For-Teacher users were given two short windows, 28–29 May and 28–29 July, to download their materials¹.

Our analysis. Most of that list lines up with our Prepare and Protect phases. The page does not mention a Content Security Policy, and it describes fixing the vulnerabilities that were used rather than a sweep for the whole bug class.

The Australian side

Reported. Instructure is American, but a lot of the data wasn't. The University of Canberra said 25 universities in Australia and New Zealand were affected⁹. On 7 May the ABC reported that Queensland and Tasmanian state schools were affected, and that UTS, Sydney, Melbourne, Western Sydney, Newcastle and Flinders had issued statements saying they were aware of the incident¹⁰. The National Cyber Security Coordinator, Lt Gen Michelle McGuinness, coordinated the government's response and warned of a higher risk of scams and phishing aimed at students and staff^6,10.

Our analysis. If a company operating under Australian law had been in Instructure's position, these rules would apply:

• Notifiable Data Breaches scheme. Under the Privacy Act 1988, a suspected breach has to be assessed within 30 days. If it's likely to cause serious harm, the OAIC and the affected people must be told^11,12.
• Ransomware payment reporting. Since 30 May 2025, a business with turnover above $3 million that makes a payment, or gives any other benefit, in response to a cyber extortion demand must report it to the Australian Signals Directorate within 72 hours¹³. An "agreement" that involved a payment would count.
• Where students can complain. The OAIC's statement of 8 May, updated on 11 May, says affected people must first complain to Instructure or their school and allow 30 days for a response. Many public universities and state schools fall under state privacy law rather than the Privacy Act¹⁴.

Presenting it

"This project reignited my curiosity for cybersecurity. It confirmed that threat intelligence and building systems that hold up under attack is where I want to spend my engineering career."