Накратко: Сигурността на MediaWiki след PHP2Shell започва от PHP на сървъра, защото уязвимостта е там, а не в уикито. Вътрешните уикита често години наред не се пипат и работят на стари версии на PHP. Проверете състоянието на Special:Version, пачнете и рестартирайте и после контролирайте LocalSettings.php, images и Interface администраторите.
Защо вътрешните уикита са примамлива цел
MediaWiki служи във много фирми, институции и изследователски организации като вътрешно ръководство. Там стоят процеси, лица за контакт, мрежови планове, инструкции за сървъри и понякога дори данни за достъп, които не принадлежат там. За нападателя такова уики е карта на фирмата.
PHP уязвимостите CVE-2026-109618 и CVE-2026-109619 позволяват според екипа на PHP изпълнение на злонамерен код от разстояние без вход в системата. Уики, което е било замислено „само вътрешно“, но е достъпно през интернет, е с това пряко уязвимо. А тъй като уикитата рядко са във фокуса на ИТ, те често работят на стари сървъри, често още с PHP като модул на Apache, режимът на работа с най-висок риск според екипа на PHP.
Сигурност на MediaWiki: проверка на версията на PHP и на състоянието на пача
Страницата Special:Version показва версията на MediaWiki, на PHP и на базата данни, както и всички инсталирани разширения и скинове. Поправените версии на оригиналния проект са 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Много сървъри с уики работят на Linux дистрибуции с backport-ове; показаният номер остава тогава същият, макар да е пачнато.
Ако уикито работи на PHP 8.1 или по-стара, от проекта PHP няма вече официални актуализации, а само минимални backport корекции в изходния код за 7.4, 8.0 и 8.1. Какво важи тогава, обобщава PHP 8.1 и по-стари. Кои версии на PHP поддържа Вашата версия на MediaWiki, проверете според системните изисквания на mediawiki.org. Смяната на PHP може да изисква надграждане на MediaWiki.
Скриптовете за поддръжка и job runner работят през PHP за командния ред. И тази версия трябва да е пачната. Ако опашката от задачи работи като постоянна услуга, тя трябва след актуализацията да се рестартира също като уеб сървъра или PHP-FPM. При mod_php това означава рестартиране на самия Apache, защото PHP е там в процеса на уеб сървъра.
Изяснете освен това на кого принадлежи уикито. Вътрешните уикита често са създадени от отдел и работят извън нормалната поддръжка на сървърите. Без ясна отговорност актуализацията на PHP там остава най-дълго.
Директории и файлове в MediaWiki
| Място | Съдържание | Какво да проверите |
|---|---|---|
LocalSettings.php |
достъп до базата данни, $wgSecretKey, $wgUpgradeKey, права, настройки за качване |
вмъкнат код, при подозрение подновете ключовете |
images/ |
качени файлове и умалени изображения | без PHP файлове, без изпълнение на PHP |
extensions/, skins/ |
разширения и дизайни | непознати или променени файлове |
cache/ |
междинна памет | изпразнете след почистване |
maintenance/ |
скриптове за поддръжка за командния ред | не ги ползвайте през уеб |
Директорията за качване не бива да изпълнява скриптове на ниво уеб сървър. При Apache това става независимо от режима на работа на PHP така:
<Directory "/var/www/wiki/images">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Безопасна първа проверка:
find images -type f -name "*.php*"
ls -l LocalSettings.php
Проверете страниците MediaWiki:Common.js и MediaWiki:Common.css в историята на версиите. Промените там действат за всеки посетител на уикито и са типично място за внедрен код.
Права, групи и разширения
В MediaWiki за сигурността решават потребителските групи. Проверете под Special:ListUsers и Special:UserRights кой принадлежи към групите администратори, бюрократи и Interface администратори. Interface администраторите могат да променят JavaScript на цялото уики; тази група трябва да е много малка.
За вътрешно уики четенето без вход трябва да е изключено, а регистрацията на нови акаунти – блокирана. Качвания разрешавайте само за типовете файлове, които наистина са нужни. Разширенията носят собствен PHP код; неподдържаните разширения освен това спират всяко надграждане. За правата върху файловете на сървъра ръководството Права върху файловете на уеб сървъра дава ориентир.
Какво може актуализацията на MediaWiki и какво не
Актуализация на MediaWiki заменя ядрото и затваря известни грешки в него. Тя не пачва PHP, не рестартира PHP процеси, не променя нищо в LocalSettings.php и не премахва нито файлове в images/, нито промени в MediaWiki:Common.js, нито допълнителни членове на групи. Тя не доказва и че преди пача никой не е четял.
Бърз преглед дават освен това дневниците под Special:Log. Нови потребителски акаунти, промени в правата на групите и редакции на интерфейсни страници от 17.10.2026 г. нататък са отбелязани там с момента.
Как помага PHP SOS конкретно?
- Проверяваме версията на PHP, режима на работа и състоянието на backport-овете на Вашия сървър с уики и получаваме потвърждение за рестартирането.
- Запазваме логове от 20.10.2026 г. нататък, базата данни и файловете.
- Проверяваме
LocalSettings.php, качванията, разширенията, правата на групите и историята на версиите на интерфейсните страници. - В рамките на спешната помощ срещу PHP2Shell оценяваме с Вас дали уикито трябва да остане публично достъпно.
Често задавани въпроси
Засегнат ли е MediaWiki от PHP2Shell?
Самият MediaWiki няма нова уязвимост, но работи на PHP. Ако PHP на сървъра не е пачнат, според екипа на PHP нападател може да изпълнява код без вход в системата. Актуализацията на MediaWiki не затваря уязвимостта.
Къде виждам версията на PHP на моето уики?
На страницата Special:Version MediaWiki изброява инсталирания софтуер, включително версията на PHP. Дали е внесен backport, не се познава по нея; това потвърждава операторът на сървъра.
Защо MediaWiki:Common.js е риск?
Съдържанието на тази страница се доставя като JavaScript на всички посетители на уикито. Който може да я променя, може да изпълнява код в браузъра на всеки потребител. Затова групата на Interface администраторите трябва да е много малка.
Достатъчно ли е уикито да е достъпно само вътрешно?
Уики само във фирмената мрежа или през VPN намалява значително риска, защото нападатели от интернет не го достигат директно. Пачването пак е нужно, защото атака може да дойде и от вътрешната мрежа.