Krótko: Bezpieczeństwo MediaWiki po PHP2Shell zaczyna się od PHP serwera, ponieważ luka tkwi tam, a nie w wiki. Wewnętrzne wiki bywają latami nietykane i działają na starych wersjach PHP. Proszę sprawdzić stan na Special:Version, załatać i zrestartować, a następnie skontrolować LocalSettings.php, images oraz administratorów interfejsu.
Dlaczego wewnętrzne wiki są łakomym celem
MediaWiki służy w wielu firmach, urzędach i instytucjach badawczych jako wewnętrzny podręcznik. Znajdują się tam procedury, osoby kontaktowe, plany sieci, instrukcje dla serwerów, a czasem nawet dane dostępowe, które tam nie należą. Dla atakującego takie wiki to mapa firmy.
Luki PHP CVE-2026-109618 i CVE-2026-109619 umożliwiają według zespołu PHP zdalne wykonanie złośliwego kodu bez logowania. Wiki, które miało być „tylko wewnętrzne”, ale jest osiągalne przez internet, jest więc bezpośrednio podatne. A ponieważ wiki rzadko są w centrum uwagi IT, często działają na starych serwerach, nierzadko nadal z PHP jako modułem Apache, czyli trybem pracy o najwyższym ryzyku według zespołu PHP.
Bezpieczeństwo MediaWiki: sprawdzanie wersji PHP i stanu poprawek
Strona Special:Version pokazuje wersję MediaWiki, PHP i bazy danych oraz wszystkie zainstalowane rozszerzenia i skórki. Naprawione wersje upstream to 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Wiele serwerów wiki działa na dystrybucjach Linuksa z backportami; wyświetlany numer pozostaje wtedy ten sam, mimo że system jest załatany.
Jeśli wiki działa na PHP 8.1 lub starszym, projekt PHP nie wydaje już oficjalnych aktualizacji, a jedynie minimalne backporty kodu źródłowego dla 7.4, 8.0 i 8.1. Co wtedy obowiązuje, podsumowuje artykuł PHP 8.1 i starsze. To, które wersje PHP obsługuje Państwa wersja MediaWiki, można sprawdzić w wymaganiach systemowych na mediawiki.org. Zmiana PHP może wymagać aktualizacji MediaWiki.
Skrypty konserwacyjne i job runnery działają przez PHP wiersza poleceń. Ta wersja również musi być załatana. Jeśli kolejka zadań działa jako stała usługa, musi zostać po aktualizacji zrestartowana tak samo jak serwer WWW lub PHP-FPM. Przy mod_php oznacza to restart samego Apache, ponieważ PHP siedzi tam w procesie serwera WWW.
Proszę ponadto ustalić, do kogo należy wiki. Wewnętrzne wiki zakładał często jakiś dział merytoryczny i działają one poza normalną opieką nad serwerami. Bez jasnej odpowiedzialności aktualizacja PHP leży tam najdłużej.
Katalogi i pliki w MediaWiki
| Miejsce | Zawartość | Punkt kontroli |
|---|---|---|
LocalSettings.php |
Dane dostępowe do bazy danych, $wgSecretKey, $wgUpgradeKey, uprawnienia, ustawienia przesyłania |
Dopisany kod, po podejrzeniu odnowić klucze |
images/ |
Przesłane pliki i miniatury | Brak plików PHP, brak wykonywania PHP |
extensions/, skins/ |
Rozszerzenia i motywy | Nieznane lub zmienione pliki |
cache/ |
Pamięć podręczna | Po oczyszczeniu opróżnić |
maintenance/ |
Skrypty konserwacyjne wiersza poleceń | Nie używać przez sieć |
Katalog przesyłania nie powinien wykonywać skryptów na poziomie serwera WWW. Pod Apache działa to niezależnie od trybu pracy PHP tak:
<Directory "/var/www/wiki/images">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Bezpieczna pierwsza kontrola:
find images -type f -name "*.php*"
ls -l LocalSettings.php
Proszę sprawdzić strony MediaWiki:Common.js i MediaWiki:Common.css w historii wersji. Zmiany tam działają na każdego odwiedzającego wiki i są typowym miejscem na wprowadzony kod.
Uprawnienia, grupy i rozszerzenia
W MediaWiki o bezpieczeństwie decydują grupy użytkowników. Proszę sprawdzić w Special:Users i Special:UserRights, kto należy do grup administratorów, biurokratów i administratorów interfejsu. Administratorzy interfejsu mogą zmieniać JavaScript całego wiki; ta grupa powinna być bardzo mała.
W wewnętrznym wiki czytanie bez logowania powinno być wyłączone, a rejestracja nowych kont zablokowana. Przesyłanie plików należy dopuścić tylko dla typów plików, które naprawdę są potrzebne. Rozszerzenia wnoszą własny kod PHP; nieprowadzone rozszerzenia hamują ponadto każdą aktualizację. Orientację w prawach do plików na serwerze daje poradnik Prawa do plików na serwerze WWW.
Co potrafi aktualizacja MediaWiki, a czego nie
Aktualizacja MediaWiki zastępuje rdzeń i zamyka w nim znane błędy. Nie łata PHP, nie restartuje procesów PHP, nie zmienia niczego w LocalSettings.php i nie usuwa ani plików w images/, ani zmian w MediaWiki:Common.js, ani dodatkowych członków grup. Nie dowodzi też, że przed poprawką nikt nie podglądał.
Szybki przegląd dają ponadto dzienniki w Special:Log. Nowe konta użytkowników, zmiany uprawnień grup i edycje stron interfejsu od 17.10.2026 są tam odnotowane wraz z czasem.
Jak konkretnie pomaga PHP SOS?
- Sprawdzamy wersję PHP, tryb pracy i stan backportów na Państwa serwerze wiki i prosimy o potwierdzenie restartu.
- Zabezpieczamy logi od 20.10.2026, bazę danych i pliki.
- Sprawdzamy
LocalSettings.php, przesłane pliki, rozszerzenia, uprawnienia grup i historię wersji stron interfejsu. - W ramach natychmiastowej pomocy przy PHP2Shell oceniamy z Państwem, czy wiki musi pozostać publicznie osiągalne.
Częste pytania
Czy MediaWiki jest dotknięte przez PHP2Shell?
Samo MediaWiki nie ma nowej luki, ale działa na PHP. Jeśli PHP serwera nie jest załatane, atakujący może według zespołu PHP wykonać kod bez logowania. Aktualizacja MediaWiki nie zamyka tej luki.
Gdzie zobaczę wersję PHP mojego wiki?
Na stronie Special:Version MediaWiki wymienia zainstalowane oprogramowanie, w tym wersję PHP. Tego, czy wprowadzono backport, nie widać po numerze; potwierdza to operator serwera.
Dlaczego MediaWiki:Common.js jest ryzykiem?
Zawartość tej strony jest dostarczana jako JavaScript wszystkim odwiedzającym wiki. Kto może ją zmieniać, może wykonywać kod w przeglądarce każdego użytkownika. Dlatego grupa administratorów interfejsu powinna być bardzo mała.
Czy wystarczy udostępnić wiki wyłącznie wewnętrznie?
Wiki dostępne tylko w sieci firmowej lub przez VPN wyraźnie zmniejsza ryzyko, ponieważ atakujący z internetu nie dosięgną go bezpośrednio. Łatać mimo to trzeba, ponieważ atak może przyjść także z sieci wewnętrznej.