Kurz gesagt: MediaWiki-Sicherheit nach PHP2Shell beginnt beim PHP des Servers, denn die Lücke steckt dort und nicht im Wiki. Interne Wikis werden oft jahrelang nicht angefasst und laufen auf alten PHP-Versionen. Prüfen Sie den Stand auf Spezial:Version, patchen und starten Sie neu und kontrollieren Sie danach LocalSettings.php, images und die Interface-Administratoren.
Warum interne Wikis ein lohnendes Ziel sind
MediaWiki dient in vielen Unternehmen, Behörden und Forschungseinrichtungen als internes Handbuch. Dort stehen Abläufe, Ansprechpartner, Netzpläne, Anleitungen für Server und manchmal sogar Zugangsdaten, die dort nicht hingehören. Für einen Angreifer ist ein solches Wiki eine Landkarte des Unternehmens.
Die PHP-Lücken CVE-2026-109618 und CVE-2026-109619 erlauben laut PHP-Team Schadcode aus der Ferne ohne Anmeldung. Ein Wiki, das „nur intern“ gedacht war, aber über das Internet erreichbar ist, ist damit direkt angreifbar. Und weil Wikis selten im Fokus der IT stehen, laufen sie häufig auf alten Servern, oft noch mit PHP als Apache-Modul, der Betriebsart mit dem höchsten Risiko laut PHP-Team.
MediaWiki-Sicherheit: PHP-Version und Patchstand prüfen
Die Seite Spezial:Version zeigt die Version von MediaWiki, PHP und der Datenbank sowie alle installierten Erweiterungen und Skins. Behobene Upstream-Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Viele Wiki-Server laufen auf Linux-Distributionen mit Backports; die angezeigte Nummer bleibt dann gleich, obwohl gepatcht ist.
Läuft das Wiki auf PHP 8.1 oder älter, gibt es vom PHP-Projekt keine offiziellen Updates mehr, nur minimale Quell-Backports für 7.4, 8.0 und 8.1. Was dann gilt, fasst PHP 8.1 und älter zusammen. Welche PHP-Versionen Ihre MediaWiki-Version unterstützt, prüfen Sie laut Systemanforderungen auf mediawiki.org. Ein PHP-Wechsel kann ein MediaWiki-Upgrade voraussetzen.
Wartungsskripte und Job-Runner laufen über das Kommandozeilen-PHP. Auch diese Version muss gepatcht sein. Läuft die Job-Warteschlange als dauerhafter Dienst, muss dieser nach dem Update ebenso neu starten wie der Webserver oder PHP-FPM. Bei mod_php bedeutet das einen Neustart von Apache selbst, denn PHP steckt dort im Webserver-Prozess.
Klären Sie außerdem, wem das Wiki gehört. Interne Wikis wurden oft von einer Fachabteilung aufgesetzt und laufen außerhalb der normalen Server-Pflege. Ohne klare Zuständigkeit bleibt das PHP-Update dort am längsten liegen.
Verzeichnisse und Dateien in MediaWiki
| Ort | Inhalt | Prüfpunkt |
|---|---|---|
LocalSettings.php |
Datenbankzugang, $wgSecretKey, $wgUpgradeKey, Rechte, Upload-Einstellungen |
eingeschobener Code, Schlüssel nach Verdacht erneuern |
images/ |
hochgeladene Dateien und Vorschaubilder | keine PHP-Dateien, keine PHP-Ausführung |
extensions/, skins/ |
Erweiterungen und Designs | unbekannte oder veränderte Dateien |
cache/ |
Zwischenspeicher | nach Bereinigung leeren |
maintenance/ |
Wartungsskripte für die Kommandozeile | nicht über das Web nutzen |
Das Upload-Verzeichnis sollte auf Webserver-Ebene keine Skripte ausführen. Unter Apache geht das unabhängig von der PHP-Betriebsart so:
<Directory "/var/www/wiki/images">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Eine ungefährliche erste Prüfung:
find images -type f -name "*.php*"
ls -l LocalSettings.php
Prüfen Sie die Seiten MediaWiki:Common.js und MediaWiki:Common.css in der Versionsgeschichte. Änderungen dort wirken für jeden Besucher des Wikis und sind ein typischer Ort für eingeschleusten Code.
Rechte, Gruppen und Erweiterungen
In MediaWiki entscheiden Benutzergruppen über die Sicherheit. Prüfen Sie unter Spezial:Benutzer und Spezial:Benutzerrechte, wer zu den Gruppen Administratoren, Bürokraten und Interface-Administratoren gehört. Interface-Administratoren können das JavaScript des gesamten Wikis ändern; diese Gruppe sollte sehr klein sein.
Für ein internes Wiki sollte Lesen ohne Anmeldung abgeschaltet sein und die Registrierung neuer Konten gesperrt. Uploads erlauben Sie nur für die Dateitypen, die wirklich gebraucht werden. Erweiterungen bringen eigenen PHP-Code mit; ungepflegte Erweiterungen bremsen zudem jedes Upgrade. Für Dateirechte auf dem Server gibt der Ratgeber Dateirechte auf dem Webserver eine Orientierung.
Was ein MediaWiki-Update kann und was nicht
Ein MediaWiki-Update ersetzt den Core und schließt bekannte Fehler darin. Es patcht nicht PHP, startet keine PHP-Prozesse neu, ändert nichts an LocalSettings.php und entfernt weder Dateien in images/ noch Änderungen an MediaWiki:Common.js oder zusätzliche Gruppenmitglieder. Es beweist auch nicht, dass vor dem Patch niemand mitgelesen hat.
Einen schnellen Überblick geben außerdem die Logbücher unter Spezial:Logbuch. Neue Benutzerkonten, Änderungen an Gruppenrechten und Bearbeitungen von Interface-Seiten seit dem 17.10.2026 sind dort mit Zeitpunkt vermerkt.
Wie hilft PHP SOS konkret?
- Wir prüfen PHP-Version, Betriebsart und Backport-Stand Ihres Wiki-Servers und lassen den Neustart bestätigen.
- Wir sichern Logs ab dem 20.10.2026, Datenbank und Dateien.
- Wir prüfen
LocalSettings.php, Uploads, Erweiterungen, Gruppenrechte und die Versionsgeschichte der Interface-Seiten. - Im Rahmen der PHP2Shell-Soforthilfe bewerten wir mit Ihnen, ob das Wiki öffentlich erreichbar bleiben muss.
Häufige Fragen
Ist MediaWiki von PHP2Shell betroffen?
MediaWiki selbst hat keine neue Lücke, läuft aber auf PHP. Ist das PHP des Servers nicht gepatcht, kann ein Angreifer laut PHP-Team ohne Anmeldung Code ausführen. Ein MediaWiki-Update schließt die Lücke nicht.
Wo sehe ich die PHP-Version meines Wikis?
Auf der Seite Spezial:Version listet MediaWiki die installierte Software, darunter die PHP-Version. Ob ein Backport eingespielt ist, erkennen Sie daran nicht; das bestätigt der Betreiber des Servers.
Warum ist MediaWiki:Common.js ein Risiko?
Der Inhalt dieser Seite wird als JavaScript an alle Besucher des Wikis ausgeliefert. Wer sie ändern kann, kann Code im Browser jedes Nutzers ausführen. Deshalb sollte die Gruppe der Interface-Administratoren sehr klein sein.
Reicht es, das Wiki nur intern erreichbar zu machen?
Ein Wiki nur im Firmennetz oder per VPN verringert das Risiko deutlich, weil Angreifer aus dem Internet es nicht direkt erreichen. Patchen müssen Sie trotzdem, denn auch aus dem internen Netz kann ein Angriff kommen.