What Can We Infer from Canvas's Technical Deep Dive?
Phil Hill's recent reporting on the Canvas security incidents includes a “technical deep dive” from Instructure. Two paragraphs stand out for what they reveal about Instructure’s technical architecture.
On the exploits:
“Both recent hacking events originated from the Free-for-Teacher tier, and both relied on stored cross-site scripting payloads (a linked file with hidden code) submitted via support tickets. The April 22 payload sat dormant until April 25, when a customer service representative opened the ticket; the code then executed in the rep’s authenticated session and the threat actor used those elevated privileges to obtain data via Canvas’s APIs between April 28 and April 30. Instructure detected the activity on April 29 and revoked access by April 30. The May 7 event was a second cross-site scripting vulnerability — this one in the Canvas discussion feature — exploited via a different code path and used to push a CSS file through the custom themes feature, deploying the ransom note to roughly 300 accounts before Canvas was placed in maintenance mode that afternoon.”
And on the response:
“The remediation was organized into three tiers — access and authentication hardening (additional multi-factor authentication checkpoints, disabling OAuth token generation via JavaScript, an Okta reauthentication framework for customer-account access), platform and web security controls (the cross-site scripting fixes and consolidated sanitization), and threat detection (CrowdStrike Falcon across the Canvas platform, behavioral alerting tied to the specific tactics observed). Free-for-Teacher is being reinstated in what Proud called a “secure limited capacity” with all administrative and support functionality stripped out.”
An Analogy, for the Rest of Us
A caveat before going further: I’m not a security expert, and I’m working only from what’s described in these paragraphs. I could be reading too much into the wording, missing context that would change the picture, or drawing inferences that someone closer to the system would disagree with.
What follows is one reading, offered in that spirit.
To make sense of what actually happened, it helps to set the technical vocabulary aside for a moment.
Imagine a school district office where one receptionist holds a master key that opens every classroom, filing cabinet, and student record across every school in the district.
Now imagine a suggestion box on the receptionist’s desk. Anyone can drop a note in it. But this office has a strange rule: when the receptionist reads a note, whatever it says to do gets done automatically, using her master key.
That’s the first attack. Someone slipped in a note that read “go copy these student files and leave them in the alley out back where I can pick them up.” When the receptionist opened the note three days later, an eager intern standing nearby grabbed her master key, went and did exactly that — and nobody noticed for days.
The second attack used a different channel: a public bulletin board in the hallway, where parents, visitors, students, and teachers all pass by and read what’s been pinned up. The same strange rule applied here as at the suggestion box — when someone read a notice, hidden instructions on it were silently carried out using that reader’s own authority, whatever it happened to be.
The attacker pinned a notice on the board. Every time a teacher or administrator walked by and read it, the building quietly used that person’s normal privileges to do something on the attacker’s behalf. One of those normal privileges was the ability to customize the posters in their own school’s hallways. The hidden instruction said: “use this person’s poster-hanging access to put up this poster” And the poster was a ransom note.
The district had assumed that “letting a school customize its posters” was a small, contained privilege. It wasn’t. Each time the notice was read by someone with poster-hanging access, another school got the ransom note in its hallway. Roughly 300 schools were hit before anyone shut the bulletin board down.
What structural vulnerabilities are revealed in these exploits?
One key opens everything. A front desk receptionist has the master key to every classroom, filing cabinet, and student record in the district. And that master key could be used automatically by someone placing a note in a suggestion box.
Local permission, district-wide reach. A school was allowed to hang a poster in its own hallway. Somehow that permission translated into the ability to hang the same poster in every hallway in every school across the district.
And the poster itself wasn’t really a poster. A poster turned out to be a vehicle that could carry instructions — the same problem as the suggestion box, just in a different channel.
Nobody was watching the keyring — and there may not even be a way to. The master key was used for days before anyone noticed. But the deeper question is whether there was a reliable audit mechanism to track when the key was used, by whom, and for what. If the logs exist but no one is watching them, that’s one problem. If the logs themselves are incomplete or absent, that’s a much bigger one.
From Analogy Back to Architecture
Let’s translate the analogy now back to the system architecture.
Session-based trust is doing too much work. A support representative’s authenticated session appears to have been sufficient, at least along this exploit path, to access customer data through Canvas’s APIs. That is the master key in technical form. The incident suggests that step-up authentication, per-action authorization, and separation between “viewing a support ticket” and “calling production APIs against customer tenants” were either missing, incomplete, or ineffective. Once the session existed, too much privilege came along for the ride.
Untrusted content was not meaningfully isolated from privileged contexts. Stored cross-site scripting executed in a privileged context twice, through two different features — first support tickets, then discussion forums. That means content submitted by untrusted users could cross into interfaces used by trusted staff or authenticated users.
The custom themes feature functioned as a broad client-side delivery channel. Pushing a CSS file through the themes feature to deploy a ransom note to roughly 300 accounts means “theme” was not merely visual decoration. In practice, it had the reach of a tenant-wide publishing mechanism. If that mechanism lacked adequate review, signing, scoping, or constraints on where and how theme assets could be applied, then a customization feature became a broadcast channel.
Tenant boundaries appear weaker than they should be for privileged internal access. One compromised internal session was apparently enough to pull data across customer accounts via API. In a stronger model, even privileged support access would be scoped by tenant, purpose, case, time, and action. Internal users would not carry broad standing authority by default. Here, tenancy appears to have depended too heavily on application-level checks inside a session that could itself be compromised.
Detection lagged exploitation. The April timeline is telling: payload planted April 22, triggered April 25, exfiltration April 28–30, detected April 29. Several days passed between planting, execution, and full revocation. That suggests either the telemetry was not being collected in a way that made the activity visible quickly, or it was being collected but not tied to behavioral baselines strong enough to flag unusual API activity from a support context.
The common thread across all five is that identity is too coarse, content boundaries too porous, customization features too powerful, tenant scoping too dependent on trusted sessions, and monitoring too reactive. A single session carried too much authority. Untrusted input reached trusted contexts. A theme feature became a broadcast mechanism. And detection caught the attack late in the cycle rather than stopping the behavior at the moment it became abnormal.
Mitigation: Three Parallel Tracks
If this analysis is broadly correct, Instructure’s mitigation will need to occur on parallel tracks, not in sequence. To keep the school analogy going, think of these as three different kinds of work the district has to do at the same time.
Short term: stop the bleeding. This is the equivalent of changing the locks the burglar used, putting up cameras at the doors they came through, and telling the receptionist she now has to show ID at multiple checkpoints before her keyring works. The objective is to close the specific exploit paths that have already been used and to make it harder for the same attack to work tomorrow. This is the work largely captured in Instructure’s three-tier remediation: patching the bugs, consolidating how user input is screened, adding multi-factor checkpoints, requiring fresh sign-ins for sensitive access, and installing monitoring software. The goal at best is containment, not transformation. It buys time and it only addresses the known exploits.
Medium term: reduce the blast radius. This is the equivalent of taking away the master key and replacing it with a system where the receptionist has to request, in the moment, a single key to a single room for a specific reason — and only for as long as she needs it. The objective is to ensure that if something like this happens again — and something like it always eventually does — the damage is far smaller. That means narrowing what a compromised internal account can actually reach, tightening what customization features like themes are allowed to deliver and where, and watching internal activity closely enough that anything unusual gets noticed in hours rather than days.
Long term: rebuild the foundations. This acknowledges that the entire building was designed under older security assumptions, and that no amount of new locks and cameras can fully compensate for a floor plan that puts the safe next to the suggestion box. The objective is to move security from something bolted onto the application to something built into the platform’s foundations. That means treating identity, access control, tenant separation, and the handling of untrusted content as infrastructure: specialized systems, professionally maintained and externally audited, rather than application code accumulated feature by feature over many years. This is a multi-quarter effort at minimum, and probably a multi-year modernization program. The test of whether it has been done correctly is whether the next incident, whenever it comes, reveals a fundamentally different building or just a more heavily guarded version of the same one.
The risk in moments like this is that the short-term work creates the appearance of resolution and the medium- and long-term work quietly slips. The visible fixes ship, customers are reassured, and the architectural questions get deferred to next year, and then the year after that.
The Verdict
Instructure will be very busy the next couple of years overhauling its security architecture. But the work doesn't stop at the vendor. Customers — districts, universities, and the institutional administrators who manage Canvas accounts — will need to do their own corresponding work: reviewing how they integrate with Canvas, tightening their own identity and access configurations, auditing the permissions they grant to third-party tools, and aligning their internal security practices with whatever new controls Instructure rolls out. A vendor can rebuild its foundations, but customers have to update their own buildings to connect to the new ones. Both sides have homework.