Kort gezegd: MediaWiki-beveiliging begint na PHP2Shell bij de PHP van de server, want de kwetsbaarheid zit daar en niet in de wiki. Interne wiki's worden vaak jarenlang niet aangeraakt en draaien op oude PHP-versies. Controleer de status op Special:Version, patch en herstart en controleer daarna LocalSettings.php, images en de interface-beheerders.
Waarom interne wiki's een lonend doelwit zijn
MediaWiki dient in veel bedrijven, overheden en onderzoeksinstellingen als intern handboek. Daar staan werkwijzen, contactpersonen, netwerkplattegronden, handleidingen voor servers en soms zelfs toegangsgegevens die er niet thuishoren. Voor een aanvaller is zo'n wiki een kaart van het bedrijf.
De PHP-kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 maken het volgens het PHP-team mogelijk om op afstand en zonder inloggen schadelijke code uit te voeren. Een wiki die "alleen intern" bedoeld was maar via het internet bereikbaar is, is daarmee rechtstreeks kwetsbaar. En omdat wiki's zelden in de aandacht van de IT staan, draaien ze vaak op oude servers, vaak nog met PHP als Apache-module, de uitvoeringsmodus met het hoogste risico volgens het PHP-team.
MediaWiki-beveiliging: PHP-versie en patchstatus controleren
De pagina Special:Version toont de versie van MediaWiki, PHP en de database, plus alle geïnstalleerde extensies en skins. Verholpen upstreamversies zijn 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Veel wikiservers draaien op Linux-distributies met backports; het getoonde nummer blijft dan gelijk, ook al is er gepatcht.
Draait de wiki op PHP 8.1 of ouder, dan zijn er van het PHP-project geen officiële updates meer, alleen minimale backports van de broncode voor 7.4, 8.0 en 8.1. Wat dan geldt, vat PHP 8.1 en ouder samen. Welke PHP-versies uw MediaWiki-versie ondersteunt, controleert u volgens de systeemeisen op mediawiki.org. Een PHP-wissel kan een MediaWiki-upgrade vereisen.
Onderhoudsscripts en jobrunners draaien via de opdrachtregel-PHP. Ook die versie moet zijn gepatcht. Draait de jobwachtrij als permanente dienst, dan moet die na de update net zo goed herstarten als de webserver of PHP-FPM. Bij mod_php betekent dat een herstart van Apache zelf, want PHP zit daar in het webserverproces.
Zoek bovendien uit van wie de wiki is. Interne wiki's zijn vaak door een vakafdeling opgezet en draaien buiten het normale serveronderhoud. Zonder duidelijke verantwoordelijkheid blijft de PHP-update daar het langst liggen.
Mappen en bestanden in MediaWiki
| Plek | Inhoud | Controlepunt |
|---|---|---|
LocalSettings.php |
Databasetoegang, $wgSecretKey, $wgUpgradeKey, rechten, uploadinstellingen |
ingevoegde code, sleutels bij vermoeden vernieuwen |
images/ |
geüploade bestanden en voorbeeldafbeeldingen | geen PHP-bestanden, geen PHP-uitvoering |
extensions/, skins/ |
Extensies en ontwerpen | onbekende of gewijzigde bestanden |
cache/ |
Tussengeheugen | na reiniging legen |
maintenance/ |
Onderhoudsscripts voor de opdrachtregel | niet via het web gebruiken |
De uploadmap mag op webserverniveau geen scripts uitvoeren. Onder Apache lukt dat onafhankelijk van de PHP-uitvoeringsmodus zo:
<Directory "/var/www/wiki/images">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Een ongevaarlijke eerste controle:
find images -type f -name "*.php*"
ls -l LocalSettings.php
Controleer de pagina's MediaWiki:Common.js en MediaWiki:Common.css in de versiegeschiedenis. Wijzigingen daar werken voor elke bezoeker van de wiki en zijn een typische plek voor binnengebrachte code.
Rechten, groepen en extensies
In MediaWiki bepalen gebruikersgroepen de beveiliging. Controleer onder Special:ListUsers en Special:UserRights wie tot de groepen beheerders, bureaucraten en interface-beheerders behoort. Interface-beheerders kunnen het JavaScript van de hele wiki wijzigen; die groep moet zeer klein zijn.
Voor een interne wiki moet lezen zonder aanmelding zijn uitgeschakeld en de registratie van nieuwe accounts geblokkeerd. Sta uploads alleen toe voor de bestandstypen die echt nodig zijn. Extensies brengen eigen PHP-code mee; niet-onderhouden extensies remmen bovendien elke upgrade af. Voor bestandsrechten op de server biedt de gids Bestandsrechten op de webserver een richtlijn.
Wat een MediaWiki-update wel en niet kan
Een MediaWiki-update vervangt de core en dicht daarin bekende fouten. Ze patcht PHP niet, herstart geen PHP-processen, verandert niets aan LocalSettings.php en verwijdert noch bestanden in images/ noch wijzigingen in MediaWiki:Common.js of extra groepsleden. Ze bewijst ook niet dat niemand vóór de patch heeft meegelezen.
Een snel overzicht geven bovendien de logboeken onder Special:Log. Nieuwe gebruikersaccounts, wijzigingen in groepsrechten en bewerkingen van interfacepagina's sinds 17-10-2026 staan daar met tijdstip vermeld.
Hoe helpt PHP SOS concreet?
- Wij controleren PHP-versie, uitvoeringsmodus en backportstatus van uw wikiserver en laten de herstart bevestigen.
- Wij maken een kopie van logs vanaf 20-10-2026, database en bestanden.
- Wij controleren
LocalSettings.php, uploads, extensies, groepsrechten en de versiegeschiedenis van de interfacepagina's. - In het kader van de PHP2Shell-noodhulp beoordelen wij met u of de wiki openbaar bereikbaar moet blijven.
Veelgestelde vragen
Is MediaWiki getroffen door PHP2Shell?
MediaWiki zelf heeft geen nieuwe kwetsbaarheid, maar draait op PHP. Is de PHP van de server niet gepatcht, dan kan een aanvaller volgens het PHP-team zonder inloggen code uitvoeren. Een MediaWiki-update sluit de kwetsbaarheid niet.
Waar zie ik de PHP-versie van mijn wiki?
Op de pagina Special:Version toont MediaWiki de geïnstalleerde software, waaronder de PHP-versie. Of er een backport is doorgevoerd, herkent u daaraan niet; dat bevestigt de beheerder van de server.
Waarom is MediaWiki:Common.js een risico?
De inhoud van deze pagina wordt als JavaScript aan alle bezoekers van de wiki geleverd. Wie haar kan wijzigen, kan code uitvoeren in de browser van elke gebruiker. Daarom moet de groep interface-beheerders zeer klein zijn.
Volstaat het de wiki alleen intern bereikbaar te maken?
Een wiki die alleen in het bedrijfsnetwerk of via VPN bereikbaar is, verlaagt het risico aanzienlijk, omdat aanvallers van het internet er niet rechtstreeks bij kunnen. Patchen moet u toch, want ook vanuit het interne netwerk kan een aanval komen.