ShinyHunters Didn't Breach 9,000 Schools. They Breached One Vendor. Your Institution Inherited the Rest.

On the evening of April 30, Instructure opened a support ticket on its own status page. The language was quiet: "limited disruption to tools relying on API keys." Canvas Data 2 and Canvas Beta went into maintenance mode. Tools that used API keys started failing silently at institutions across the country. By the next afternoon, the quiet language was gone. CISO Steve Proud confirmed a criminal threat actor had accessed names, email addresses, student ID numbers, and private user messages. Outside forensics were already on-site.

Twenty-four hours from "limited disruption" to confirmed breach. If you run Canvas at your institution and you're reading this, that window matters -- because it's probably how long your integrations were authenticating against a compromised environment before the keys got rotated.

This piece is for the people who have to make decisions in the next few days: the IT security staff, the sysadmins managing LTI integrations, the folks who got a vendor notification and are now trying to figure out what it actually means for their environment. I'm going to be precise about what's confirmed, what's being inferred from the disruption pattern, and what is currently just ShinyHunters telling their side of the story.

What Instructure Has Actually Confirmed

The confirmed data classes are names, institutional email addresses, student ID numbers, and messages sent between users inside the Canvas platform. Instructure has explicitly stated they found no indication that passwords, dates of birth, government identifiers, or financial information were involved. Take that at face value as a starting point, not as a conclusion -- the forensic investigation is still active.

The containment actions Instructure has confirmed: privileged credentials and access tokens were revoked, certain application keys were rotated (requiring users to reauthorize connected tools), security patches were deployed, and additional monitoring was implemented. Instructure's own status update on May 6 stated that Canvas is fully operational and there is no ongoing unauthorized activity. They're now communicating directly with impacted institutions rather than through the public status page.

UMass Amherst's IT advisory confirmed Instructure notified both the FBI and CISA. No CISA advisory has been published specific to this incident as of this writing.

What We're Inferring From the Disruption Signature

Instructure has not publicly disclosed the attack vector. What the disruption pattern tells us, independent of anything ShinyHunters claims: the specific systems that went down were Canvas Data 2 and Canvas Beta, and the specific symptom institutions reported was failure in tools that depended on API keys. Instructure's containment response was to revoke privileged credentials and rotate application keys -- not to push an emergency patch for a user-facing vulnerability, not to force a password reset across the user base.

That pattern is consistent with compromise at the application-layer credential or service-account level. Something with privileged API access was compromised, and the remediation was to kill and reissue those credentials. That's a meaningfully different failure mode than a web application vulnerability or a mass credential phishing event. It suggests the attacker had access that looked like legitimate administrative traffic, which is exactly why Canvas Data 2 was the affected surface -- that's the analytics export pipeline, the part of the stack that moves data in bulk.

I want to be explicit that this is inference from the available evidence, not Instructure's confirmed account. The company hasn't said what the access path was.

What ShinyHunters Claims (and What to Do With It)

ShinyHunters posted to their Tor-based leak site on May 3, claiming responsibility, 3.65 terabytes of exfiltrated data, 275 million affected users across roughly 9,000 institutions. On May 7, the same group defaced Canvas login pages at multiple institutions with an extortion message accusing Instructure of ignoring their outreach and demanding negotiations before May 12.

The scale figures -- 275 million users, 3.65 TB -- are adversary self-reporting and have not been independently verified. Treat them as pressure tactics, not confirmed data inventory. The University of Pennsylvania confirmed approximately 306,000 affected users at their institution specifically; that's the most concrete institution-level figure I've seen from a confirmed source.

ShinyHunters also claims Instructure's Salesforce instance was compromised as part of this campaign. That claim is unconfirmed by Instructure, but it lines up directly with the documented September 2025 breach, where social engineering against Instructure's Salesforce environment was the confirmed vector. Whether May 2026 is a fresh intrusion through the same path, or persistence from the earlier compromise, hasn't been established publicly.

Instructure hasn't attributed this incident to a named actor. That's relevant -- it means we're working with claimed attribution, not confirmed attribution.

Who ShinyHunters Is Right Now

The group's current operating model is worth understanding because it shapes what the residual risk looks like for your users.

ShinyHunters started as a mass data theft operation in 2020 and has spent the last two years pivoting toward targeted SaaS extortion. They're operating under loose affiliation with what researchers at Trustwave SpiderLabs have characterized as the Scattered LAPSUS\( Hunters alliance -- not a formal merger, but a situational brand that combines ShinyHunters' data theft capabilities with Scattered Spider's social engineering tradecraft and LAPSUS\)'s brand recognition. The threat intel community flags attribution here as genuinely messy; the group leans into that.

Their Salesforce campaign across the summer of 2025 is the most documented precedent. The attacks didn't exploit Salesforce vulnerabilities. They used voice phishing against help desk staff to coerce employees into completing legitimate OAuth authorization flows, combined with Salesforce Data Loader -- a bulk export tool designed for legitimate data migration -- to pull CRM data at scale. No custom malware. No zero-day. The attacker impersonated IT support, got someone to authorize a malicious Connected App, and then used Salesforce's own tooling to walk out with the data.

That's the group's signature: get legitimate access, use legitimate tooling, make the exfiltration look like authorized activity. The May 2026 Instructure disruption pattern -- API key failures, Canvas Data 2 affected, bulk analytics pipeline disrupted -- is consistent with that approach at the application layer.

The Blast Radius Is Bigger Than the Breach Itself

This is the piece that a vendor notification email won't explain clearly enough.

Canvas integrates with over 1,000 external tools. LTI apps, SIS connectors, gradebook sync tools, SSO configurations, analytics platforms, third-party assessment tools -- all of them authenticated against Canvas at some point before the keys were rotated. Instructure rotated the platform-side keys. Your institution's tenant-generated API keys are yours to rotate, and they aren't automatically invalidated by Instructure's remediation unless they happened to be the specific keys that were compromised.

If you have API keys your institution generated for Canvas integrations, they need to be treated as potentially compromised until you've rotated them yourself. That's not Instructure's responsibility to do for you.

There's a second exposure window that's getting less attention: the re-authorization prompts. When Instructure rotated application keys, connected tools started prompting users and admins to re-authorize access. That's a real, legitimate process. It's also an ideal template for a phishing campaign. An attacker with a list of confirmed institutional email addresses -- which is exactly what was taken -- can send re-auth prompts that are structurally indistinguishable from the real ones. In prior incidents against edtech platforms, the phishing wave has followed the breach disclosure within weeks. That window is open right now.

Treat any Canvas re-authorization email that arrives via your inbox rather than directly inside the Canvas interface as suspicious until you've verified the source.

What to Do This Week If You Run Canvas

Immediate action: Rotate every API key your institution generated for Canvas integrations. Instructure rotated platform-side keys -- tenant-generated keys are your responsibility and are not automatically invalidated by their remediation.

Rotate every API key your institution generated for Canvas integrations -- LTI tools, SIS connectors, reporting pipelines, anything that authenticates against Canvas using a key you hold. Don't wait for Instructure to tell you which keys were affected; the answer is that you don't know yet, and the cost of rotating is low relative to the cost of a compromised integration sitting quietly in your environment.

Immediate action: Audit every app registration and OAuth grant your identity provider holds for Canvas. A Canvas-linked credential with directory access is a path to your entire tenant, not just Canvas.

If your Canvas SSO ties into Microsoft Entra ID, open up Enterprise Applications and App Registrations right now. Review what consented to Graph API permissions, rotate client secrets on Canvas-linked app registrations, and verify that each grant reflects least-privilege scope. A Canvas-side credential that has Graph API access to your Entra tenant is a path to your directory, not just Canvas.

Do the same audit for any other identity provider Canvas federates against. The breach is at Instructure. The credentials and OAuth grants that Canvas holds into your environment are your exposure surface.

Enforce MFA on privileged accounts if you haven't already -- Instructure's own post-containment guidance said this explicitly. And for the next sixty to ninety days, treat any unexpected Canvas-themed email as a potential social engineering attempt. That includes password reset prompts, re-authorization requests, grade notifications from unfamiliar addresses, and anything that asks for institutional SSO credentials via a link.

For K-12 specifically: the FTC's updated COPPA amendments took effect June 23, 2025, and the compliance deadline for most operators landed on April 22, 2026. The Instructure breach was detected eight days after that deadline passed. For districts with Canvas users under thirteen, the updated security and breach notification requirements aren't pending -- they're now in force. Start your COPPA notification assessment now, before a state AG inquiry prompts it.

The Structural Problem That Keeps Producing These Incidents

This is the third major edtech SaaS vendor in eighteen months to lose student data at scale. PowerSchool disclosed a breach in late 2024 -- with estimates indicating more than 62 million students and 9.5 million teachers may have had records exposed. Infinite Campus followed. Now Instructure. The vendors are different. The architecture is identical.

A single SaaS provider holds data on tens of millions of students across thousands of institutions. That provider gets compromised through a single privileged account, a single integration, or a single misconfigured CRM instance. Every institution that trusts that provider inherits the breach simultaneously. None of their own perimeter controls -- firewalls, endpoint detection, DLP -- saw a thing, because the attacker never touched their perimeter. The attacker used legitimate credentials to access a legitimate platform and pulled data that was supposed to be inside a trusted perimeter. It looked like authorized traffic because it was authorized traffic, with stolen authorization.

This is what supply chain risk actually looks like at the identity layer. The question worth sitting with isn't "how do we harden Canvas" -- you can't harden a vendor's platform from outside it. The question is: what does your institution trust Canvas with, how many integrations does that trust extend through, and do you have visibility into what happens when that trust is violated? For most institutions right now, the honest answer to that last part is no.

The breach notification will come. The phishing wave is already starting. The forensic investigation is still running. Keep checking status.instructure.com and your institution's IT security page for updates, and assume the situation is still developing until it demonstrably isn't.

If you've already gone through this rotation and audit process at your institution, I'd be curious what you found in your Entra app registrations -- the breadth of OAuth consent grants in a mature Canvas deployment tends to surprise people.