En bref : la sécurité de MediaWiki après PHP2Shell commence par le PHP du serveur, car la faille s'y trouve et non dans le wiki. Les wikis internes restent souvent des années sans être touchés et tournent sur d'anciennes versions de PHP. Vérifiez l'état sur Special:Version, appliquez le correctif et redémarrez, puis contrôlez LocalSettings.php, images et les administrateurs d'interface.
Pourquoi les wikis internes sont une cible intéressante
Dans de nombreuses entreprises, administrations et institutions de recherche, MediaWiki sert de manuel interne. On y trouve des procédures, des interlocuteurs, des plans de réseau, des instructions pour les serveurs et parfois même des identifiants qui n'ont rien à y faire. Pour un attaquant, un tel wiki est une carte de l'entreprise.
Les failles PHP CVE-2026-109618 et CVE-2026-109619 permettent, selon l'équipe PHP, d'exécuter du code malveillant à distance sans authentification. Un wiki conçu « uniquement pour l'interne », mais accessible par Internet, est donc directement vulnérable. Et comme les wikis sont rarement au centre de l'attention de l'informatique, ils tournent souvent sur de vieux serveurs, fréquemment encore avec PHP comme module Apache, le mode d'exploitation présentant le risque le plus élevé selon l'équipe PHP.
Sécurité MediaWiki : vérifier la version de PHP et l'état du correctif
La page Special:Version affiche la version de MediaWiki, de PHP et de la base de données ainsi que toutes les extensions et tous les thèmes installés. Les versions corrigées en amont sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. De nombreux serveurs de wikis tournent sur des distributions Linux avec backports ; le numéro affiché reste alors identique bien que le correctif soit appliqué.
Si le wiki tourne sur PHP 8.1 ou plus ancien, le projet PHP ne publie plus de mises à jour officielles, seulement des backports minimaux du code source pour 7.4, 8.0 et 8.1. Ce qui s'applique alors est résumé dans PHP 8.1 et antérieur. Les versions de PHP prises en charge par votre version de MediaWiki se vérifient dans la configuration requise sur mediawiki.org. Un changement de PHP peut exiger une mise à niveau de MediaWiki.
Les scripts de maintenance et les job runners fonctionnent via le PHP en ligne de commande. Cette version doit elle aussi être corrigée. Si la file d'attente des tâches tourne comme service permanent, celui-ci doit redémarrer après la mise à jour, tout comme le serveur web ou PHP-FPM. Avec mod_php, cela signifie un redémarrage d'Apache lui-même, car PHP se trouve dans le processus du serveur web.
Clarifiez en outre à qui appartient le wiki. Les wikis internes ont souvent été mis en place par un service métier et fonctionnent en dehors de la maintenance normale des serveurs. Sans responsabilité claire, la mise à jour de PHP y reste le plus longtemps en suspens.
Dossiers et fichiers dans MediaWiki
| Emplacement | Contenu | Point de contrôle |
|---|---|---|
LocalSettings.php |
Accès à la base de données, $wgSecretKey, $wgUpgradeKey, droits, réglages d'upload |
code inséré, renouveler les clés en cas de soupçon |
images/ |
fichiers téléversés et vignettes | aucun fichier PHP, aucune exécution de PHP |
extensions/, skins/ |
Extensions et designs | fichiers inconnus ou modifiés |
cache/ |
Mémoire tampon | vider après nettoyage |
maintenance/ |
Scripts de maintenance pour la ligne de commande | ne pas utiliser via le web |
Le répertoire d'upload ne devrait exécuter aucun script au niveau du serveur web. Sous Apache, cela se fait ainsi, indépendamment du mode d'exploitation de PHP :
<Directory "/var/www/wiki/images">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Un premier contrôle sans danger :
find images -type f -name "*.php*"
ls -l LocalSettings.php
Vérifiez l'historique des versions des pages MediaWiki:Common.js et MediaWiki:Common.css. Les modifications qui y sont faites agissent pour chaque visiteur du wiki et sont un endroit typique pour du code introduit.
Droits, groupes et extensions
Dans MediaWiki, ce sont les groupes d'utilisateurs qui décident de la sécurité. Vérifiez sous Special:ListUsers et Special:UserRights qui appartient aux groupes administrateurs, bureaucrates et administrateurs d'interface. Les administrateurs d'interface peuvent modifier le JavaScript de l'ensemble du wiki ; ce groupe devrait être très restreint.
Pour un wiki interne, la lecture sans connexion devrait être désactivée et la création de nouveaux comptes bloquée. N'autorisez les uploads que pour les types de fichiers réellement nécessaires. Les extensions apportent leur propre code PHP ; les extensions non maintenues freinent en outre chaque mise à niveau. Pour les droits de fichiers sur le serveur, le guide Droits de fichiers sur le serveur web donne une orientation.
Ce qu'une mise à jour de MediaWiki peut faire et ne peut pas faire
Une mise à jour de MediaWiki remplace le cœur et y comble des défauts connus. Elle ne corrige pas PHP, ne redémarre pas de processus PHP, ne change rien à LocalSettings.php et ne supprime ni fichiers dans images/, ni modifications de MediaWiki:Common.js, ni membres de groupes supplémentaires. Elle ne prouve pas non plus que personne n'a lu en cachette avant le correctif.
Les journaux sous Special:Log donnent en outre un aperçu rapide. Les nouveaux comptes utilisateurs, les modifications des droits de groupes et les modifications de pages d'interface depuis le 17/10/2026 y sont consignés avec l'horodatage.
Comment PHP SOS aide-t-il concrètement ?
- Nous contrôlons la version de PHP, le mode d'exploitation et l'état des backports de votre serveur de wiki et faisons confirmer le redémarrage.
- Nous sauvegardons les journaux à partir du 20/10/2026, la base de données et les fichiers.
- Nous contrôlons
LocalSettings.php, les uploads, les extensions, les droits de groupes et l'historique des versions des pages d'interface. - Dans le cadre de l'aide immédiate PHP2Shell, nous évaluons avec vous si le wiki doit rester accessible publiquement.
Questions fréquentes
MediaWiki est-il concerné par PHP2Shell ?
MediaWiki lui-même n'a pas de nouvelle faille, mais il fonctionne sur PHP. Si le PHP du serveur n'est pas corrigé, un attaquant peut, selon l'équipe PHP, exécuter du code sans authentification. Une mise à jour de MediaWiki ne comble pas la faille.
Où vois-je la version de PHP de mon wiki ?
Sur la page Special:Version, MediaWiki liste les logiciels installés, dont la version de PHP. Le numéro ne permet pas de savoir si un backport a été appliqué ; l'exploitant du serveur le confirme.
Pourquoi MediaWiki:Common.js est-il un risque ?
Le contenu de cette page est livré en JavaScript à tous les visiteurs du wiki. Qui peut la modifier peut exécuter du code dans le navigateur de chaque utilisateur. Le groupe des administrateurs d'interface devrait donc être très restreint.
Suffit-il de rendre le wiki accessible uniquement en interne ?
Un wiki accessible seulement sur le réseau de l'entreprise ou par VPN réduit nettement le risque, car les attaquants venant d'Internet ne l'atteignent pas directement. Vous devez malgré tout appliquer le correctif, car une attaque peut aussi venir du réseau interne.