Kort sagt: Moodle-sikkerhed afhænger efter PHP2Shell af serverens PHP, ikke af Moodle. Fordi læringsplatforme behandler data om elever, studerende og ansatte, er hurtig handling vigtig. Patch PHP til web og cron, genstart alle processer, og kontrollér config.php, moodledata, plugins og admin-konti.
Hvad PHP2Shell betyder for Moodle-driftsansvarlige
Moodle er udbredt på skoler, højere læreanstalter, i voksen- og efteruddannelse og til interne kurser i virksomheder. Platformen administrerer navne, e-mailadresser, kursustilhørsforhold, karakterer, eksamensafleveringer og forumindlæg, på skoler ofte fra mindreårige. PHP-sårbarhederne CVE-2026-109618 og CVE-2026-109619 gør det ifølge PHP-teamet muligt at køre skadelig kode på afstand uden login.
Moodle-servere kan næsten altid nås fra internettet, fordi de lærende arbejder hjemmefra. BSI (det tyske forbundsagentur for informationssikkerhed) anbefaler ved advarselsniveau 3 en øjeblikkelig opdatering og, hvis det ikke er muligt, at tage webservere midlertidigt af nettet. For skoler og uddannelsesudbydere er det organisatorisk vanskeligt, men muligt at planlægge. Branchespecifikke råd finder I under IT-sikkerhed for skoler og uddannelsesudbydere.
Moodle-sikkerhed: kontrollér PHP-versionen for web og cron
Under Webstedsadministration > Server > Miljø kontrollerer Moodle PHP-versionen og yderligere krav. Under Server > PHP-info ser administratorer desuden de fulde PHP-oplysninger. Begge dele beskriver web-PHP.
Moodle har desuden brug for et cronjob, der regelmæssigt kører admin/cli/cron.php via kommandolinje-PHP. Denne version kan afvige og skal ligeledes være patchet. Rettede upstream-versioner er 8.5.12, 8.4.27, 8.3.36 og 8.2.35; backports bærer ofte ældre numre. Hvilke PHP-versioner jeres Moodle-version understøtter, kontrollerer I ifølge systemkravene i dokumentationen på moodle.org. Hvordan I bagefter genstarter alle processer korrekt, står under Genstart PHP-FPM og alle workers.
Mapper og konfiguration i Moodle
| Sted | Indhold | Kontrolpunkt |
|---|---|---|
config.php |
Databaseadgang, wwwroot, sti til moodledata |
indskudt kode, skift adgangskode ved mistanke |
moodledata/ |
Filopbevaring, afleveringer, sessioner, caches | uden for dokumentroden, ingen PHP-filer |
mod/, blocks/, local/, theme/ |
Aktiviteter, blokke, lokale udvidelser, designs | ukendte eller ændrede plugins |
admin/cli/ |
Kommandolinje-scripts | kun brugbare via CLI |
Moodle tilbyder en indstilling, der forhindrer ændring af programstier via weboverfladen. Den hører hjemme i config.php og gør det sværere at kalde programmer på serveren via en kapret admin-konto:
$CFG->preventexecpath = true;
Ufarlige kontroller på kommandolinjen, som webserverens bruger:
# Udskriv Moodles egne status- og sikkerhedskontroller
php admin/cli/checks.php
php admin/cli/checks.php --type=security
# Søg efter PHP-filer i datamappen (tilpas stien)
find /pfad/zu/moodledata -type f -name "*.php"
Ved mistanke om dataudslip på en skole eller en højere læreanstalt er der hurtigt flere parter involveret: skoleledelse, ejer, databeskyttelsesrådgivere og eventuelt tilsynsmyndigheden. Sikr logs fra 20.10.2026, og dokumentér hver foranstaltning med klokkeslæt.
Plugins, admin-konti og uploads
Et praktisk råd til planlægningen: PHP-opdateringer og genstarter bør ikke falde i eksamensperioder eller under igangværende online-tests. Moodle har en vedligeholdelsestilstand, som underretter brugerne på forhånd. Mod PHP2Shell beskytter den dog ikke, fordi også vedligeholdelsessiden leveres af PHP.
Moodle lever af plugins: aktiviteter, eksamensværktøjer, integrationer til videokonferencer og skoleadministration. Hvert plugin er yderligere PHP-kode og skal passe til Moodle-versionen. Under Webstedsadministration viser Moodle tilgængelige opdateringer til core og plugins. Fjern plugins, som ingen længere bruger, fuldstændigt.
Kontrollér listen over webstedsadministratorer og globale roller med vidtgående rettigheder. Lærere og kursusoprettere har som regel ikke brug for globale rettigheder. Aktivér totrinsgodkendelse i det mindste for administratorer. Tilladte filtyper til uploads bør være så snævre som muligt; råd hertil findes i Implementér filuploads i PHP sikkert.
Hvad en Moodle-opdatering kan, og hvad den ikke kan
En Moodle-opdatering lukker fejl i Moodle og gør ofte nyere PHP-versioner mulige. Den patcher ikke PHP, genstarter hverken web- eller cron-processer og fjerner ingen fremmede filer fra moodledata, ingen ekstra administratorer og ingen ændrede plugins. Om der i tiden før rettelsen er sivet data ud, besvarer en opdatering heller ikke.
Moodle logger desuden logins og handlinger i egne logs, som administratorer ser under Webstedsadministration > Rapporter. Søg dér målrettet efter påfaldende logins fra administratorer, nye konti med globale roller og plugin-installationer siden 17.10.2026. Eksportér disse poster, før automatiske oprydninger sletter ældre data. Rapporterne supplerer webserverens logs, men erstatter dem ikke.
Hvordan hjælper PHP SOS konkret?
- Vi afklarer ansvaret for PHP og lader patch-status og genstart af web og cron bekræfte.
- Vi sikrer logs, database og
moodledatafør enhver ændring. - Vi kontrollerer konfiguration, plugins, administratorer, roller og uploads.
- På ønske vedligeholder vi platformen løbende i sikkerhedsvedligeholdelsesaftalen, afstemt med skoleår og eksamensperioder.
Ofte stillede spørgsmål
Er Moodle berørt af PHP2Shell?
Moodle har ikke selv en ny sårbarhed, men kører på PHP. Er serverens PHP upatchet, kan en angriber ifølge PHP-teamet køre kode uden login. En Moodle-opdatering ændrer ikke ved det.
Hvor ser jeg PHP-versionen i Moodle?
Under Webstedsadministration > Server > Miljø kontrollerer Moodle PHP-versionen mod sine krav. Om en backport er indspillet, viser Moodle ikke; det bekræfter serverens driftsansvarlige.
Hvorfor skal moodledata ligge uden for webmappen?
Dér ligger uploadede filer, afleveringer, sessioner og caches. Er mappen tilgængelig via nettet, kan indhold muligvis hentes direkte. Moodle kræver derfor et sted uden for dokumentroden.
Hvem er ansvarlig for PHP-opdateringen på skoler?
Det er forskelligt: skoleejeren, en delstatsvirksomhed, et kommunalt datacenter eller en tjenesteudbyder. Afklar ansvaret skriftligt, og lad jer bekræfte patch-status og genstart.