Instructure confirmed last week that ShinyHunters accessed Canvas data belonging to roughly 275 million students, educators, and staff at nearly 9,000 institutions worldwide.
Attackers gained initial access on April 29, 2026, by exploiting a vulnerability in Instructure's Free-for-Teacher program. The FFT program lets individual educators create Canvas tenants without institutional verification. That low-friction design created a trust boundary between FFT accounts and institutional Canvas tenants. The boundary was enforced in application code, not architectural separation. ShinyHunters found a flaw in support ticket handling within the FFT environment that let them cross it.
The Register reported on May 12 that Instructure detected and revoked access on April 29, then found a second unauthorized entry on May 7 tied to the same technique. By that point ShinyHunters had exfiltrated 3.65 terabytes of data covering names, email addresses, student IDs, and private messages from institutions across North America, Europe, and Asia-Pacific. The group defaced login portals at roughly 330 institutions and sent extortion demands directly to individual schools. Instructure reached a ransom agreement on May 11, one day before the deadline to publish the stolen data.
Two things in the reporting are worth pulling out.
What scanners would have missed
The failure here was not a code-level vulnerability in the traditional sense. It was an architectural assumption: that an unverified educator account operating inside the FFT tenant environment could not read data belonging to verified institutional tenants. That assumption was wrong at the API layer.
Standard vulnerability scanners work against surfaces they can observe. They probe endpoints and evaluate responses against a vulnerability model. What they cannot do is reason about tenant semantics.
Consider what a DAST scanner would see at the support ticket API. The scanner authenticates with a valid FFT credential. The endpoint returns 200. If the tool checks for access control issues, it tests authentication bypass by removing the token. That test passes. The problem is not unauthenticated access. The problem is that an authenticated FFT user can read data owned by a different, unrelated institutional tenant. The scanner has no model of what data should be returned for that account type.
Three reasons this class of flaw evades standard tooling:
- CVSS scoring is scoped to the finding in isolation. A single endpoint returning data to an authenticated user scores medium at most.
- DAST tools do not maintain a cross-request model of tenant boundaries. They observe HTTP in and out, not tenant identity semantics.
- SAST has no visibility into runtime tenant resolution logic. The code may look correct in isolation. The flaw is in how the pieces compose at scale.
The 275-million-record exposure follows directly from a finding that looks manageable in a standard scan report.
What Sekura would have shown
Sekura's exploit-chain analysis phase would trace the access graph from a low-trust FFT account to the institutional data layer.
We start with an attacker persona: an unverified educator account with no institutional affiliation. The exploit-chain agent walks available API surfaces using that credential. The goal is not to find an error response. The goal is to determine what data the credential actually reaches. When the support ticket endpoint returns records outside the FFT tenant boundary, the agent does not file a medium-severity finding and stop. It confirms scope: how many tenants are reachable, what data types return, and whether the read scales.
The resulting finding would read: "FFT credential reaches institutional student PII via support ticket API. Confirmed cross-tenant read. No tenant scope filter observed. Scope: all institutional tenants. 275 million records at risk." That is a critical finding, not a medium one.
I think the key distinction is what "proof" means in practice. A DAST report shows an endpoint that returned a 200 to an authenticated user. A Sekura exploit-chain report shows a working access path, a confirmed data return, and a scope estimate. We do not claim we would have stopped this breach. We are showing what proof-first analysis would have produced on this attack surface, in a pre-production scan.
The bigger pattern
The Instructure incident belongs to a well-documented category: multi-tenant isolation failure in a SaaS platform.
The pattern is consistent. A product team adds a low-friction onboarding tier to grow adoption. That tier sits within the same shared infrastructure as verified enterprise customers. Isolation between tiers is implemented as application-layer access control. One API endpoint with incomplete tenant scoping undoes that isolation for every customer on the platform.
In 2026, most SaaS platforms run single-cluster, shared-infrastructure architectures. The correctness of tenant boundary enforcement code is load-bearing for every customer simultaneously. The industry does not have widely deployed tooling for auditing multi-tenant isolation holistically, across the full access graph and across tenant tiers. That gap is what ShinyHunters exploited.
If you want to see what exploit-chain analysis looks like on your own application, book a POC.