On the Canvas hack
Posted May 7, 2026.
Instructure's LMS Canvas has been compromised, leading to an extended outage. This post discusses the implications for students, lists out the institutions named, and discusses a technical attack vector.
I'm a student, how does this affect me?
Your instructors should be willing to work with you to accomodate for disruption to your studies. You were not responsible for this incident and they were also unable to access Canvas.
Do I need to change my password?
It couldn't hurt. The attackers could have inserted malicious phishing code on the frontend to steal your credentials if you typed them in.
Authentication to Canvas usually happens on campus servers and not on Instructure's platform, so passwords are not believed to be at risk. You typically login to your school's single sign-on (SSO) service. Then you're redirected to Canvas on (compromised) Instructure servers.
What happens next?
Anticipate an increase in phishing and targeted scams that make use of the leaked information. Attackers might craft convincing emails relating to classes you are taking e.g. extra credit opportunities, grades, etc. LLMs will greatly improve the ease and scale of these attacks.
What data may have been compromised?
- Names of students and instructors
- Email addresses
- Student IDs
- Course enrollment information
- Content on Canvas such as messages
If you have submitted sensitive information to Canvas, make preparations for the information becoming public.
Did Instructure pay the ransom?
The Incident update page says that Instructure "reached an agreement" with the attackers. There was no mention of a ransom or amount paid.
Who is affected?
The attackers named over 8,000 institutions in a text file. You can search through it below. (check here if it doesn't load).
Who is behind the attack?
The ransom message (cleaned for malware) attributes the attack to the ShinyHunters black-hat group. The IP address provided, 91.215.85.103, belongs to a Russian hosting provider known for ignoring requests to take down malware and phishing. The web server also hosts past leaks by ShinyHunters.
The attackers' site on the dark web appeared to link to the downloadable leaks hosted on the normal web. It expresses that targeted organizations must pay the ransom or face disclosure of the data to other cybercriminal groups.
How did the breach occur?
The specifics remain undisclosed, but an article by Sean Nikkel of BitDefender lays out two likely techniques:
- Vishing and social engineering to gain priveleged credentials and access (typical ShinyHunters M.O.)
- Privelege escalation through the Free-For-Teacher system and compromise due to improper isolation of Canvas instances
What Instructure has said
The incident update page says that the exploit was via "support tickets in our Free for Teacher environment". Free for Teacher is Canvas's program allowing anyone to create their own Canvas instance for free.
Instructure has released a changelog of UX updates in response to the incident. Here's a quick summary.
Changes made before the May 7 defacement:
- Better enforce external SSO before taking admin actions e.g. themes, CSP
- Stop GraphQL clients from reading all enrollment IDs in a course
- Improve sanitization of inputs in Canvas's built in rich text editor
After May 7:
- Reenable HTML input in the rich text editor
- Disable account self-registration
- Gate third party apps' developer key management behind SSO
- Disallow the use of client-side JavaScript to accept OAuth permissions
- Discourage bypassing browser-based authentication by restricting out-of-band redirect URLs
- Stop showing API secrets on the frontend but allow them to be rotated more easily
The changes having to do with HTML sanitization, CSP, and JavaScript seem to imply XSS. This allows attackers to inject malicious JS into browser sessions. OAuth and third-party Canvas API clients are another common theme. Of note,
- By default, developer keys are unscoped and match the permissions of the issuing account
- Instructure employees can configure developer keys on customer instances
One possible series of events
- Attackers notice improper sanitization of support tickets and submit tickets containing malicious JS
- Instructure support staff view the tickets and run malicious JavaScript, allowing the attackers to hijack their sessions
- To persist their access, attackers use Instructure staff's sessions to create or steal developer keys with full access to all Canvas instances
- Attackers use these keys to exfiltrate data using GraphQL, which allows batching massive queries with fewer requests
- After Instructure fails to patch the XSS issue, attackers use Theme Editor to post their ransom note across different campuses (discussed further below)
This seems to hit the major points discussed in the changelog, but because those changes are described as "precautionary", it's possible that not all were directly relevant to the attack.
Confusingly, the changelog itself was updated.
- A new Root Account setting has been added to designate an "Elevated Auth Provider." When enabled, a user attempting to make admin actions must be authenticated through the selected auth provider, or the request will fail.
+ A setting designates an Elevated Auth Provider for Instructure employees. When enabled, Instructure’s actions require the user to be authenticated through the selected provider. Requests from users authenticated through any other provider will fail.
The changelog also frequently states "This change impacts Instructure employees. The setting is configured by Instructure engineers and is not currently available to Canvas administrators.", implying that Instructure employees' administrative permissions could have been abused in the attack.
What we saw on Thursday
On May 7 at around 13:00 PST, UCSD's Canvas page was defaced. The attackers' message was included in a CSS file. It seems to have been inserted through Theme Editor. Because the mobile clients don't apply custom styles, they functioned until Instructure shut down the service for "scheduled maintenance".
Instructure's response page says "the same issue that led to the unauthorized access the prior week". This leads us to believe that Canvas's initial response involved revoking malicious API keys but overlooked the original support tickets issue.
What are people saying?
Our alumnus Gowtham has posted some thoughts here. Other users report discovering vulnerabilities in Canvas before the breach.