Kort sagt: MediaWiki-sikkerhed efter PHP2Shell begynder ved serverens PHP, for sårbarheden sidder dér og ikke i wikien. Interne wikier bliver ofte ikke rørt i årevis og kører på gamle PHP-versioner. Kontrollér status på Speciel:Version, patch og genstart, og kontrollér derefter LocalSettings.php, images og interface-administratorerne.
Hvorfor interne wikier er et attraktivt mål
MediaWiki tjener i mange virksomheder, myndigheder og forskningsinstitutioner som intern håndbog. Dér står arbejdsgange, kontaktpersoner, netværksplaner, vejledninger til servere og indimellem endda adgangsdata, som ikke hører hjemme dér. For en angriber er sådan en wiki et landkort over virksomheden.
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. En wiki, der var tænkt som "kun intern", men kan nås via internettet, er dermed direkte sårbar. Og fordi wikier sjældent er i IT's fokus, kører de ofte på gamle servere, tit stadig med PHP som Apache-modul, den driftsform med den højeste risiko ifølge PHP-teamet.
MediaWiki-sikkerhed: kontrollér PHP-version og patch-status
Siden Speciel:Version viser versionen af MediaWiki, PHP og databasen samt alle installerede udvidelser og skins. Rettede upstream-versioner er 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Mange wiki-servere kører på Linux-distributioner med backports; det viste nummer forbliver så det samme, selv om der er patchet.
Kører wikien på PHP 8.1 eller ældre, findes der ikke længere officielle opdateringer fra PHP-projektet, kun minimale kildekode-backports til 7.4, 8.0 og 8.1. Hvad der så gælder, opsummerer PHP 8.1 og ældre. Hvilke PHP-versioner jeres MediaWiki-version understøtter, kontrollerer I ifølge systemkravene på mediawiki.org. Et PHP-skifte kan forudsætte en MediaWiki-opgradering.
Vedligeholdelsesscripts og job-runners kører via kommandolinje-PHP. Også denne version skal være patchet. Kører job-køen som en vedvarende tjeneste, skal den genstartes efter opdateringen ligesom webserveren eller PHP-FPM. Ved mod_php betyder det en genstart af selve Apache, for PHP sidder dér i webserverprocessen.
Afklar desuden, hvem wikien tilhører. Interne wikier er ofte sat op af en fagafdeling og kører uden for den normale serverpleje. Uden et klart ansvar bliver PHP-opdateringen dér liggende længst.
Mapper og filer i MediaWiki
| Sted | Indhold | Kontrolpunkt |
|---|---|---|
LocalSettings.php |
Databaseadgang, $wgSecretKey, $wgUpgradeKey, rettigheder, upload-indstillinger |
indskudt kode, forny nøgler ved mistanke |
images/ |
uploadede filer og miniaturebilleder | ingen PHP-filer, ingen PHP-kørsel |
extensions/, skins/ |
Udvidelser og designs | ukendte eller ændrede filer |
cache/ |
Mellemlager | tøm efter oprydning |
maintenance/ |
Vedligeholdelsesscripts til kommandolinjen | må ikke bruges via nettet |
Upload-mappen bør på webserverniveau ikke køre scripts. Under Apache gøres det uafhængigt af PHP-driftsformen sådan:
<Directory "/var/www/wiki/images">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
En ufarlig første kontrol:
find images -type f -name "*.php*"
ls -l LocalSettings.php
Kontrollér siderne MediaWiki:Common.js og MediaWiki:Common.css i versionshistorikken. Ændringer dér virker for enhver besøgende i wikien og er et typisk sted for indsmuglet kode.
Rettigheder, grupper og udvidelser
I MediaWiki afgør brugergrupper sikkerheden. Kontrollér under Speciel:Brugere og Speciel:Brugerrettigheder, hvem der tilhører grupperne administratorer, bureaukrater og interface-administratorer. Interface-administratorer kan ændre JavaScriptet i hele wikien; denne gruppe bør være meget lille.
For en intern wiki bør læsning uden login være slået fra og oprettelsen af nye konti spærret. Tillad kun uploads af de filtyper, der virkelig er brug for. Udvidelser medbringer egen PHP-kode; ikke vedligeholdte udvidelser bremser desuden enhver opgradering. Til filrettigheder på serveren giver vejledningen Filrettigheder på webserveren en orientering.
Hvad en MediaWiki-opdatering kan, og hvad den ikke kan
En MediaWiki-opdatering erstatter core og lukker kendte fejl i den. Den patcher ikke PHP, genstarter ikke PHP-processer, ændrer intet i LocalSettings.php og fjerner hverken filer i images/ eller ændringer i MediaWiki:Common.js eller ekstra gruppemedlemmer. Den beviser heller ikke, at ingen har læst med før rettelsen.
Et hurtigt overblik giver desuden logbøgerne under Speciel:Logbog. Nye brugerkonti, ændringer af gruppetilladelser og redigeringer af interface-sider siden 17.10.2026 er noteret dér med tidspunkt.
Hvordan hjælper PHP SOS konkret?
- Vi kontrollerer PHP-version, driftsform og backport-status på jeres wiki-server og lader genstarten bekræfte.
- Vi sikrer logs fra 20.10.2026, database og filer.
- Vi kontrollerer
LocalSettings.php, uploads, udvidelser, gruppetilladelser og versionshistorikken for interface-siderne. - Som led i PHP2Shell-akuthjælpen vurderer vi sammen med jer, om wikien skal forblive offentligt tilgængelig.
Ofte stillede spørgsmål
Er MediaWiki berørt af PHP2Shell?
MediaWiki har ikke selv en ny sårbarhed, men kører på PHP. Er serverens PHP ikke patchet, kan en angriber ifølge PHP-teamet køre kode uden login. En MediaWiki-opdatering lukker ikke sårbarheden.
Hvor ser jeg min wikis PHP-version?
På siden Speciel:Version viser MediaWiki den installerede software, herunder PHP-versionen. Om en backport er indspillet, kan I ikke se heraf; det bekræfter serverens driftsansvarlige.
Hvorfor er MediaWiki:Common.js en risiko?
Indholdet af denne side leveres som JavaScript til alle wikiens besøgende. Den, der kan ændre den, kan køre kode i enhver brugers browser. Derfor bør gruppen af interface-administratorer være meget lille.
Er det nok kun at gøre wikien tilgængelig internt?
En wiki, der kun kan nås i virksomhedens netværk eller via VPN, mindsker risikoen markant, fordi angribere fra internettet ikke kan nå den direkte. I skal alligevel patche, for et angreb kan også komme fra det interne netværk.