Kort gezegd: Bij Moodle-beveiliging op scholen gaat het om gegevens van kinderen en jongeren, om cijfers en om het lopende onderwijs. Stel eerst vast wie uw Moodle beheert: deelstaat, schoolbestuur, dienstverlener of een betrokken leraar. Daarvan hangt af wie PHP patcht, herstart en het bewijs levert.
Welke PHP-systemen in scholen en onderwijsinstellingen draaien
Centraal staat vaak de leeromgeving Moodle. Daarbij komen de schoolwebsite, vaak op WordPress of Joomla, tools voor vervangingsroosters, formulieren voor ouderbrieven en aanmeldingen, boekingssystemen voor ruimten en apparatuur en bestandsopslag zoals Nextcloud. Bijna alles daarvan draait op PHP.
Bij particuliere opleidingsinstituten, volksuniversiteiten en aanbieders van bijscholing komen cursusboekingen, deelnemersbeheer en online examens erbij. Hier is de leeromgeving vaak rechtstreeks verbonden met facturering en deelnemersgegevens.
Welke gegevens in Moodle en dergelijke staan
Een leeromgeving bevat meer dan werkbladen: namen en klassen van leerlingen, ingeleverd werk, beoordelingen en feedback, forumberichten, berichten tussen leraren en leerlingen, bij opleidingsinstituten ook deelnamebewijzen en examenresultaten. Hier en daar staan aanwijzingen over een ondersteuningsbehoefte of gezondheidsbeperkingen, die tot de bijzondere categorieën volgens art. 9 AVG kunnen horen.
De betrokkenen zijn overwegend minderjarig. Dat verhoogt het risico bij een gegevenslek, omdat kinderen gevolgen zoals gerichte benadering of te kijk zetten nauwelijks zelf kunnen afweren. Voor meldplichten geldt de termijn van 72 uur volgens de AVG; de beoordeling maakt de bevoegde functionaris voor gegevensbescherming.
School, Moodle en beveiliging: de vraag van de verantwoordelijkheid
| Beheermodel | Wie patcht PHP | Wat de school moet controleren |
|---|---|---|
| Centraal door de deelstaat of een landelijk instituut | Beheerder van de deelstaat | eigen aanvullende systemen van de school |
| Via het schoolbestuur of een mediacentrum | IT van het bestuur | schriftelijke bevestiging opvragen |
| Externe dienstverlener | Dienstverlener volgens contract | of PHP uitdrukkelijk in het contract staat |
| Eigen server, beheerd door een leraar | de school zelf | tijd, kennis en vervanging |
Het laatste model is verbreider dan veel mensen denken. Een betrokken leraar heeft Moodle jaren geleden opgezet en onderhoudt het er een beetje bij. Bij een kritiek lek ontbreken dan tijd, vervanging en vaak ook de rechten om snel te handelen.
Een update van Moodle sluit PHP2Shell niet. Het lek is pas verholpen met PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35 of een bevestigde backport, en pas na de herstart van alle PHP-processen.
Wat een storing voor onderwijs en examens betekent
Valt Moodle uit, dan ontbreken materiaal en inlevermogelijkheden. In toetsperiodes of vlak voor rapporten is dat bijzonder delicaat. Toch geldt: liever een platform enkele uren gecontroleerd uitschakelen dan het ongepatcht laten draaien. Een gecompromitteerd systeem kan ingeleverd werk vervalsen of accounts van leraren overnemen.
Plan daarom een eenvoudige noodroute, bijvoorbeeld inleveren via een ander, niet getroffen systeem, en informeer leraren, leerlingen en ouders kort over de reden.
Na een opschoning loont een blik op de accounts. Scholen hebben veel gebruikers met uitgebreide rechten: leraren, stagiairs, vakgroepvoorzitters, voormalige collega's wier toegang nooit is verwijderd. Verweesde accounts met lerarenrechten zijn een gemakkelijke weg terug in het platform. Een vergelijking met de actuele personeelslijst van de school sluit die deur, en accounts met beheerdersrechten moeten tot weinig personen beperkt zijn.
Bijzonderheden bij opleidingsinstituten en bijscholing
Particuliere opleidingsinstituten, volksuniversiteiten en aanbieders van bijscholing werken vaak met volwassen deelnemers, maar met meer economische gegevens: cursusboekingen met betaalgegevens, facturen aan zakelijke klanten, stukken over gesubsidieerde trajecten, examenresultaten en certificaten. De leeromgeving is hier vaak verbonden met boekingssysteem en boekhouding.
Een aanval kan daarom ook certificaten en examenresultaten treffen. Wie gegevens in het platform kan wijzigen, kan geslaagd-vermeldingen vervalsen of bewijzen uitgeven die nooit zijn behaald. Laat na een incident controleren of beoordelingen en certificaten achteraf zijn gewijzigd en vergelijk ze met uw examenadministratie.
Eerste stappen voor schoolleiding en bestuur
- Stel vast wie Moodle, website en cloud beheert en laat telkens patchstatus en herstart schriftelijk bevestigen.
- Zet niet-bevestigde systemen in onderhoudsmodus of haal ze van het netwerk.
- Laat logs vanaf 20 oktober 2026 veiligstellen.
- Controleer beheerdersaccounts: zijn er nieuwe of onbekende beheerders?
- Informeer de functionaris voor gegevensbescherming en het schoolbestuur.
Hoe helpt PHP SOS concreet?
- Wij stemmen af met schoolleiding, bestuur en de verzorgende leraar en stellen vast wie welk systeem verantwoordt.
- Via de PHP2Shell-spoedhulp patchen wij PHP, herstarten alle workers en tonen het resultaat aan.
- Wij controleren Moodle-gegevensmap, database en beheerdersaccounts op sporen van een aanval.
- Daarna verzorgen wij de serverhardening, zodat het platform niet meer van één persoon afhangt.
Veelgestelde vragen
Onze Moodle wordt via de deelstaat beheerd. Moeten wij iets doen?
Wordt Moodle centraal beheerd door de deelstaat of een landelijk instituut, dan ligt de patch bij de beheerder. De school moet toch nagaan of er daarnaast eigen systemen zijn, zoals de schoolwebsite of een zelf beheerde cloud. Die liggen meestal onder verantwoordelijkheid van school of schoolbestuur.
Is een Moodle-update genoeg tegen PHP2Shell?
Nee. PHP2Shell treft PHP zelf, waarop Moodle draait. Nodig zijn gepatcht PHP en de herstart van alle PHP-processen. Welke PHP-versie uw Moodle-versie ondersteunt, controleert u in de systeemvereisten op moodle.org.
Wie is verantwoordelijk bij een datalek op school?
De verantwoordelijkheid is, afhankelijk van de deelstaat, verdeeld over school, schoolleiding en schoolbestuur. Voor de beoordeling van meldplichten is de bevoegde functionaris voor gegevensbescherming het eerste aanspreekpunt. De verantwoordelijkheden moeten vóór een incident schriftelijk zijn geregeld.