Wat is er gebeurd?

Canvas is het leerplatform van Instructure en wordt wereldwijd gebruikt door onderwijsinstellingen. Voor studenten en docenten is het de plek waar opdrachten, berichten, lesmateriaal, cijfers en portfolio’s samenkomen. Voor Instructure is het een grootschalig SaaS-platform met duizenden klanten, verschillende accounttypen, koppelingen en rollen.

Begin mei 2026 maakte Instructure bekend dat er ongeautoriseerde toegang was geweest tot de Canvas-omgeving. Daarbij zijn persoonsgegevens buitgemaakt, waaronder namen, e-mailadressen, studentnummers en berichten tussen gebruikers. Volgens Instructure waren er geen aanwijzingen dat wachtwoorden, geboortedata, financiële gegevens of officiële identificatiedocumenten waren geraakt.

Voor een softwarebedrijf is dit incident interessant omdat het niet draait om één gehackte school, maar om een aanval op het platform zelf. De zwakke plek zat niet primair bij de klantorganisatie, maar in de SaaS-laag waar accountbeheer, autorisatie, logging, tokens, tenants en productfunctionaliteit samenkomen. Precies daar waar schaalbaarheid normaal je kracht is, werd schaalbaarheid nu het risico.

Wat was de impact?

De impact werd in Nederland vooral zichtbaar toen onderwijsinstellingen Canvas uit voorzorg offline haalden. Onder meer Hogeschool Utrecht, Fontys Hogeschool en De Haagse Hogeschool werden in de berichtgeving genoemd. Bij Hogeschool Utrecht werden Canvas en gekoppelde systemen zoals Portflow losgekoppeld. Bij Fontys werd gemeld dat onder meer namen, e-mailadressen, studentnummers en onderlinge berichten waren buitgemaakt.

Voor studenten betekende dit dat opdrachten niet via de normale route konden worden ingeleverd, lesmateriaal niet beschikbaar was en deadlines moesten worden aangepast. Voor softwarebedrijven zit daar een belangrijke les in: jouw incident wordt al snel het bedrijfscontinuïteitsprobleem van je klant. Als een kernplatform uitvalt, raakt dat niet alleen data, maar ook primaire processen.

Een SaaS-leverancier levert dus niet alleen functionaliteit. Hij levert vertrouwen, beschikbaarheid en operationele continuïteit. En bij een incident wordt precies getest of de architectuur, monitoring en crisiscommunicatie daarop zijn ingericht.

Hoe zijn de hackers binnengekomen?

Volgens Instructure maakte de aanvaller gebruik van de zogenoemde Free-For-Teacher-omgeving: gratis Canvas-accounts voor individuele docenten. De aanvaller gebruikte in beide incidenten zo’n account. Instructure stelt dat er kwetsbaarheden en privilege-escalatiepaden zijn misbruikt en dat deze zijn verholpen.

Technisch wijst dit op een klassiek SaaS-risico: een laagdrempelig accounttype krijgt via een fout in autorisatie, rechtenmodel of platformlogica toegang tot meer dan bedoeld. Dat hoeft niet te betekenen dat zo’n account direct adminrechten had. Het kan ook gaan om een combinatie van zwakke tenant-isolatie, onvoldoende server-side autorisatiechecks, te ruime API-mogelijkheden, herbruikbare tokens of functies die in gratis en betaalde omgevingen dezelfde backend delen.

Juist dat laatste is relevant voor softwarebedrijven. Gratis proefomgevingen, demo-accounts en freemium-modellen zijn commercieel aantrekkelijk, maar technisch risicovol als ze dezelfde paden, objecten, API’s of permissiemodellen gebruiken als productieomgevingen van betalende klanten. Een account dat bedoeld is als laagdrempelige instap mag nooit een springplank kunnen worden naar bredere platformdata.

Op 7 mei volgde een tweede incident. Dezelfde dreigingsactor kreeg opnieuw toegang en paste pagina’s aan die sommige studenten en docenten zagen wanneer zij via Canvas waren ingelogd. Volgens Instructure werd dit binnen ongeveer tien minuten gedetecteerd en gestopt. Dat snelle detectiemoment is positief, maar het feit dat er na de eerste ontdekking opnieuw toegang mogelijk was, laat zien hoe lastig volledige containment is bij complexe SaaS-platformen.

Tijdlijn van de aanval

Op 29 april 2026 detecteerde Instructure ongeautoriseerde activiteit in Canvas. De toegang van de aanvaller werd ingetrokken en externe forensische experts werden ingeschakeld.

Op 1 mei werden klanten geïnformeerd over het cybersecurity-incident. Daarna werd duidelijk dat ook Nederlandse onderwijsinstellingen op slachtofferlijsten voorkwamen. Instellingen gingen risico’s afwegen: openhouden voor onderwijscontinuïteit of afsluiten totdat er meer zekerheid was.

Op 7 mei werd Canvas opnieuw geraakt. Sommige gebruikers kregen aangepaste meldingen of pagina’s te zien. Daarna haalden instellingen Canvas en gekoppelde systemen offline. Hogeschool Utrecht schakelde Canvas en Portflow uit. Ook Fontys sloot Canvas af.

In de dagen daarna volgden noodoplossingen. Deadlines werden uitgesteld, lesmateriaal werd via alternatieve kanalen gedeeld en instellingen wachtten op aanvullende informatie en analyses voordat zij systemen weer gefaseerd beschikbaar maakten.

Waarom is deze aanval geslaagd?

Deze aanval lijkt te zijn geslaagd door een combinatie van technische en organisatorische factoren. Technisch zat het risico in privilege escalation: een accounttype kon kennelijk worden gebruikt om verder te komen dan de bedoeling was. Dat wijst op tekortkomingen in autorisatie, segmentatie of controle op gevoelige platformacties.

Daarnaast speelt tenant-isolatie. In een multi-tenant SaaS-platform moet iedere actie worden gevalideerd op gebruiker, rol, tenant, object en context. Niet alleen in de frontend, maar vooral server-side en op API-niveau. Iedere aanname zoals “deze route wordt alleen door dit accounttype gebruikt” is gevaarlijk.

Ook tokenbeheer is cruciaal. Bij incidentrespons moeten sessies, API-tokens, serviceaccounts, signing keys en integratiekoppelingen snel kunnen worden ingetrokken of geroteerd. Als dat niet volledig of niet snel genoeg kan, blijft hernieuwde toegang mogelijk.

Tot slot speelt detectie. Monitoring moet niet alleen kijken naar bekende aanvalspatronen, maar ook naar afwijkend gedrag binnen applicatielogica: ongebruikelijke exports, toegang buiten tenantgrenzen, privilegewijzigingen, massale API-reads, rare templatewijzigingen of activiteiten vanuit accounttypen die normaal weinig rechten hebben.

Wat kunnen organisaties hiervan leren?

Voor softwarebedrijven is de les helder: behandel elk accounttype als potentieel aanvalspad. Gratis accounts, proefaccounts, supportaccounts en testomgevingen moeten technisch strikt gescheiden zijn van productiegegevens van klanten, tenzij er aantoonbaar harde isolatie is.

Daarnaast moet autorisatie centraal en afdwingbaar zijn. Geen losse permissiechecks verspreid door de codebase, maar een consistent model waarin iedere actie wordt getoetst op rol, tenant, object en doel. Test dit actief met abuse cases, niet alleen met functionele happy flows.

Investeer ook in security regression testing. Iedere nieuwe feature, API of exportfunctie moet worden getest op broken access control, IDOR, privilege escalation en tenant escape. Dit hoort thuis in de CI/CD-pipeline, naast reguliere unit- en integratietests.

Zorg verder voor een volwassen incidentrespons binnen het product zelf. Kun je tokens platformbreed intrekken? Kun je tenants tijdelijk isoleren? Kun je verdachte functies uitschakelen zonder het hele platform offline te halen? Kun je klanten snel vertellen welke data, welke periode en welke gebruikers geraakt zijn?

Tot slot

De Canvas-hack laat zien dat SaaS-security niet alleen draait om firewalls, MFA en pentests. De echte risico’s zitten vaak dieper: in autorisatielogica, tenant-isolatie, accounttypen, tokens en monitoring van applicatiegedrag.

Voor softwarebedrijven is dit de kern: bouw je platform alsof ieder laagdrempelig account morgen door een aanvaller wordt gebruikt. Beperk rechten, segmenteer omgevingen, test misbruikscenario’s en bereid containment technisch voor.

Wil je weten of jouw SaaS-platform bestand is tegen privilege escalation, tenant escape of misbruik van accounttypen? Neem contact op met Hoek en Blok.IT. Wij helpen softwarebedrijven om kwetsbaarheden in applicatiearchitectuur, autorisatie en incidentrespons zichtbaar te maken voordat een aanvaller dat doet.