The Instructure Canvas Breach (2026): How XSS in a Support Ticket Compromised 275 Million Students

A single support ticket became the front door to 275 million student records. The Canvas breach shows how quickly untrusted user content can become a serious security incident when it is rendered inside privileged internal tooling. This was not an exotic attack chain; it was stored XSS, over-scoped access, and a missing browser-enforced safety net. The fix is cheap. The consequences of ignoring it are not.

In April and May 2026, the cybercrime group ShinyHunters compromised Instructure's Canvas — the learning platform used by roughly 275 million students at 8,809 schools and universities worldwide — by exploiting a stored cross-site scripting (XSS) vulnerability in the free-tier support ticket system. A malicious file attached to a single help-desk ticket fired inside a Canvas employee's authenticated session when they opened it, handing the attacker cross-tenant API access to every paying institution on the platform. Canvas went offline mid-finals and during AP exams, an alleged $10 million ransom was reportedly paid, and both the US Congress and the US Department of Education opened inquiries. The architectural pattern that made this possible — unauthenticated user content rendered inside privileged admin tooling, on infrastructure shared between free and paying tenants — exists in most SaaS estates I've seen. The first line of defence is often just a single HTTP header.

A note before we start — what's confirmed and what isn't

Before I get into the details, I want to be clear about what I know and what I'm inferring, because the public record on this incident is uneven at best and I don't want to mislead.

What is confirmed, either by Instructure directly (their incident update page and their customer webinar) or via Phil Hill's coverage of that webinar at On EdTech, the "linked file with hidden code" phrasing, the April 22 → April 25 → April 28–30 timeline, the customer-service representative whose session was used to call Canvas's APIs, the second XSS in the discussion feature on May 7, the use of the custom-themes feature to deploy a CSS file, and the ~300-account defacement scope. The data categories exposed are also confirmed.

What I am inferring, and what you should treat as my reading rather than disclosed fact: the exact nature of the "linked file" payload (Instructure has not said whether it was an HTML attachment, an SVG, a document previewer exploit, or something else); the architectural claim that the help-desk rep's session had cross-tenant API reach (I feel this is the most plausible explanation for how a single rep's session led to data exfiltration across 8,809 institutions, but Instructure has not described their internal session model publicly that I can find); the specific privilege level the second XSS achieved; and obviously every claim I make about what a CSP would or wouldn't have stopped, which is an analytical argument rather than a counterfactual we can actually run. If you do happen to have the malicious payload, please let me know.

Where I speculate, I'll flag it and make it clear. Where I state something as fact, it's from the sources you can find at the end of the post. Now, let's dig in.

How did the Canvas breach actually happen?

Instructure has since done a customer webinar with their Chief Architect Zach Pendleton, their CISO Steve Proud, and CrowdStrike's Head of Incident Response James Perry. Between that, their incident update page, and Phil Hill's coverage at On EdTech, here's the timeline I can put together:

That's the whole chain. Two separate stored XSS bugs, one privileged session, one cross-tenant API surface, and one feature working as designed (custom themes) used as the final defacement primitive. ShinyHunters claim 3.65 TB of data and 8,809 institutions affected. Instructure reportedly settled.

How did the support ticket become an XSS vector?

This is the part that I think most people are missing in their coverage: the original vector was an XSS attack. Having an XSS vulnerability in your application is going to be bad even in the best of scenarios, but a help-desk ticketing system with an XSS vulnerability introduces some extra concerns.

1. The input is untrusted by definition. Anybody can open a ticket. In Canvas's case, anybody could open a Free-for-Teacher account — no institutional verification, no payment, no identity — and then open a ticket from inside that account.
2. The output is rendered in a privileged context. Support reps look at tickets all day, every day, in internal tooling that almost always has authenticated sessions to backend admin systems.
3. Those sessions are usually wider than any single customer. A customer-service rep needs to look at anybody's tickets, so their session typically carries authority across the estate — every tenant, every paying institution, every API. I want to flag that I'm inferring this part about Canvas specifically; Instructure has not publicly described the scope of their help-desk session model. But the outcome — a single rep's session leading to data exfiltration across thousands of institutions — I feel is difficult to explain any other way.

Combine those three and what you have is a cross-tenant privilege escalation primitive disguised as a help-desk form. The user is unauthenticated to your paying customers' data; the rep who opens their ticket is authenticated to (probably) all of it. The XSS vulnerability is the bridge.

We don't know exactly what the "linked file with hidden code" was. It feels like the phrasing is deliberately vague, and what follows is my own speculation, rather than disclosed fact. To my reading, it implies the payload wasn't simply HTML or JavaScript pasted into the ticket body — which would have hit Canvas's existing HTML sanitiser, canvas_sanitize. It was a file. Plausible candidates, in no particular order:

• An HTML or SVG file attachment, rendered inline in the ticket viewer without a sandboxed iframe.
• A linked URL whose contents got fetched and rendered as a preview by the help-desk UI.
• A document attachment processed by a previewer (Canvas uses Canvadocs / DocViewer for inline document previews; this code path has had CVEs before).

I want to be honest that this is informed guesswork. Instructure may yet publish more detail, and if they do I'll happily come back and correct this section. But whether it was one of these options or something else entirely, the lesson is the same and it's an old one: never render untrusted content in the same origin as your privileged tooling. If you absolutely must preview attachments inline, do it from a sandboxed origin that has no cookies for anything important. Document previewers, in particular, should live on a usercontent.example.com-style cookieless sibling domain, exactly the way Google Docs, GitHub user content or other SaaS products handle user-uploaded files.

How did the second XSS lead to the login portal defacement?

After Instructure plugged the support-ticket hole on April 30, ShinyHunters came back through a fresh XSS — this one in the discussion feature, which is exactly the user-generated-content surface you'd worry about in an LMS. Discussions in Canvas accept rich text, math equations, embedded media, and a long tail of the kind of HTML constructs that make sanitiser writers cry.

That, presumably, gave them administrator-level access again — Instructure hasn't spelled out exactly which privilege level the second XSS reached, but the subsequent abuse of an admin-only feature is consistent with admin sessions. Once they had that access, they didn't need another vulnerability for the defacement — they used the platform's intended administrator feature, "custom themes," to push a malicious CSS file out to login pages.

This is worth pausing on. The defacement itself was not exploiting a bug. It was exploiting a feature — one that exists because institutions want to brand their login pages. Once an attacker has admin-tier access, they have legitimate access to the customisation primitive. The XSS was just the route to admin.

So when we read that Canvas "pushed a CSS file through the custom themes feature," what's actually happening is: stored XSS in discussions → privileged session theft → legitimate themes API call → CSS deployed to ~300 login portals → ransom note visible to students opening the app during AP exams. The chain looks complicated; each individual step is mundane.

What would CSP have actually stopped?

This is the part that matters to me, and I get asked all the time whether CSP "would have stopped" some breach or another, and the honest answer is usually "it depends which part of the breach."

Caveat up front: this entire section is analytical. We don't know what Instructure's CSP posture was on the help-desk UI, the discussion-rendering pages, or the tenant login portals at the time of the incident. The claims below are about what a suitably strict CSP would have done in principle — not a critique of any specific policy Instructure may or may not have had in place. With that flagged, let's go stage by stage.

Stage one: the support-rep XSS. A strict, nonce-based CSP on Instructure's internal help-desk UI could very plausibly have broken this stage of the attack chain. The payload was running script — in the rep's authenticated session, which is the textbook thing CSP is designed to prevent. A policy along the lines of:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{random}';
  style-src 'self' 'nonce-{random}';
  object-src 'none';
  base-uri 'none';
  frame-ancestors 'none';
  report-to csp-endpoint;

…with no 'unsafe-inline' and no broad allow-listed hosts, leaves attacker-controlled inline script with nowhere to execute. Even if the attacker manages to inject a <script> tag through the sanitiser, the browser refuses to run it because it doesn't carry the nonce. The session theft never happens. The April 28–30 API pillage never happens. The breach is contained at the door.

Stage two: the discussion XSS. Same answer, broadly. A nonce-based script-src on the Canvas app surface that admins use would stop the second XSS reaching script execution in a privileged session. There's a wrinkle here — Canvas explicitly renders user-generated HTML, including math equations via MathJax, embedded media, and the rest — so a strict CSP for the student-facing rendering of discussions is genuinely hard. But for the admin-facing rendering of discussions, where session compromise has cross-tenant consequences, the trade-off is straightforward. Admin views of UGC should be sandboxed, protected by CSP, or both.

Stage three: the themes defacement. This one is more nuanced. The defacement was delivered as a CSS file via a legitimate administrator feature. CSP's style-src would not necessarily block a CSS file served from the application's own origin, because it was uploaded through the application's own admin tooling and served as a legitimate asset. The ransom banner — whatever inline script or DOM injection it used to render the message — would, however, hit the CSP wall if the policy was strict on script-src.

So CSP doesn't magically fix architectural mistakes about what privileged features can do. But it does break the chain at the point that matters most: the moment user-controlled script first runs in a privileged session.

Would SRI have helped? And what about CSP reporting?

Some of you are probably already reaching for the keyboard to ask about Subresource Integrity. SRI is brilliant when somebody compromises a third-party script CDN you're loading. This wasn't that. The malicious content here was first-party — uploaded into Instructure's own systems, served from Instructure's own origins. SRI was never going to help. This is also a useful distinction from the newer Integrity-Policy work: integrity controls are powerful for governing external script loading, but they are not a substitute for isolating user-generated content or preventing first-party XSS.

What would have helped — and this is the bit I find most painful — is CSP reporting. The Canvas attackers were in the rep's session for roughly four days before detection. Four days, with attacker-controlled script presumably making outbound API calls or fetching attacker resources from somewhere.

If Instructure had been running CSP in report-only or enforce mode on their help-desk UI, and pointing the reports at an aggregator (yes, like ours), the injection would have announced itself on day one. The loudest signal is the simplest: an injected inline script that doesn't carry the right nonce generates a violation report on every single page load — so from April 25 onwards, the help-desk UI would have been emitting a report every time that ticket was viewed. (Worth being precise here: the data exfiltration itself ran through Canvas's own first-party APIs, which are same-origin and wouldn't trip— CSP only reports violations. But the moment any stolen data was beaconed to attacker infrastructure, that off-origin fetch would have hit the policy and generated a report too.) The signal would have been screaming for four days before anyone looked.

This is the part of the CSP story that doesn't get told often enough. It isn't just a runtime block. It's a real-time integrity sensor for your application's execution environment. When somebody manages to inject content into pages they shouldn't, your CSP reports tell you in seconds. You don't need to wait for a CrowdStrike engagement and a forensic timeline to learn that something in the help-desk UI executed a script it shouldn't have. The browser, on every page load, is willing and ready to tell you.

We see this pattern at Report URI constantly. Customers who deploy CSP and pipe the reports somewhere they actually look at them catch injections — sometimes from contractors testing things in production, sometimes from compromised third parties, occasionally from genuine attacks — days or weeks before any other detection layer fires. The cost of getting that signal is the cost of a CSP header and an endpoint to send reports to.

What's the architectural lesson from the Canvas breach?

If I had to compress this entire incident into one sentence, it would be this: the support ticket is the back door to your admin console, and your admin console is the front door to every customer.

Free-tier programs are wonderful for adoption. Instructure's Free-for-Teacher was almost certainly responsible for a meaningful chunk of Canvas's eventual institutional uptake — teachers who tried it in a personal capacity, then advocated for it when their districts went shopping. Shutting it down, as Instructure has now done, is a real product loss.

But Free-for-Teacher sat on shared infrastructure with paying tenants. The trust boundary between "anonymous member of the public who signed up with a Gmail address ten minutes ago" and "regulated student data at 9,000 institutions" was a sanitiser, a support-ticket renderer, and a session cookie scope. That's a thin boundary to ask three pieces of code to hold up.

The fix is not to abandon free tiers. The fix is to render untrusted user content in places that don't matter when they get compromised. Cookieless sandbox origins. Sandboxed iframes with no allow-same-origin. Help-desk tooling that doesn't carry production session cookies. Cross-tenant API access that requires re-authentication, not just session presence. And on top of all of it, a CSP that turns "an attacker just executed script in my admin UI" from a four-day silent breach into a notification you get before your coffee goes cold.

Canvas is back online. The students caught up. The data, allegedly, has been destroyed. But the underlying architectural pattern — untrusted user content rendered in privileged origins — is sitting in more SaaS products than I can count. Most of you reading this probably have it in your stack right now.

The good news is that the defence is cheap. The bad news is that the people who need it most are usually the ones who think it doesn't apply to them.

Don't be the next case study.

So what should teams do tomorrow?

The uncomfortable lesson here is that this pattern is probably already present somewhere in your own estate. Most SaaS products have places where untrusted user content is rendered for trusted staff: support tickets, file previews, customer messages, admin notes, imports, exports, themes, templates, comments, invoices, logs, or uploaded attachments. The options are plenty, so start by finding those places.

Ask a simple question for each one: can attacker-controlled content execute in a browser session that has more privilege than the attacker does? If the answer is yes, you have a problem worth fixing quickly.

The immediate review list is short:

1. Identify every internal or admin surface that renders customer-supplied HTML, Markdown, files, images, SVGs, PDFs, CSS, templates, or rich text.
2. Check whether those surfaces share an origin, cookies, or session context with privileged staff tools.
3. Move risky rendering to a separate, sandboxed origin with no access to admin cookies or production APIs.
4. Apply a strict CSP in enforce mode, not just report-only, especially on support, admin, and moderation tooling.
5. Require re-authentication, step-up verification, or explicit approval before staff sessions can perform sensitive cross-tenant actions.
6. Review whether support/admin roles have broader API access than they actually need.
7. Monitor CSP, failed isolation, and suspicious API activity as production security telemetry, not as passive logs nobody reads.

The goal is not just to "fix XSS". The goal is to make sure that when XSS inevitably appears somewhere, it cannot jump from a low-privilege customer-controlled surface into a high-privilege employee session with access to everyone’s data.

Sources

Primary sources from Instructure:
Instructure — Security Incident Update & FAQs — the official statement, including the line confirming "a vulnerability regarding support tickets in our Free for Teacher environment that was exploited."
Instructure — Customer Webinar: Technical Deep Dive on Recent Security Incident — the May 18–19 webinar with Chief Architect Zach Pendleton, CISO Steve Proud, and CrowdStrike's Head of Incident Response James Perry.

Phil Hill's coverage at On EdTech, which is the cleanest public summary of what Instructure disclosed in the webinar:
Phil Hill — A Technical Deep Dive Is Not a Crisis Response — the source of the verbatim chain (support ticket on April 22, rep session theft on April 25, API exfiltration April 28–30, second XSS in discussions, themes CSS pivot to ~300 accounts on May 7).
Phil Hill — Instructure Is Risking the Trust That Built Canvas
Phil Hill — One Step Forward, One Step Back

Mainstream press coverage of the incident:
BleepingComputer — Instructure confirms hackers used Canvas flaw to deface portals
BleepingComputer — Canvas login portals hacked in mass ShinyHunters extortion campaign
BleepingComputer — Instructure reaches 'agreement' with ShinyHunters to stop data leak
TechCrunch — Hackers deface school login pages after claiming another Instructure hack
The Register — Congress investigates Canvas breach after Instructure cuts deal with ShinyHunters
The Hacker News — Instructure Reaches Ransom Agreement with ShinyHunters
Malwarebytes — ShinyHunters escalates Canvas attacks with school login defacements

Government and regulatory:
US Department of Education — Federal Student Aid security alert, May 12 2026

Vendor analysis:
Bitdefender — Technical Advisory: ShinyHunters Breach of Instructure Canvas LMS
Trend Micro — What Is the Instructure Canvas Breach?
AI Learn Insights — What Can We Infer from Canvas's Technical Deep Dive?

Technical references mentioned in the article:
Canvas LMS on GitHub — the open-source codebase, including the canvas_sanitize gem responsible for HTML sanitisation.
canvas_sanitize gem source — the allowlist-based HTML sanitiser referenced when discussing the difficulty of inline-HTML injection paths.
CVE-2021-36539 — a prior Canvas vulnerability in the DocViewer / canvadoc_session_url code path, illustrating the document-previewer angle.

Prior art — historical Canvas XSS research (separate from the 2026 incident, but illustrative of the recurring UGC-rendering pattern):
andrew-healey/canvas-lms-vuln — Rich Content Editor XSS via outdated jQuery and a broken image handler.
andrew-healey/example-canvas-xss-attack — MathJax \phantom{\unicode{...}} bypass via the math-equation insertion path in discussions, journals and assignments.

Wikipedia (timeline reference only):
2026 Canvas security incident — Wikipedia