The Failure Pattern
On April 30, tools depending on Canvas API keys started failing across
thousands of institutions. Instructure's status page called it "limited
disruption to tools relying on API keys." Canvas Data 2 and Canvas Beta
went into maintenance. By May 1, the CISO confirmed a criminal threat
actor had been in the environment. Containment was declared May 2.
The confirmed data classes: names, institutional email addresses, student
ID numbers, and Canvas inbox messages. Instructure explicitly states no
passwords, government IDs, or financial data were involved. The forensic
investigation is still running.
ShinyHunters claimed responsibility May 3, asserting 3.65TB exfiltrated
across 275 million users at roughly 9,000 institutions. Those figures are
adversary self-reporting and unverified. The University of Pennsylvania
confirmed approximately 306,000 affected users -- that's the only
institution-level figure from a confirmed source so far.
No CVE. No CISA advisory. No IOC list. This is still an active
investigation and Instructure hasn't disclosed the attack vector.
What the Disruption Signature Tells Us
Instructure has not confirmed how the attacker got in. But the response
pattern tells you something.
They didn't force a password reset across the user base. They didn't push
an emergency patch for a web vulnerability. They revoked privileged
credentials and access tokens, rotated application keys, and deployed
patches. That response is consistent with application-layer credential
compromise -- something with privileged API access got taken, and the
fix was to kill and reissue those credentials.
Canvas Data 2 is the analytics export pipeline. It's the part of the
stack designed to move data in bulk. That's the surface that went down.
That's also what you'd target if you had stolen credentials that looked
like legitimate administrative traffic -- because that's exactly what
they were.
This is inference, not Instructure's confirmed account. Flag it as such
if you're briefing your team.
Who ShinyHunters Is and Why the TTP Matters
ShinyHunters pivoted from mass data theft to targeted SaaS extortion in
2024 and has spent the last eighteen months running campaigns against
Salesforce environments specifically. Their summer 2025 Salesforce
campaign is the most documented playbook.
The attack chain didn't exploit Salesforce. It used voice phishing against
help desk staff to get employees to authorize malicious OAuth Connected
Apps through a standard authorization flow. Once the token was issued,
they used Salesforce Data Loader -- a legitimate bulk export client -- to
pull CRM data at scale. No malware. No custom tooling. Just a phone call,
a legitimate-looking OAuth prompt, and the platform's own export
functionality.
That's the signature: get a credential that looks authorized, use
legitimate tooling, make the exfiltration look like normal traffic. The
Instructure disruption pattern -- API key failures, bulk analytics pipeline
down, credential revocation as the containment action -- is consistent with
that approach at the application layer.
ShinyHunters also claims Instructure's Salesforce instance was hit as part
of this campaign. Instructure confirmed a separate Salesforce breach via
social engineering in September 2025. Whether May 2026 is a fresh
intrusion or persistence from that incident hasn't been established.
What Your Integration Stack Inherited
This is the part the vendor notification won't explain clearly.
Instructure rotated platform-side application keys. What that means in
practice: every LTI tool, SIS connector, gradebook sync, analytics
pipeline, and SSO configuration at your institution that held a
Canvas-issued key got that key invalidated and reissued. Connected tools
started prompting for reauthorization.
What it does not mean: your tenant-generated API keys were rotated.
Those are keys your institution created for your own integrations. They
are not invalidated by Instructure's remediation. They are your
responsibility.
If you generated API keys for any Canvas integration -- reporting
pipelines, custom LTI tools, data warehouse syncs, anything -- those
keys need to be treated as potentially compromised until you've rotated
them yourself.
The second problem is the reauthorization window. An attacker holding
confirmed institutional email addresses -- which is exactly what was
taken -- can send reauthorization prompts that are structurally
indistinguishable from the legitimate ones Instructure is triggering
right now. In prior edtech incidents, the phishing wave followed the
breach disclosure within weeks. That window is open.
Any Canvas reauthorization email landing in an inbox rather than
appearing inside the Canvas interface itself should be treated as
suspicious.
What to Audit Right Now
Rotate tenant-generated API keys first. Every key your institution
created for Canvas integrations -- LTI tools, SIS connectors, reporting
pipelines, data exports -- needs to be rotated. Don't wait for
Instructure to tell you which keys were in scope. Assume all of them
until you know otherwise.
If Canvas SSO federates into Microsoft Entra ID, this is your checklist:
Open Enterprise Applications in Entra and filter for any app
registered against Canvas or Instructure. For each one: check consented
Graph API permissions against what the integration actually needs, rotate
client secrets, and revoke and reissue any certificates. A Canvas-side
credential that holds Graph API access into your Entra tenant is a path
to your directory, not just Canvas.
Audit OAuth grants in every identity provider Canvas touches.
A stolen Canvas-linked credential with directory permissions is
lateral movement waiting to happen. The breach is at Instructure.
The blast radius is wherever those credentials reach.
Run the same check against any other identity provider Canvas federates
against -- Okta, Google Workspace, ADFS. Inventory every app registration
and OAuth grant. Verify least-privilege scope on each one.
Enforce MFA on privileged accounts -- Instructure's own post-containment
guidance said this explicitly. And treat any Canvas-themed email asking
for credential input as a potential phishing attempt for the next sixty
to ninety days.
The Architecture Problem
Canvas integrates with over 1,000 external tools across 7,000+
institutions. When Instructure gets compromised, every institution's
integration stack inherits the exposure simultaneously. None of your own
perimeter controls see it because the attacker never touched your
perimeter. The traffic looked authorized because the credentials were
authorized -- just stolen.
PowerSchool. Infinite Campus. Now Instructure. Three major edtech vendors
in eighteen months. The vendors are different. The structural pattern is
identical: single SaaS provider, single credential compromise, thousands
of institutions inherit the breach at once.
The question worth sitting with isn't how to harden Canvas from outside
-- you can't do that. It's what your institution's Canvas deployment
trusts, how many integrations that trust extends through, and whether
you have visibility into the OAuth consent graph that Canvas holds into
your environment. For most institutions, the honest answer to the last
part is no.
Keep an eye on status.instructure.com
and your institution's IT security page. The investigation is still
running and the notification timeline is still developing.
If you've run the Entra audit already and found something worth sharing,
I'd be curious what the consent graph looked like in a mature Canvas
deployment.
