Inside the 2026 Canvas breach

Originally published at amansinghnp.com.

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 [1]. The first hole had been closed. A second one, in the discussions feature, was still open [1].

For UTS Tech Fest 2026, two teammates and I took the incident apart. UTS was among the universities that issued statements about it [10], 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.

How to read this

• Claimed. Said by ShinyHunters, the group behind the attack, and not confirmed by Instructure.
• Reported. Stated by Instructure, a government body or a named publication, with the source cited. Instructure's statements are its own account, not an independent finding.
• Our analysis. Our reading, reconstruction or recommendation. The ATT&CK mapping and the response plan are ours, not Instructure's.

275M users' data, claimed

8,809 institutions, reported

3.65 TB of data, claimed

~300 organisations shown the ransom note, reported

5 days from "contained" to back in, reported dates

25 AU and NZ universities hit, reported

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 [4].

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 [1]. 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 [1].

The ransom note from 7 May, with the deadline pushed to 12 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 [6]. A proposed class action was filed in the US District Court for the Southern District of California on 13 May [4].

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 [1]. A figure of US$10 million has circulated only as an unconfirmed rumour [4].

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 [1]. 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 [2].

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" [3]. 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 [1].

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 [1]. 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 [1].

What ShinyHunters claimed

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

Our reconstruction of the attack chain from the reported dates. The 275M figure is ShinyHunters' claim. Instructure called it contained on 2 May; five days later the attacker came back through a second XSS bug.

Day by day

The Source column says whose account each row rests on. The technique IDs are our mapping to MITRE ATT&CK Enterprise [7], 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 [2].
• 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" [3].
• One token was enough. A single token lifted from a browser gave elevated access inside Canvas [1]. On Reuters' count, data from 8,809 institutions followed [4].
• "Contained" before the bug class was fixed. The first XSS bug was closed. A second one, in discussions, was not [1]. 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 [3].

What we'd have done

Our analysis. We built our plan on the ACSC's incident response guidance [8] 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.

Our response plan as a loop. Lessons from the last phase feed back into preparation.

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 [1]. Former Free-For-Teacher users were given two short windows, 28–29 May and 28–29 July, to download their materials [1].

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 [9]. 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 [10]. 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 [13]. 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 [14].

Presenting it

Our timeline slide.

Our response plan slide.

"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."

One support ticket from a free account opened the way to what ShinyHunters claims is 275 million users' data, and a fix declared too early let them back in. A breach is a chain, and you stop it at the weakest link.

Sources

1. Instructure. Security incident update and FAQs for customers. Most entries undated; dated status updates on 20 May and 27 July 2026. instructure.com
2. Bitdefender. Technical advisory: ShinyHunters breach of Instructure Canvas LMS. 8 May 2026. businessinsights.bitdefender.com
3. Helme, S. The Instructure Canvas breach (2026): how XSS in a support ticket compromised 275 million students. 15 June 2026. scotthelme.ghost.io
4. Wikipedia. 2026 Canvas data breach. en.wikipedia.org
5. Malwarebytes. ShinyHunters escalates Canvas attacks with school login defacements. 8 May 2026. malwarebytes.com
6. Information Age (ACS). Canvas breach: "agreement" reached with hackers over stolen data. 12 May 2026. ia.acs.org.au
7. MITRE. ATT&CK Enterprise matrix. attack.mitre.org
8. Australian Signals Directorate. Cybersecurity incident response planning: practitioner guidance. December 2024. cyber.gov.au
9. University of Canberra. Australia-wide Canvas learning management platform breach. 6 May 2026. canberra.edu.au
10. ABC News. Canvas data breach leaves education providers scrambling as student data compromised. 7 May 2026, updated the same day. abc.net.au
11. Privacy Act 1988 (Cth), Part IIIC. legislation.gov.au
12. OAIC. About the Notifiable Data Breaches scheme. oaic.gov.au
13. MinterEllison. Mandatory ransomware payment reporting obligations now in force. 16 June 2025. minterellison.com
14. OAIC. Statement on Instructure (Canvas) cyber incident. 8 May 2026, updated 11 May 2026. oaic.gov.au

---

This article was first published at amansinghnp.com.