Kort sagt: Moodle-säkerheten hänger efter PHP2Shell på serverns PHP, inte på Moodle. Eftersom lärplattformar behandlar uppgifter om elever, studerande och anställda är det viktigt att agera snabbt. Patcha PHP för webb och cron, starta om alla processer och kontrollera config.php, moodledata, plugin och administratörskonton.
Vad PHP2Shell betyder för Moodle-driftansvariga
Moodle är utbrett i skolor, högskolor, vuxenutbildning och för interna utbildningar i företag. Plattformen hanterar namn, e-postadresser, kurstillhörighet, betyg, inlämningar och forumsinlägg, i skolor ofta från minderåriga. PHP-sårbarheterna CVE-2026-109618 och CVE-2026-109619 gör det enligt PHP-teamet möjligt att köra skadlig kod på distans utan inloggning.
Moodle-servrar är nästan alltid nåbara från internet, eftersom elever arbetar hemifrån. BSI (den tyska federala myndigheten för informationssäkerhet) rekommenderar vid varningsnivå 3 omedelbar uppdatering och, om det inte går, att webbservrar tillfälligt tas offline. För skolor och utbildningsanordnare är det organisatoriskt svårt, men går att planera. Branschspecifika råd finns under IT-säkerhet för skolor och utbildningsanordnare.
Moodle-säkerhet: kontrollera PHP-versionen för webb och cron
Under Webbplatsadministration > Server > Miljö kontrollerar Moodle PHP-versionen och andra krav. Under Server > PHP-info ser administratörer dessutom de fullständiga PHP-uppgifterna. Båda beskriver webb-PHP.
Moodle behöver dessutom ett cronjobb som regelbundet kör admin/cli/cron.php via kommandoradens PHP. Den versionen kan avvika och måste också vara patchad. Åtgärdade upstream-versioner är 8.5.12, 8.4.27, 8.3.36 och 8.2.35; backports bär ofta äldre nummer. Vilka PHP-versioner er Moodle-version stöder kontrollerar ni enligt systemkraven i dokumentationen på moodle.org. Hur ni därefter startar om alla processer på ett rent sätt står under Starta om PHP-FPM och alla workers.
Kataloger och konfiguration i Moodle
| Plats | Innehåll | Kontrollpunkt |
|---|---|---|
config.php |
Databasåtkomst, wwwroot, sökväg till moodledata |
inskjuten kod, byt lösenord vid misstanke |
moodledata/ |
Fillagring, inlämningar, sessioner, cacher | utanför dokumentroten, inga PHP-filer |
mod/, blocks/, local/, theme/ |
Aktiviteter, block, lokala tillägg, teman | okända eller ändrade plugin |
admin/cli/ |
Kommandoradsskript | endast användbara via CLI |
Moodle har en inställning som förhindrar att programsökvägar ändras via webbgränssnittet. Den hör hemma i config.php och försvårar att program på servern anropas via ett kapat administratörskonto:
$CFG->preventexecpath = true;
Ofarliga kontroller på kommandoraden, som webbserverns användare:
# Skriv ut Moodles egna status- och säkerhetskontroller
php admin/cli/checks.php
php admin/cli/checks.php --type=security
# Sök efter PHP-filer i datakatalogen (anpassa sökvägen)
find /pfad/zu/moodledata -type f -name "*.php"
Vid misstanke om dataläckage i en skola eller högskola blir snabbt flera parter inblandade: rektor, huvudman, dataskyddsombud och i förekommande fall tillsynsmyndigheten. Säkra loggar från och med den 20 oktober 2026 och dokumentera varje åtgärd med klockslag.
Plugin, administratörskonton och uppladdningar
Ett praktiskt råd för planeringen: PHP-uppdateringar och omstarter bör inte läggas i provperioder eller under pågående onlinetester. Moodle har ett underhållsläge som informerar användarna i förväg. Mot PHP2Shell skyddar det dock inte, eftersom även underhållssidan levereras av PHP.
Moodle lever på plugin: aktiviteter, provverktyg, kopplingar till videokonferenser och skoladministration. Varje plugin är extra PHP-kod och måste passa Moodle-versionen. Under Webbplatsadministration visar Moodle tillgängliga uppdateringar för kärna och plugin. Ta bort plugin som ingen längre använder helt och hållet.
Kontrollera listan över webbplatsadministratörer och globala roller med vittgående rättigheter. Lärare och kursskapare behöver oftast inga globala rättigheter. Aktivera tvåfaktorsinloggning åtminstone för administratörer. Tillåtna filtyper för uppladdningar bör begränsas så snävt som möjligt; råd om det finns i Implementera filuppladdningar i PHP på ett säkert sätt.
Vad en Moodle-uppdatering klarar och inte klarar
En Moodle-uppdatering stänger fel i Moodle och möjliggör ofta nyare PHP-versioner. Den patchar inte PHP, startar varken om webb- eller cron-processer och tar inte bort främmande filer ur moodledata, extra administratörer eller ändrade plugin. Inte heller om data har läckt ut under tiden före patchen besvarar en uppdatering.
Moodle loggar dessutom inloggningar och åtgärder i egna loggar, som administratörer kan se under Webbplatsadministration > Rapporter. Sök där särskilt efter avvikande inloggningar av administratörer, nya konton med globala roller och plugin-installationer sedan den 17 oktober 2026. Exportera dessa poster innan automatiska rensningar raderar äldre data. Rapporterna kompletterar webbserverns loggar men ersätter dem inte.
Hur hjälper PHP SOS konkret?
- Vi klargör ansvaret för PHP och låter patchstatus och omstart av webb och cron bekräftas.
- Vi säkrar loggar, databas och
moodledataföre varje ändring. - Vi kontrollerar konfiguration, plugin, administratörer, roller och uppladdningar.
- På begäran sköter vi plattformen löpande i säkerhetsunderhållsavtalet, anpassat efter läsår och provperioder.
Vanliga frågor
Berörs Moodle av PHP2Shell?
Moodle självt har ingen ny sårbarhet, men körs på PHP. Är serverns PHP opatchat kan en angripare enligt PHP-teamet köra kod utan inloggning. En Moodle-uppdatering ändrar inget i det.
Var ser jag PHP-versionen i Moodle?
Under Webbplatsadministration > Server > Miljö kontrollerar Moodle PHP-versionen mot sina krav. Om en backport är installerad visar Moodle inte; det bekräftar serverns driftansvariga.
Varför måste moodledata ligga utanför webbkatalogen?
Där ligger uppladdade filer, inlämningar, sessioner och cacher. Är katalogen nåbar via webben kan innehåll eventuellt hämtas direkt. Moodle kräver därför en plats utanför dokumentroten.
Vem ansvarar för PHP-uppdateringen hos skolor?
Det varierar: skolhuvudman, regional driftorganisation, kommunalt datacenter eller en tjänsteleverantör. Klargör ansvaret skriftligen och låt patchstatus och omstart bekräftas.