| Update: June 22, 2026 What We Know about the Canvas Breach On May 11, Instructure said it would release a report explaining the cause of the Canvas breach and what it learned. As of June 22, the report is still not available. The company’s incident update page says it “intends to share additional details about the root cause and lessons learned,” but there is no timeline yet. 1 The U.S. House Committee on Homeland Security asked Instructure CEO Steve Daly for a closed-door briefing by May 21, 2026. There has been no public disclosure as to whether that meeting was held or what was discussed. 2 Instructure confirmed that the exploit was linked to its Free-For-Teacher (FFT) account program. BleepingComputer reported that ShinyHunters injected malicious JavaScript by exploiting cross-site scripting flaws in user-generated content features, which gave attackers access to authenticated admin sessions. Instructure has not confirmed these technical details in a public report, but has since permanently shut down the FFT program. 3 What ShinyHunters Has Done Since ShinyHunters continued their activity after the Canvas breach. From May 27 to June 9, they reportedly exploited CVE-2026-35273, a zero-day vulnerability in Oracle PeopleSoft, across more than 100 organizations and 300 systems. Google and Mandiant say about 68% of those affected are in higher education. Oracle released a security alert on June 10, but it is still unclear if all systems have been patched. 4 On June 10, 2026, the University of Nottingham confirmed a breach. Data from about 454,600 current and former students, including personal and academic records, was stolen and posted on ShinyHunters’ data leak site.5 These incidents all raise the same questions: how far can an attacker move, and would you notice? Without a formal root-cause report, institutions have to make these assessments without all the facts. Each institution is still responsible for understanding its own risks, no matter what Instructure has shared. Proactive assessments can help answer these questions before someone else does. Update: May 15, 2026 Significant developments have emerged since this post was originally published on May 11. We’ve summarized the key updates below. Instructure likely paid the ransom. On May 11, Instructure confirmed it reached an agreement with the threat actor, one day before the attackers’ May 12 deadline. The agreement reportedly included the return of stolen data, digital shred logs confirming its destruction, and a commitment from the attackers not to extort individual institutions. Instructure’s statement advised customers not to engage with the criminals directly. Independent analysts say the agreement likely involved paying a ransom, though Instructure has not publicly confirmed a payment or disclosed an amount. Legal experts are urging institutions to treat these assurances with skepticism because shred logs are unenforceable. There is no way to verify that all copies of the data were eliminated, and cybercriminals regularly retain or resell stolen data regardless of agreements. Paying the ransom also doesn’t eliminate notification obligations under state or federal law. The confirmed scope of compromised data. Instructure has clarified that the data accessed included usernames, email addresses, course names, enrollment information, and messages. Core learning content, submissions, and credentials were not affected. CrowdStrike independently verified that there was no system-level access, malware installation, or additional data extraction during the May 7 defacement attack. Parchment, Instructure’s digital transcript service, operates on distinct servers and was confirmed unaffected. Some messages between students and instructors were compromised. Legal advisers are specifically flagging that those messages may include accommodation requests, harassment complaints, and other sensitive communications, and that institutions should treat Instructure’s scope statements as preliminary until the forensic review is complete. Congressional investigation opened. The U.S. House Committee on Homeland Security sent a letter to Instructure on May 11 requesting a comprehensive briefing on how the breach occurred, what data was accessed, and how the company responded. The letter specifically noted that the same threat actor breached Instructure twice within a week and that the second intrusion defaced login pages across at least eleven states. More than two dozen lawsuits filed. As of mid-May, more than two dozen lawsuits have been filed against Instructure, alleging negligence and unjust enrichment. Plaintiffs argue the breach disrupted exams and that sensitive communications including accommodation requests and harassment complaints may have been exposed. Attorneys advising universities are noting that paying the ransom doesn’t satisfy legal or regulatory notification requirements, and institutions should review insurance coverage and prepare for litigation regardless of Instructure’s agreement with the attackers. Guidance from regulators. The Federal Trade Commission published a consumer alert advising users to avoid clicking suspicious messages, monitor credit reports, and contact IdentityTheft.gov if they suspect their personal information is being misused. Universities including Grand Rapids Community College and the University of Washington have informed their communities that there is no evidence of passwords, dates of birth, government identifiers, or financial data being exposed, but recommend resetting passwords and remaining vigilant against phishing. We’ll continue to update this post as Instructure’s forensic review progresses. The root-cause details the company has committed to sharing are not yet public. When they are, we’ll add them here. |
This past week, a ShinyHunters-linked compromise of the Canvas Platform operated by Instructure disrupted universities including Harvard, Columbia, Princeton, Georgetown, along with hundreds of other educational institutions worldwide, with attackers reportedly altering user-facing Canvas pages as part of an extortion campaign. With more than 100 million users globally, and attacker claims referenced roughly 8,000 to 9,000 institutions, though Instructure’s confirmed scope is narrower, this is a significant event. The incident underscores the systemic risk created by widely adopted third-party platforms across the education sector.
After years of assessing complex, interconnected environments, we’ve noticed that the weakest point is almost always the inherent trust between entities such as a Software as a Service (SaaS) and their customers.
Evaluating SaaS platforms like Instructure’s Canvas and their integration into your network and operational processes is crucial for identifying potential risks within these connections. As a Learning Management System (LMS), Canvas often connects with research platforms, cloud services, and student information systems. These integrations require broad access across environments that institutions inherently trust.
However, over time, convenience overrides verification. Shared accounts Shared accounts proliferate, MFA enforcement weakens across organizational boundaries, and service account credentials remain unchanged for years. When a vendor is compromised, those assumptions create direct attack paths into trusted environments.
The Canvas breach demonstrates how quickly those trusted connections can become operational risk at scale.
This isn’t the first time ShinyHunters breached Instructure. In September 2025, they accessed Instructure’s Salesforce through social engineering. Instructure changed credentials, declared it contained, and moved on. Eight months later, the group returned. On May 1, Instructure reported another incident, called it contained by May 2, but by May 7, Canvas portals tied to schools and universities displayed ransom messages. The real lesson isn’t about ShinyHunters’ skills, it’s about what happens when a breach response only addresses credentials and vulnerabilities, not the root exposure.
ShinyHunters claimed access to hundreds of millions of records including private messages, student IDs, names, and email addresses from nearly 9,000 institutions. Instructure confirmed that names, email addresses, student IDs, and user messages were involved, though the full extent isn’t independently verified. The important point is that attackers didn’t need to breach each university; they only had to breach the one vendor everyone trusted.
There’s another risk to highlight. While institutions deal with the disruption, students are locked out during finals and professors are moving course materials, creating ideal conditions for phishing campaigns impersonating Canvas, Instructure, or university IT, offering to restore access. At least one major university had to warn its community about fake messages within hours. A vendor breach doesn’t end when the platform is restored. It creates confusion that attackers quickly exploit, making your users easy targets. The following is a high-level summary and chronological visualization detailing the key milestones of the recent security breach.
Attackers target Higher Education for good reason. Universities store student records, research, financial, and sometimes patient health data. Their IT environments are decentralized, spanning many departments and partners, with large, changing user groups and vendor networks that grow faster than security teams can manage.
ShinyHunters didn’t just go after Instructure. In late 2025 and early 2026, ShinyHunters-linked activity reportedly impacted institutions including the University of Pennsylvania, Harvard, and Princeton directly. The Canvas incident isn’t a one-off event. It’s part of a sustained campaign by a group that understands exactly how interconnected the higher education ecosystem is and knows how to exploit that at scale.
Campuses also manage complex payment systems for dining, bookstores, tuition, and stadiums. We’ve discussed before how annual PCI DSS penetration tests are often treated as a formality, even though the risks are high. Both vendor trust and payment security issues stem from assuming that controls put in place once will always work. Usually, they don’t, and the only way to know is to test them.
Regardless of existing vendor agreements, institutions should immediately pressure-test these questions, which form the core of our penetration tests targeting third-party risk and supply chain vulnerabilities.
What access does each major vendor really have?
Not just what your records say, but what they have right now at the system level. This includes shared accounts, VPN access, shared apps, and cloud resources. Do you have an up-to-date view of every connected platform, the credentials they use, and what they can reach? Most institutions can answer this for their top vendors, but not for the many smaller platforms.
How do you monitor that access?
Giving a vendor access is one thing, but regularly monitoring their activity is another. Most institutions grant access but don’t keep track of what vendors do. This gap makes third-party breaches hard to detect early.
What happens if a vendor is breached?
If Canvas or another key system is compromised, what could an attacker access in your environment? Can they move between systems or reach sensitive data like PHI or PII shared with partners? Do you know the answer, or are you just assuming?
Who is responsible for notifications?
Instructure reported a cybersecurity incident on May 1 and said it was contained by May 2, but by May 7, Canvas portals tied to universities displayed ransom messages. What does your vendor’s breach notification policy actually require, and is that timeline enough for you to respond?
When was the last time you tested these boundaries?
Has anyone on your team simulated what an attacker could do with vendor access or a compromised account inside a trusted network? If you don’t know, that’s your answer.
September 2025
Salesforce-related compromise reportedly linked to social engineering.
Instructure responds
Instructure rotates credentials and states incident is contained.
April 30, 2026
Unauthorized access activity detected. Investigation begins.
May 1, 2026
Unauthorized intrusion confirmed. Law enforcement engaged.
May 2, 2026
Instructure again states the incident is contained.
May 3, 2026
ShinyHunters posts Instructure on leak site. Attackers claim 275M records from ~8,800 institutions.
May 7, 2026
Canvas portals tied to universities and school systems worldwide display ransom messages. May 12 extortion deadline issued.
Oracle PeopleSoft zero-day reportedly exploited
ShinyHunters reportedly exploits CVE-2026-35273 across 300 vulnerable systems. More than 100 organizations affected; ~68% are colleges and universities.
June 10, 2026
Oracle issues security alert. Patch status across affected systems not yet confirmed.
University of Nottingham confirms breach
~454,600 current and former students affected. Personal and academic records posted on ShinyHunters’ leak site.
We performed this kind of assessment for a major research university and a local partner. Both were well-managed and believed their security was strong. But neither had examined their shared boundary from an attacker’s perspective, since they trusted each other and hadn’t questioned that trust in years.
At that boundary, we found shared credentials without MFA, network shares that allowed attackers to move between institutions, and reused passwords on service accounts both teams thought were secure. A single compromised account could give access to the other institution. The risk was greater and had gone untested for a long time.
The results were clear. We showed what an attack between the two environments would look like and how far it could go. We found a path to sensitive shared information that neither team knew about. We also uncovered detection and response gaps that only appeared when tested. Together, we created a remediation plan to improve both institutions’ security and shared resources.
A meaningful supply chain assessment tests the real security boundary, not just what’s assumed. This includes external testing of internet-facing systems, internal network testing from different breach points, application testing of shared platforms, reviewing authentication and authorization across shared boundaries, and simulating lateral movement to see how far an attacker could go. The findings matter because they reflect reality, not just documentation. The goal isn’t to remove every vendor, but to make sure your controls work as expected.
Immediate action is possible even before Instructure releases its forensic analysis. Considering the observed breach characteristics and common vulnerabilities in higher education, we recommend prioritizing these measures this week.
Rotate all Canvas API keys and integration credentials in your system.
Instructure has reissued application keys with timestamps so admins can spot legitimate keys during re-authorization. Take advantage of this. Any integration still using an old key is a risk you can remove right now.
Check MFA enforcement at every shared network boundary.
Check MFA enforcement at every shared network boundary, not just at your perimeter, but between your institution and every partner, vendor, or affiliated group with network access. If MFA isn’t enforced at these points, one compromised account can put you at risk.
Review all shared service accounts between your institution and partners.
These accounts often go unaudited because they’ve worked for years. Look for password reuse, excessive privileges, and accounts that haven’t been reviewed since setup. This is where we find the most serious risks in partner assessments.
Inform your users about what to watch for now.
Institutions should anticipate phishing campaigns using Canvas-related language following a breach of this scale. Anyone with a school email in the breach is a target. Staff whose Canvas messages included sensitive topics—like safeguarding, accommodations, or finances—should be told their conversations may have been exposed and to treat any unexpected messages about Canvas access with caution.
Check your vendor breach notification requirements.
Review the contract language for Canvas and other major SaaS providers. Find out their notification timelines, what counts as a reportable incident under your laws, and whether there are gaps between what vendors promise and what you need to respond. Don’t wait until the next incident to find out.
The Canvas breach is a good time to test your assumptions, not just about Instructure, but about how your institution manages the risks from all its vendors and partners.
We’ve consistently found that proactive assessments do more than improve security—they provide clear, actionable data that helps secure funding and engage IT leaders. Showing exactly what an attacker could do, where detection gaps are, and what a remediation plan looks like leads to better conversations than compliance reports. Security should be a continuous cycle: assess, improve, and repeat. That cycle starts when you test the real boundaries.
The most damaging breaches in higher education aren’t coming through obvious entry points. They happen through trusted connections that haven’t been fully checked, shared platforms, partner networks, and vendors with old access that no one has reviewed since onboarding. If your team can’t confidently answer the questions here, that’s the gap to close before someone else finds it.
Further Reading
Why Your Campus Payment Systems Need Annual Penetration Testing
Managing OT Supply Chain Security and Insider Threats
Public reporting indicates the incident involved Instructure’s Canvas platform and related systems, not separate confirmed breaches of each university’s own network or identity infrastructure. Because Canvas is widely used across education, the compromise created downstream disruption for multiple institutions at once.
Instructure has reported that exposed data may include names, email addresses, user IDs or student IDs, course-related information, and Canvas messages. Attackers claimed access to a much larger dataset tied to thousands of institutions, but those broader claims have not been independently verified.
Higher education environments often rely on deeply integrated SaaS platforms, APIs, shared authentication, cloud services, and partner systems. When those connections are trusted but not continuously validated, a compromise at one vendor can create operational disruption and potential access risk across many institutions.
Institutions should review connected integrations, rotate exposed or high-risk credentials, validate MFA enforcement, monitor suspicious activity, warn users about phishing attempts, and review vendor notification and incident response requirements.
A strong third-party risk assessment tests what an attacker could actually reach through trusted vendor relationships. This can include reviewing authentication paths, exposed integrations, excessive permissions, lateral movement opportunities, and assumptions that may not have been validated since onboarding.
Sources:
