ShinyHunters Sets May 12 Deadline for Canvas / Instructure: 8,809 Schools, 275M Records, Per-School Ransom Demands

Introduction

ShinyHunters has shifted from disclosure to extortion against Instructure, the company behind the Canvas learning-management platform used by more than 8,000 universities, K-12 districts, and training organisations worldwide. After defacing roughly 330 school login portals during finals week on May 7, the group has now set a hard pay-or-leak deadline of end-of-day May 12 and is forcing each affected institution to negotiate its own ransom over Tox. Claimed haul: about 275–280 million student-and-staff records totalling 3.65 TB, drawn from up to 9,000 institutions, with ~30 million currently active Canvas users in scope.

What Happened

Instructure first disclosed the incident on May 1 and declared it "contained" by May 6. On May 7, ShinyHunters made it clear "contained" did not mean "their copy of the data went away" by replacing Canvas login screens at universities including Harvard, Penn, Duke, Virginia Tech, and MIT with ransom messages timed to mid-finals. The defacement specifically targeted the OAuth login flow, so any student or staff member trying to access course materials was met with the extortion note instead.

Per Instructure, the stolen data includes names, email addresses, student ID numbers, and private messages between users; the company says passwords, dates of birth, government IDs, and financial information were not exposed. ShinyHunters' own public claims cite 275–280 million records across 8,809 institutions and 3.65 TB of data — large enough that even substantial deduplication still leaves multi-million-record exposure for any individual large institution.

The extortion model is unusual and worth understanding. ShinyHunters is not pricing one ransom for Instructure as a whole; the group is demanding each affected school negotiate separately over Tox messaging, with a May 12 end-of-day deadline before its threatened mass leak. Instructure was briefly removed from the leak blog in the days after disclosure, which usually signals an in-progress negotiation, but the public deadline against individual schools has not changed. ShinyHunters' history with Snowflake-era third-party-token theft is the template here: harvest once, monetise per tenant.

Why It Matters

The "negotiate per institution" structure converts one company's bad day into a coordinated panic across thousands of unrelated institutions, almost none of which have a tested playbook for negotiating with an extortion crew, paying a ransom, or operating their LMS on a deadline. In practice, that means pressure flows downhill — students are asking why their finals were disrupted, IT teams are scrambling to identify what was actually exfiltrated about their tenant, and parents are pursuing inquiry channels that the universities themselves do not yet have answers for.

For defenders, the bigger lesson is the OAuth-and-login-portal attack surface. Even if no Canvas password was exposed, the harvested email addresses paired with course names, student IDs, and private messages give a phishing operator enough context to send extremely convincing lures to a 30-million-strong list. Canvas-themed phishing — "Your professor has shared a feedback rubric for ECON-201, sign in here" — is now a high-confidence inbound risk for every Canvas-using institution and the partners they integrate with.

Who Is Affected

  • Up to 9,000 educational institutions globally that use Canvas (Instructure), with about 30 million active users in scope.
  • ~330 universities and schools whose login portals were defaced May 7 — including Harvard, Penn, Duke, Virginia Tech, and MIT.
  • Students, faculty, and staff whose names, email addresses, student IDs, and private Canvas messages were exfiltrated.
  • Indirectly, every SIS, identity provider, single sign-on, and OAuth-connected app integrated with Canvas — those integrations are not the breach surface, but the leaked metadata makes targeted phishing against them substantially easier.

How to Protect Yourself

If you are an Instructure customer, your first move is not to wait for vendor guidance — it is to assume your tenant data is in scope and put the rotation work in motion now.

# enumerate Canvas API tokens issued in the affected tenant
curl -s -H "Authorization: Bearer $CANVAS_ADMIN_TOKEN" \
  "https://canvas.your-school.edu/api/v1/accounts/self/users?per_page=100"; \
  | jq '.[] | {id, login_id, email, last_login}'

# rotate developer keys for any LTI/Canvas API integrations
# (admin -> Developer Keys -> regenerate; do this for every key, not just the ones you use)

Force re-authentication for every active session and rotate any service-account-style credentials your SIS, SSO, or grade-sync integrations use against Canvas:

# example: revoke all access tokens for a specific user via admin API
curl -X DELETE \
  -H "Authorization: Bearer $CANVAS_ADMIN_TOKEN" \
  "https://canvas.your-school.edu/api/v1/users/$USER_ID/sessions";

# audit IdP (Okta/Azure/Shibboleth) for sessions assertions to canvas in the breach window
# Okta example
curl -s -H "Authorization: SSWS $OKTA_API_TOKEN" \
  "https://your-org.okta.com/api/v1/logs?filter=outcome.result%20eq%20%22SUCCESS%22%20and%20target.displayName%20co%20%22Canvas%22&since=2026-04-15T00:00:00Z"; \
  | jq '.[] | {time: .published, actor: .actor.displayName, ip: .client.ipAddress}'

Treat your tenant's email-address column as a confirmed phishing list. Stand up two protections immediately:

# add a generous SOC alert for "Canvas-themed login lures" to incoming mail
# (rule sketches; translate to your secure email gateway / Defender / Mimecast etc.)
#   subject contains: ("Canvas" or "Instructure" or "your assignment" or "feedback rubric")
#   AND from-domain not in: (instructure.com, canvaslms.com, your-school.edu)
#   AND contains URL not on allowlist
# action: quarantine + analyst review

# block clones of canvas login URLs at the DNS level
# add to your DNS sinkhole: canva-login.*, canvas-secure.*, canvasl-ms.*, instructure-secure.*

For students and staff who use Canvas, the practical advice is short: sign in to Canvas only by typing the URL directly or following an institutional bookmark; never via an email link. Enable MFA on the institutional account if it is not already mandatory, and assume any "Canvas message about your grade" arriving by email this week is hostile until proven otherwise.

If you operate any platform with similar architecture — login portals at thousands of customer subdomains, OAuth flows shared across tenants, exposed admin API surface — this is the prompt to verify that a breach of a single shared component cannot leak per-tenant data en masse. Logging, scoped service accounts, and per-tenant network egress checks for the data-exfiltration phase are all cheaper than negotiating with 8,000 customers one by one.

Source