Kort sagt: När det gäller Moodle-säkerhet i skolor handlar det om uppgifter om barn och unga, om betyg och om den pågående undervisningen. Klargör först vem som driver er Moodle: delstaten, skolhuvudmannen, en leverantör eller en engagerad lärare. Av det beror vem som patchar PHP, startar om och levererar underlaget.
Vilka PHP-system som körs i skolor och utbildningsverksamheter
I centrum står ofta lärplattformen Moodle. Dessutom finns skolans webbplats, ofta på WordPress eller Joomla, verktyg för vikariescheman, föräldrabrev och anmälningsformulär, bokningssystem för lokaler och utrustning samt filförvaring som Nextcloud. Nästan allt detta körs på PHP.
Hos privata utbildningsanordnare, vuxenutbildningar (Volkshochschulen) och aktörer inom fortbildning tillkommer kursbokning, deltagarhantering och onlineprov. Här är lärplattformen ofta direkt kopplad till fakturering och deltagaruppgifter.
Vilka uppgifter som finns i Moodle och liknande
En lärplattform innehåller mer än arbetsblad: namn och klasser för elever, inlämningar, bedömningar och feedback, forumsinlägg, meddelanden mellan lärare och elever, hos utbildningsanordnare även deltagarintyg och provresultat. Enstaka gånger finns uppgifter om stödbehov eller hälsomässiga begränsningar, som kan höra till de särskilda kategorierna enligt art. 9 GDPR.
De berörda är till övervägande del minderåriga. Det höjer risken vid ett dataläckage, eftersom barn knappast själva kan värja sig mot följder som riktad kontakt eller utpekande. För anmälningsskyldighet gäller 72-timmarsfristen enligt GDPR, och bedömningen görs av ansvarigt dataskyddsombud.
Skola, Moodle och säkerhet: frågan om ansvar
| Driftmodell | Vem patchar PHP | Vad skolan bör kontrollera |
|---|---|---|
| Centralt av delstaten eller ett delstatligt institut | Delstatens driftansvarige | skolans egna tilläggssystem |
| Via skolhuvudmannen eller ett mediecentrum | Huvudmannens IT | begär skriftlig bekräftelse |
| Extern leverantör | Leverantören enligt avtalet | om PHP uttryckligen står i avtalet |
| Egen server, sköts av en lärare | skolan själv | tid, kunskap och ersättare |
Den sista modellen är mer utbredd än många tror. En engagerad lärare har installerat Moodle för flera år sedan och sköter det vid sidan av. Vid en kritisk sårbarhet saknas då tid, ersättare och ofta även behörighet för att agera snabbt.
En uppdatering av Moodle stänger inte PHP2Shell. Sårbarheten är åtgärdad först med PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 eller en bekräftad backport, och först efter omstart av alla PHP-processer.
Vad ett avbrott betyder för undervisning och prov
Faller Moodle bort saknas material och möjlighet att lämna in. Under provperioder eller strax före betygen är det särskilt känsligt. Trots det gäller: Hellre stänga av en plattform ordnat några timmar än låta den fortsätta köra ej patchad. Ett komprometterat system kan förfalska inlämningar eller kapa lärarkonton.
Planera därför en enkel reservväg, till exempel inlämning via ett annat, icke berört system, och informera lärare, elever och föräldrar kort om orsaken.
Efter en rensning lönar sig en titt på kontona. Skolor har många användare med utökade rättigheter: lärare, lärarkandidater, ämnesansvariga, tidigare kollegor vars åtkomster aldrig raderats. Föräldralösa konton med lärarbehörighet är en bekväm väg tillbaka in i plattformen. En avstämning mot skolans aktuella personallista stänger den dörren, och konton med administratörsrättigheter bör begränsas till ett fåtal personer.
Särskilt för utbildningsanordnare och fortbildning
Privata utbildningsanordnare, vuxenutbildningar och aktörer inom fortbildning arbetar ofta med vuxna deltagare, men med mer ekonomiska uppgifter: kursbokningar med betalningsuppgifter, fakturor till företagskunder, handlingar om understödda insatser, provresultat och certifikat. Lärplattformen är här ofta kopplad till bokningssystem och bokföring.
Ett angrepp kan därför också beröra certifikat och provresultat. Den som kan ändra uppgifter i plattformen kan förfalska godkändanteckningar eller utfärda intyg som aldrig förvärvats. Låt efter en incident kontrollera om bedömningar och certifikat har ändrats i efterhand, och stäm av dem mot era provhandlingar.
Första stegen för skolledning och huvudman
- Klargör vem som driver Moodle, webbplats och moln och låt för vart och ett patchnivå och omstart bekräftas skriftligen.
- Sätt obekräftade system i underhållsläge eller ta dem offline.
- Låt säkra loggar från och med den 20 oktober 2026.
- Kontrollera adminkonton: Finns det nya eller okända administratörer?
- Informera dataskyddsombud och skolhuvudman.
Hur hjälper PHP SOS konkret?
- Vi samordnar med skolledning, huvudman och ansvarig lärare och klarlägger vem som ansvarar för vilket system.
- Via PHP2Shell-direkthjälpen patchar vi PHP, startar om alla workers och styrker resultatet.
- Vi kontrollerar Moodles datakatalog, databas och adminkonton efter spår av ett angrepp.
- Därefter tar vi över serverhärdningen, så att plattformen inte längre beror på en enskild person.
Vanliga frågor
Vår Moodle körs via delstaten. Måste vi göra något?
Om Moodle drivs centralt av delstaten eller ett delstatligt institut ligger patchen hos driftansvarig. Skolan bör ändå kontrollera om det vid sidan av finns egna system, till exempel skolans webbplats eller ett egendrivet moln. De ligger oftast inom skolans eller skolhuvudmannens ansvar.
Räcker en Moodle-uppdatering mot PHP2Shell?
Nej. PHP2Shell berör PHP självt, som Moodle körs på. Det som behövs är en patchad PHP och omstart av alla PHP-processer. Vilken PHP-version er Moodle-version stöder kontrollerar ni i systemkraven på moodle.org.
Vem är ansvarig vid ett dataläckage på skolan?
Ansvaret fördelas beroende på förbundsland mellan skola, skolledning och skolhuvudman. För bedömningen av anmälningsskyldighet är det ansvariga dataskyddsombudet första adress. Ansvarsfördelningen bör vara skriftligt klarlagd före en incident.