Un site à jour côté CMS peut rester exposé. La raison tient en une couche d’infrastructure : l’interpréteur qui exécute le code. Le projet PHP a publié le 21 octobre 2026 les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui referment deux vulnérabilités baptisées PHP2Shell. Elles permettent d’exécuter du code à distance sans authentification. Voici comment savoir si vos sites internet sont concernés, et par quoi commencer.
PHP2Shell : une faille de sécurité logée dans le moteur, pas dans le CMS
Deux vulnérabilités critiques, notées 9,2 sur 10 selon le score CVSS v4, sont référencées CVE-2026-109618 et CVE-2026-109619 dans l’avis publié par php.net. Leur point commun : l’attaquant n’a pas besoin de compte ni de mot de passe pour déclencher l’exécution de code sur le serveur.
Toutes les installations qui servent des pages web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet PHP classe le risque au plus haut niveau avec mod_php, où une attaque a été validée avant même que le code de l’application ne s’exécute.
Le point essentiel pour les équipes techniques : le correctif de sécurité ne se trouve ni dans un plugin, ni dans un thème, ni dans une extension. Il se trouve dans le paquet PHP installé sur la machine. Une alerte informatique de cette nature se traite donc côté hébergeur ou administrateur système, pas depuis l’interface d’administration.
Mise à jour du CMS : pourquoi elle ne protège pas
Le réflexe habituel consiste à ouvrir le tableau de bord et à cliquer sur « mettre à jour ». Ce geste reste utile, mais il ne couvre pas PHP2Shell. Wiz, à l’origine de la découverte, indique avoir pris le contrôle d’images récentes de WordPress, Drupal et Joomla malgré des installations à jour.
Second effet documenté par le même cabinet : la lecture de la mémoire du processus PHP. Celle-ci peut contenir des mots de passe, des jetons de session et des clés d’API. Un site qui affiche des données sensibles devient donc une cible d’autant plus intéressante.
À ce jour, php.net ne confirme aucune exploitation active. Cloudflare, en revanche, déclare observer du trafic d’attaque dirigé vers ses clients. Une nuance qui suffit à justifier une intervention rapide. Le précédent d’une mise à jour WordPress qui avait échoué sur de nombreux sites illustre la même mécanique : tant que la couche serveur n’est pas traitée, la sécurité web reste théorique.
Vérifier la version de PHP réellement servie
Le piège classique : la version affichée dans le CMS n’est pas toujours celle utilisée par le serveur web. Un même VPS peut exécuter une version en ligne de commande et une autre via PHP-FPM. Le contrôle doit porter sur le binaire qui répond aux requêtes.
| Situation | Où lire la version | Point de vigilance |
|---|---|---|
| Site WordPress | Outils → Santé du site → Informations → Serveur | Indique la version du moteur, pas le niveau de correctif du paquet |
| Site Drupal | Rapports → Rapport d’état | Même limite : le correctif de distribution n’apparaît pas |
| Hébergement mutualisé | Espace client de l’hébergeur | Demander une confirmation écrite du correctif appliqué |
| VPS ou serveur dédié | php -v en SSH, puis vérification du paquet | Les distributions corrigent souvent sans changer le numéro de version |
| Site derrière Cloudflare | Journal du pare-feu applicatif | Les règles sont un filet, pas un correctif |
Hébergement mutualisé et serveur dédié : deux pièges distincts
Sur un hébergement mutualisé, la version affichée ne garantit pas que le correctif soit appliqué : les distributions Linux rétroportent fréquemment les patches sans modifier le numéro visible. La seule réponse fiable reste une confirmation écrite du support, à archiver.
Sur un serveur dédié, le contrôle en SSH ne suffit pas non plus. Il faut consulter l’avis de sécurité de la distribution et vérifier le paquet effectivement installé, puis redémarrer PHP-FPM ou Apache. Un redémarrage oublié laisse le code vulnérable en mémoire.
Les quatre gestes à appliquer sans attendre
- Relever la version réellement servie par chaque site, via le CMS, l’hébergeur ou le serveur. Un inventaire écrit vaut mieux qu’une estimation.
- Installer les versions corrigées de votre branche, ou le paquet corrigé de votre distribution, puis redémarrer PHP-FPM ou Apache.
- Appliquer les réglages provisoires de php.net en cas de blocage, dont session.upload_progress.enabled=0 dans php.ini, suivi d’un redémarrage de tous les workers.
- Surveiller les journaux : requêtes multipart suivies d’erreurs de limite mémoire, erreurs 500 répétées, cookies PHPSESSID anormalement longs. Ce sont les signaux cités par Wiz.
Les équipes qui gèrent un parc de sites clients ont intérêt à ordonner le travail. Les serveurs en mod_php passent en premier, puis les sites en PHP-FPM, dont l’analyse du code suffit à les rendre vulnérables même sans attaque complète démontrée.
Réglages provisoires, branches obsolètes et WAF : les limites des parades
php.net le précise clairement : les réglages temporaires bloquent des chemins d’attaque connus, pas toutes les variantes. Ils réduisent la surface exposée, ils ne rendent pas un serveur sûr.
Les branches 8.1 et antérieures ne reçoivent plus de versions officielles. Des correctifs minimaux existent en code source pour 7.4, 8.0 et 8.1, à destination de ceux qui compilent eux-mêmes. Dans les autres cas, il reste la distribution, le support étendu ou la migration.
Les règles de pare-feu applicatif ne constituent pas une alternative durable. Cloudflare indique avoir observé des attaquants modifier leurs requêtes pour contourner ses protections. Utile en complément, insuffisant comme stratégie unique.
Couper un site en 503 plutôt qu’en 500 : l’avis de John Mueller
Certaines organisations ont choisi d’interrompre temporairement leur service le temps du correctif. Reuters mentionne des administrations et des hôpitaux européens ayant procédé ainsi. Le choix se défend, à condition de soigner la manière.
John Mueller, chez Google, recommande de renvoyer un code HTTP 503 plutôt qu’un délai d’attente, un 404 ou un 500. Ce statut peut être servi en dehors de PHP, depuis le CDN ou le DNS, ce qui maintient la page d’attente disponible même si le moteur est arrêté. Google précise aussi la durée acceptable : quelques heures, pas quelques semaines.
Une plateforme comme Messenger Rooms et ses appels vidéo jusqu’à 50 participants rappelle à quel point les usages grand public évoluent vite ; côté serveur, la fenêtre de correction se compte en heures. Les règles de pare-feu de Cloudflare, actives depuis le 21 octobre et incluses dans l’offre gratuite, apportent un répit. Elles ne remplacent pas l’installation des versions corrigées.
Le vrai indicateur n’est pas la version affichée dans WordPress, mais celle que le serveur exécute réellement. Tant que cette vérification n’est pas faite, la faille reste ouverte.
