Pe scurt: Securitatea MediaWiki după PHP2Shell începe cu PHP-ul serverului, deoarece vulnerabilitatea se află acolo și nu în wiki. Wiki-urile interne nu sunt adesea atinse ani de zile și rulează pe versiuni PHP vechi. Verificați starea pe Special:Version, aplicați patchul și reporniți, apoi controlați LocalSettings.php, images și interface-admins.
De ce wiki-urile interne sunt o țintă rentabilă
MediaWiki servește în multe companii, autorități și instituții de cercetare drept manual intern. Acolo se găsesc procese, persoane de contact, scheme de rețea, instrucțiuni pentru servere și uneori chiar date de acces care nu au ce căuta acolo. Pentru un atacator, un astfel de wiki este o hartă a companiei.
Potrivit echipei PHP, vulnerabilitățile PHP CVE-2026-109618 și CVE-2026-109619 permit execuția de cod malițios la distanță, fără autentificare. Un wiki gândit „doar intern”, dar accesibil prin internet, este astfel direct vulnerabil. Iar deoarece wiki-urile ajung rar în atenția IT-ului, ele rulează adesea pe servere vechi, de multe ori încă cu PHP ca modul Apache, modul de operare cu cel mai ridicat risc potrivit echipei PHP.
Securitatea MediaWiki: verificarea versiunii PHP și a stării patchului
Pagina Special:Version arată versiunea MediaWiki, PHP și a bazei de date, precum și toate extensiile și skin-urile instalate. Versiunile upstream remediate sunt 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Multe servere de wiki rulează pe distribuții Linux cu backporturi; numărul afișat rămâne atunci același, deși patchul este aplicat.
Dacă wiki-ul rulează pe PHP 8.1 sau mai vechi, proiectul PHP nu mai oferă actualizări oficiale, ci doar backporturi minimale ale codului sursă pentru 7.4, 8.0 și 8.1. Ce se aplică atunci rezumă PHP 8.1 și mai vechi. Ce versiuni PHP sunt acceptate de versiunea dumneavoastră de MediaWiki verificați conform cerințelor de sistem de pe mediawiki.org. O schimbare PHP poate presupune un upgrade MediaWiki.
Scripturile de mentenanță și job-runner-ul rulează prin PHP-ul din linia de comandă. Și această versiune trebuie să aibă patchul aplicat. Dacă coada de joburi rulează ca serviciu permanent, acesta trebuie repornit după actualizare la fel ca serverul web sau PHP-FPM. La mod_php, aceasta înseamnă o repornire a Apache însuși, deoarece PHP se află acolo în procesul serverului web.
Clarificați, în plus, cui aparține wiki-ul. Wiki-urile interne au fost adesea configurate de un departament de specialitate și rulează în afara întreținerii normale a serverelor. Fără o responsabilitate clară, actualizarea PHP rămâne acolo cel mai mult nefăcută.
Directoare și fișiere în MediaWiki
| Loc | Conținut | Punct de verificare |
|---|---|---|
LocalSettings.php |
Accesul la baza de date, $wgSecretKey, $wgUpgradeKey, drepturi, setări de upload |
Cod strecurat, reînnoiți cheile în caz de suspiciune |
images/ |
Fișiere încărcate și miniaturi | Fără fișiere PHP, fără execuție PHP |
extensions/, skins/ |
Extensii și teme | Fișiere necunoscute sau modificate |
cache/ |
Memorie intermediară | Goliți după curățare |
maintenance/ |
Scripturi de mentenanță pentru linia de comandă | Nu se folosesc prin web |
Directorul de upload nu ar trebui să execute scripturi la nivelul serverului web. Sub Apache, acest lucru funcționează astfel, indiferent de modul de operare PHP:
<Directory "/var/www/wiki/images">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
O primă verificare inofensivă:
find images -type f -name "*.php*"
ls -l LocalSettings.php
Verificați paginile MediaWiki:Common.js și MediaWiki:Common.css în istoricul versiunilor. Modificările de acolo se aplică fiecărui vizitator al wiki-ului și sunt un loc tipic pentru cod strecurat.
Drepturi, grupuri și extensii
În MediaWiki, grupurile de utilizatori decid securitatea. Verificați la Special:ListUsers și Special:UserRights cine aparține grupurilor administratori, birocrați și administratori de interfață. Administratorii de interfață pot modifica JavaScript-ul întregului wiki; acest grup ar trebui să fie foarte mic.
Pentru un wiki intern, citirea fără autentificare ar trebui dezactivată, iar înregistrarea conturilor noi blocată. Permiteți upload-uri doar pentru tipurile de fișiere de care este într-adevăr nevoie. Extensiile aduc cod PHP propriu; extensiile neîntreținute frânează, în plus, orice upgrade. Pentru drepturile de fișiere pe server, ghidul Drepturile de fișiere pe serverul web oferă o orientare.
Ce poate și ce nu poate o actualizare MediaWiki
O actualizare MediaWiki înlocuiește nucleul și închide erorile cunoscute din el. Ea nu aplică patchul PHP, nu repornește procese PHP, nu schimbă nimic în LocalSettings.php și nu elimină nici fișiere din images/, nici modificări ale MediaWiki:Common.js, nici membri suplimentari ai grupurilor. Nu dovedește nici că înainte de patch nimeni nu a citit pe ascuns.
O privire de ansamblu rapidă oferă, în plus, jurnalele de la Special:Log. Conturile de utilizator noi, modificările drepturilor de grup și editările paginilor de interfață din 17.10.2026 sunt consemnate acolo cu momentul.
Cum ajută PHP SOS concret?
- Verificăm versiunea PHP, modul de operare și starea backporturilor serverului dumneavoastră de wiki și punem să fie confirmată repornirea.
- Salvăm jurnalele începând cu 20.10.2026, baza de date și fișierele.
- Verificăm
LocalSettings.php, upload-urile, extensiile, drepturile de grup și istoricul versiunilor paginilor de interfață. - În cadrul ajutorului imediat PHP2Shell, evaluăm împreună cu dumneavoastră dacă wiki-ul trebuie să rămână accesibil public.
Întrebări frecvente
Este MediaWiki afectat de PHP2Shell?
MediaWiki însuși nu are o vulnerabilitate nouă, dar rulează pe PHP. Dacă PHP-ul serverului nu are patchul aplicat, un atacator poate, potrivit echipei PHP, să execute cod fără autentificare. O actualizare MediaWiki nu închide vulnerabilitatea.
Unde văd versiunea PHP a wiki-ului meu?
Pe pagina Special:Version, MediaWiki listează software-ul instalat, inclusiv versiunea PHP. Dacă a fost aplicat un backport nu recunoașteți după aceasta; acest lucru îl confirmă operatorul serverului.
De ce este MediaWiki:Common.js un risc?
Conținutul acestei pagini este livrat ca JavaScript tuturor vizitatorilor wiki-ului. Cine îl poate modifica poate executa cod în browserul fiecărui utilizator. De aceea, grupul administratorilor de interfață ar trebui să fie foarte mic.
Este suficient să fac wiki-ul accesibil doar intern?
Un wiki accesibil doar în rețeaua companiei sau prin VPN reduce considerabil riscul, deoarece atacatorii din internet nu îl pot ajunge direct. Trebuie totuși să aplicați patchul, pentru că un atac poate veni și din rețeaua internă.