In April 2026 a support ticket became the way into Canvas, the learning platform used by roughly 275 million students at 8,809 institutions. Our founder published a full analysis of the breach, and this page is the short version of why it happened the way it did.
The mechanism is worth understanding even if you have never touched an education platform, because the architecture behind it is extremely common.
Four days
On 22 April a user of the free tier filed a support ticket containing, in Instructure's own phrasing, “a linked file with hidden code”. On 25 April a customer service representative opened it, and the payload executed inside their authenticated session. Between 28 and 30 April that session was used to call Canvas APIs and pull data out.
Instructure noticed unusual API activity on 29 April and revoked the session on the 30th — four days after the payload fired. On 7 May a second stored cross-site scripting flaw was found in the discussions feature, this time granting administrative access, which was used to push malicious CSS to the login portals of around 300 schools through the legitimate custom-themes feature. Canvas went offline that evening, in the middle of finals.
The reported scope is usernames, email addresses, course names, enrolment information and in-product messages. The actor is ShinyHunters, who claimed 3.65 TB of data and, according to reporting, sought a ransom of around $10 million — both figures are the attacker's and reporting's rather than Instructure's. Instructure has said an agreement was reached, which is not the same as saying the data was destroyed.
Three conditions, and you need all three
The vulnerability alone would have been an incident report. What made it a breach was the combination underneath it:
First, untrusted input from unauthenticated free-tier accounts — anyone could file a ticket. Second, that input rendered in privileged internal tooling carrying production session cookies. Third, sessions with cross-tenant API reach spanning all 8,809 institutions.
Remove any one of those and the story ends early. That is also the checklist worth running against your own estate, because most organisations have all three and have never drawn the line between them.
The support ticket is the back door to your admin console, and your admin console is the front door to every customer.
The file, not the markup
The exact injection route has not been confirmed by Instructure. The analysis sets out the plausible ones — an HTML or SVG attachment rendered without sandboxing, a linked URL whose contents were previewed, a document passed through Canvas's viewer — and deliberately does not pick between them.
What is worth taking from it is the shape. The payload arrived as a file, not as inline markup in the ticket body. There is precedent: in 2023, Roundcube failed to sanitise SVG files carried inside HTML messages, so a crafted SVG became JavaScript in the reader's session. Two unrelated products, both sanitising the markup they expected, both missing the file attached to it.
What a policy would and would not have done
Stage one, the support ticket: the script would not have executed. It carries no nonce on any of the routes above, so the representative's session is never stolen.
Stage two, the discussions flaw: it would not have executed for the same reason, which also removes the privilege escalation that followed.
Stage three, the defacement of school login portals: not blocked, and it is worth conceding that plainly. The CSS was uploaded through legitimate admin tooling and served from the application's own origin, which a style-src directive has no reason to refuse. Any inline script rendering a ransom message would have hit script-src, but the CSS defacement itself is not a CSP win.
A nonce-based policy is what breaks this chain. With script-src 'self' 'nonce-{random}' and no 'unsafe-inline', an injected script carries no nonce, so the browser refuses to run it — and the session it was reaching for is never taken. It does not matter which field the payload arrived in or which bug let it through.
And then the part this page exists for. Had Canvas been running that policy in report-only on the help-desk interface and sending the reports somewhere, the injection would have announced itself on day one rather than being inferred from API traffic on day four. An inline script with no nonce is the loudest and simplest signal a browser can give you.
How we can help
The policy is the mitigation and the reporting is the detection, and it is the second half almost nobody switches on. Run CSP in report-only across the internal tools where untrusted content gets rendered, and an injected inline script announces itself the first time it fires — from the real session it fired in, with the page it fired on.
One line of code or config to deploy, and nothing is blocked while you learn what the policy would have caught. Reach out to sales@report-uri.com for a demo or a trial with no commitment.
