Skip to content
HACKTECH
BreachesReported Published 5 sources

Instructure confirms Canvas breach via a Free-for-Teacher account and a second intrusion

Instructure, the developer of the Canvas learning management system, said it detected unauthorised activity in Canvas on 29 April 2026 and later confirmed the actor had used one of its Free-for-Teacher accounts. According to Help Net Security, ShinyHunters claimed to have stolen 3.65 TB of data tied to approximately 275 million records across 8,809 educational institutions. On 7 May the same actor used a second Canvas vulnerability to change pages shown to some logged-in students and teachers. On 11 May Instructure said it had reached an agreement with the actor, that the data had been returned and that it had received digital confirmation of its destruction.

  • education
  • edtech
  • Canvas
  • Instructure
  • ShinyHunters
  • extortion
  • multi-tenant platforms
  • student data

What the sources report

  • Instructure said it detected unauthorised activity on 29 April, immediately revoked the unauthorised party's access, started an investigation and engaged outside forensic experts; a 'Confirmed Security Incident' notice was first posted on its status page on 1 May 2026, and the status page marked the incident resolved on 6 May.
  • Instructure confirmed the actor used one of its Free-for-Teacher accounts in both incidents and identified an exploited vulnerability regarding support tickets in the Free-for-Teacher environment; Free-for-Teacher has been permanently discontinued.
  • Instructure said the data fields involved include usernames, email addresses, course names, enrolment information and messages, and that core learning data (course content, submissions, credentials) was not compromised.
  • Instructure said that on 7 May the actor changed pages that appeared when some students and teachers were logged in, that monitoring added after the first attack detected and disabled the second attack about 10 minutes after it began, and that no additional data was accessed or exfiltrated; Help Net Security reported defaced Canvas login portals at about 330 institutions.
  • Instructure said it received 'digital confirmation of data destruction (shred logs)'; Inside Higher Ed reported that Instructure paid a ransom, that the company did not disclose the deal's monetary value, and, citing the company's update, that the returned data covered some 275 million users across more than 8,800 institutions.
  • Instructure said it was working with CrowdStrike on forensic analysis, stated in a 13 May update that it had rolled out CrowdStrike's Falcon Endpoint Detection & Response tool across its network, and said in a 29 September update that its forensic review of the data involved was complete.

What it means for your organisation

A free, self-service account tier and its support-ticket environment gave an attacker a route into a platform serving thousands of schools and universities, and a second vulnerability was exploited the day after the incident was marked resolved on Instructure's status page. Low-trust tenant tiers need hard isolation from production data and support tooling, and remediation should be verified by retesting before a platform is declared safe. For institutions, one vendor held usernames, email addresses, course names, enrolment information and messages among users, and the data came back through an agreement with the attacker; Instructure itself said there is never complete certainty when dealing with cyber criminals.

What we check

  • Test whether free, trial or self-registered accounts can reach other tenants' data, administrative functions or support tooling through authorisation flaws or privilege escalation.
  • Review support-ticket and helpdesk integrations for paths that let a customer-controlled account act with staff or system privileges.
  • After containment, retest for alternative entry points and confirm monitoring coverage before announcing that services are safe to use.
  • For institutions, follow the practices Instructure advised on its status page (enforce MFA on privileged accounts, review admin access, rotate API tokens or keys), and review what student data the platform holds and the vendor's notification commitments.
  • Confirm students and staff have been warned to expect phishing that uses the exposed names and email addresses.

Sources

Services that cover these checks

  • Web application testing

    Authenticated, role-aware testing of your application and its API surface, with an account for every role. We chain small findings into the access they lead to, such as a sequential invoice ID and a missing tenant check that together let one customer read another's invoices.

    Duration: 5 to 10 working days

  • Application security audit

    A white-box review of your application: source code, architecture, dependencies and build pipeline. Automated analysis finds the candidates; reviewers confirm each one by reading the code path, and only confirmed defects reach the report, each with a file and line reference.

    Duration: 5 to 15 working days, depending on codebase size

  • Cloud configuration review

    An IAM-first review of AWS, Azure or GCP. We map what an attacker reaches after compromising one workload or one developer laptop, then rank those paths by the data at the end of each and write the Terraform or policy change that cuts it.

    Duration: 4 to 8 working days

  • Threat modelling

    Facilitated workshops that map how a system or feature could be attacked before it is built or shipped. We draw the data flows with your engineers, walk them with STRIDE, rank the threats by likelihood and impact, and turn the result into backlog items and test cases your team owns.

    Duration: 2 to 5 days per system, remote or on site

  • Incident response

    Hands-on help when an attacker is already inside: triage on the first call, containment that does not destroy evidence, forensic scoping of what was touched, and recovery that we verify before calling it complete. Outside a crisis we run retainers, tabletop exercises and compromise assessments, so your team has practised the first hour before it happens.

    Duration: Live incidents until recovery is verified; readiness work in days

Run these checks against your own systems

We pick the checks that apply to your systems. A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.

Scope an engagementHow incident response works