Kort sagt: Ved Moodle-sikkerhed i skoler handler det om data om børn og unge, om karakterer og om den løbende undervisning. Afklar først, hvem der driver jeres Moodle: delstaten, skoleejeren, en tjenesteudbyder eller en engageret lærer. Heraf afhænger det, hvem der patcher PHP, genstarter og leverer dokumentationen.
Hvilke PHP-systemer der kører i skoler og uddannelsesinstitutioner
I centrum står ofte læringsplatformen Moodle. Dertil kommer skolens hjemmeside, ofte på WordPress eller Joomla, værktøjer til vikarplaner, forældrebreve og tilmeldingsformularer, bookingsystemer til lokaler og udstyr samt filarkiver som Nextcloud. Næsten alt dette kører på PHP.
Hos private uddannelsesudbydere, folkeuniversiteter og efteruddannelsesudbydere kommer kursusbooking, deltagerstyring og onlineprøver til. Her er læringsplatformen ofte direkte forbundet med fakturering og deltagerdata.
Hvilke data der ligger i Moodle og lignende
En læringsplatform indeholder mere end arbejdsark: navne og klasser på elever, afleveringer, bedømmelser og feedback, forumindlæg, beskeder mellem lærere og lærende, hos uddannelsesudbydere også deltagelsesbeviser og prøveresultater. Enkelte steder findes der henvisninger til støttebehov eller helbredsmæssige begrænsninger, som kan høre til de særlige kategorier efter art. 9 GDPR.
De berørte er overvejende mindreårige. Det øger risikoen ved et dataudslip, fordi børn næppe selv kan afværge følger som målrettet henvendelse eller blotlæggelse. For anmeldelsespligter gælder GDPR's 72-timersfrist, vurderingen foretager den ansvarlige databeskyttelsesrådgiver.
Skole, Moodle og sikkerhed: spørgsmålet om ansvar
| Driftsmodel | Hvem patcher PHP | Hvad skolen bør kontrollere |
|---|---|---|
| Centralt fra delstaten eller delstatsinstitut | Delstatens driftsoperatør | skolens egne ekstrasystemer |
| Via skoleejeren eller et mediecenter | Ejerens it | anmod om skriftlig bekræftelse |
| Ekstern tjenesteudbyder | Tjenesteudbyder ifølge aftalen | om PHP udtrykkeligt står i aftalen |
| Egen server, passet af en lærer | skolen selv | tid, viden og stedfortræder |
Den sidste model er mere udbredt, end mange tror. En engageret lærer har for år siden sat Moodle op og vedligeholder det ved siden af. Ved en kritisk sårbarhed mangler der så tid, stedfortræder og ofte også rettighederne til at handle hurtigt.
En opdatering af Moodle lukker ikke PHP2Shell. Sårbarheden er først udbedret med PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 eller en bekræftet backport, og først efter genstart af alle PHP-processer.
Hvad et udfald betyder for undervisning og prøver
Falder Moodle ud, mangler materiale og afleveringsmuligheder. I prøveperioder eller kort før karakterbeviser er det særligt vanskeligt. Alligevel gælder: Hellere slukke en platform ordnet i nogle timer end lade den køre videre upatchet. Et kompromitteret system kan forfalske afleveringer eller overtage læreres konti.
Planlæg derfor en enkel erstatningsvej, f.eks. aflevering via et andet, ikke-berørt system, og informér lærere, lærende og forældre kort om årsagen.
Efter en oprydning kan det betale sig at se på kontiene. Skoler har mange brugere med udvidede rettigheder: lærere, vikarer under uddannelse, fagområdeledere, tidligere kolleger, hvis adgange aldrig blev slettet. Forladte konti med lærerrettigheder er en bekvem vej tilbage ind i platformen. En afstemning med skolens aktuelle personaleliste lukker denne dør, og konti med administratorrettigheder bør begrænses til få personer.
Særlige forhold hos uddannelsesudbydere og efteruddannelse
Private uddannelsesudbydere, folkeuniversiteter og efteruddannelsesudbydere arbejder ofte med voksne deltagere, men til gengæld med flere økonomiske data: kursusbookinger med betalingsdata, fakturaer til firmakunder, dokumenter om støttede foranstaltninger, prøveresultater og certifikater. Læringsplatformen er her ofte forbundet med bookingsystem og bogholderi.
Et angreb kan derfor også berøre certifikater og prøveresultater. Den, der kan ændre data i platformen, kan forfalske beståetmarkeringer eller udstede beviser, der aldrig blev erhvervet. Lad efter en hændelse kontrollere, om bedømmelser og certifikater er ændret efterfølgende, og sammenhold dem med jeres prøvedokumenter.
Første skridt for skoleledelse og ejer
- Afklar, hvem der driver Moodle, hjemmeside og sky, og lad i hvert tilfælde patchstatus og genstart bekræfte skriftligt.
- Sæt ikke-bekræftede systemer i vedligeholdelsestilstand, eller tag dem af nettet.
- Lad logs fra 20.10.2026 sikre.
- Kontrollér admin-konti: Findes der nye eller ukendte administratorer?
- Informér databeskyttelsesrådgiveren og skoleejeren.
Hvordan hjælper PHP SOS konkret?
- Vi koordinerer med skoleledelse, ejer og den ansvarlige lærer og afklarer, hvem der er ansvarlig for hvilket system.
- Via PHP2Shell-akuthjælpen patcher vi PHP, genstarter alle workers og dokumenterer resultatet.
- Vi kontrollerer Moodles datamappe, database og admin-konti for spor efter et angreb.
- Derefter overtager vi serverhærdningen, så platformen ikke længere afhænger af en enkelt person.
Ofte stillede spørgsmål
Vores Moodle kører via delstaten. Skal vi gøre noget?
Drives Moodle centralt af delstaten eller et delstatsinstitut, ligger rettelsen hos driftsoperatøren. Skolen bør alligevel undersøge, om der ved siden af findes egne systemer, f.eks. skolens hjemmeside eller en selvdrevet sky. Disse ligger som regel i skolens eller skoleejerens ansvar.
Er en Moodle-opdatering nok mod PHP2Shell?
Nej. PHP2Shell berører selve PHP, som Moodle kører på. Nødvendigt er et patchet PHP og genstart af alle PHP-processer. Hvilken PHP-version jeres Moodle-version understøtter, kontrollerer I i systemkravene på moodle.org.
Hvem er ansvarlig ved et datalæk på skolen?
Ansvaret fordeler sig alt efter delstat mellem skole, skoleledelse og skoleejer. Til vurdering af anmeldelsespligter er den ansvarlige databeskyttelsesrådgiver den første adresse. Ansvarsfordelingen bør være afklaret skriftligt før en hændelse.