La plupart des alertes de sécurité WordPress que nous relayons concernent une extension : un formulaire mal protégé, un module de réservation qui accepte n'importe quel fichier. On met l'extension à jour, on vérifie, on passe à la suite. L'alerte du 21 octobre est d'une autre nature. Elle porte sur PHP, le langage qui exécute WordPress sur le serveur, et elle concerne donc tous les sites PHP, quelles que soient leurs extensions.
Les deux failles, référencées CVE-2026-109618 et CVE-2026-109619 et surnommées « php2shell », permettent à un visiteur anonyme d'exécuter du code sur le serveur. L'agence américaine CISA, le CERT-EU et le NCSC britannique ont publié des alertes dans la foulée, ce qui reste rare pour un composant aussi banal.
Ce qui a été corrigé
Les deux défauts touchent les parties de PHP que chaque requête traverse : la gestion de la mémoire et la gestion des erreurs. Dans le premier cas, une requête qui atteint la limite de mémoire au mauvais moment laisse derrière elle des données à moitié initialisées, que PHP réutilise ensuite comme si elles étaient valides. Dans le second, une erreur fatale laisse un pointeur vers une zone mémoire appartenant à une requête précédente.
Le résultat est le même : un attaquant peut fabriquer des requêtes qui corrompent la mémoire du processus PHP et y faire exécuter ses propres instructions. La fondation PHP indique que l'exécution de code a été démontrée avec la configuration par défaut sur Apache avec mod_php, et confirmée sur PHP-FPM, le mode le plus répandu chez les hébergeurs.
Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Toute version antérieure de ces branches est vulnérable. Le CERT-EU signale que des preuves de concept circulent déjà, ce qui raccourcit fortement le délai avant les premières campagnes automatisées.
Pourquoi votre tableau de bord ne dira rien
WordPress affiche la version de PHP dans l'outil de santé du site, mais il ne connaît pas les numéros de correctif sûrs. Un site en 8.3.30 apparaîtra en bonne santé alors qu'il tourne sur un interpréteur vulnérable. Les extensions de sécurité, elles, surveillent les fichiers de WordPress et les requêtes suspectes ; elles ne remplacent pas un interpréteur à jour.
Il faut aussi distinguer deux situations d'hébergement. Sur un hébergement mutualisé ou managé, c'est l'hébergeur qui installe les versions correctives de PHP, et les grands acteurs l'ont fait dans la journée. Sur un serveur privé virtuel ou un serveur dédié que vous administrez, personne ne le fera à votre place : la mise à jour passe par le gestionnaire de paquets du système, puis par un redémarrage du service PHP.
Le cas de PHP 8.1 et des versions antérieures
C'est le point le plus inconfortable de l'alerte. Les failles existent depuis PHP 5.4, mais seules les branches encore maintenues reçoivent un correctif. PHP 8.1, sortie du support fin 2025, n'en aura pas. PHP 7.4 non plus.
La consigne de la CISA est sans détour : les systèmes qui ne peuvent pas être mis à jour doivent être mis hors ligne jusqu'à leur migration. Pour un site vitrine, la conséquence pratique est simple : un site encore en 8.1 n'est plus en retard, il est exposé. La migration que nous recommandions de planifier pour la fin de l'année, dans notre article sur la fin de vie de PHP 8.2, devient une urgence pour tous ceux qui n'avaient pas encore quitté 8.1.
Certains hébergeurs proposent des versions anciennes maintenues par leurs soins, avec des correctifs reportés. C'est une solution transitoire acceptable si l'hébergeur confirme par écrit que le correctif php2shell a été intégré. Sans cette confirmation, il faut considérer la version comme vulnérable.
Les vérifications à faire cette semaine
- Relever la version exacte. Dans WordPress, menu Outils, Santé du site, onglet Informations, rubrique Serveur. Notez les trois chiffres, pas seulement la branche.
- Comparer aux versions corrigées. En dessous de 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, le site est vulnérable.
- Demander confirmation à l'hébergeur si vous êtes en mutualisé et que la version n'a pas changé. Certains appliquent les correctifs sans modifier le numéro affiché ; il faut le leur faire écrire.
- Mettre à jour et redémarrer si vous administrez le serveur. Un paquet installé sans redémarrage de PHP-FPM laisse les anciens processus en mémoire.
- Inventorier les autres usages de PHP. Un outil interne, une ancienne plateforme de réservation ou un logiciel de gestion hébergé sur le même serveur sont concernés au même titre que le site.
- Surveiller les journaux. La CISA recommande de rechercher des processus PHP qui lancent un interpréteur de commandes ou téléchargent des outils. Une erreur de mémoire répétée dans les journaux depuis le 20 octobre mérite aussi un examen.
Et si le site a déjà été touché
Une compromission par cette voie ne laisse pas toujours de trace dans WordPress : l'attaquant agit avec les droits du serveur web, pas avec un compte administrateur. Les signes à rechercher sont des fichiers PHP récents dans le dossier des médias, des tâches planifiées inconnues, des comptes administrateurs créés récemment ou un trafic sortant inhabituel depuis le serveur.
Si l'un de ces signes apparaît, la mise à jour de PHP ne suffit pas : elle ferme la porte sans faire sortir l'intrus. Il faut restaurer une sauvegarde antérieure au 20 octobre, changer les mots de passe de la base de données et des comptes, puis vérifier. La démarche complète figure dans notre article sur la reprise d'un site piraté. Elle suppose une sauvegarde stockée hors du serveur, sujet que nous traitons dans sauvegarder WordPress hors du serveur.
Ce que couvre le contrat
Sur les sites que nous maintenons, la version de PHP fait partie de l'inventaire suivi chaque mois. Le 21 octobre, nous avons vérifié les versions en service chez chaque hébergeur, relancé ceux qui n'avaient pas encore publié de correctif et basculé sur une branche maintenue les sites qui tournaient encore sur une version abandonnée.
Ce suivi est inclus dans la maintenance WordPress à 500 HT / an. Pour un site que personne ne suit, nous intervenons ponctuellement, et en dehors des heures ouvrées via l'urgence 24/7 à 230 HT de l'heure hors contrat. Les détails techniques figurent dans l'annonce de la fondation PHP.
À retenir
php2shell touche l'interpréteur PHP lui-même, donc tous les sites WordPress, quelles que soient leurs extensions. Les versions sûres sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12. PHP 8.1 et les versions plus anciennes ne seront pas corrigées : un site qui y tourne encore doit migrer maintenant. Relevez le numéro exact, faites confirmer le correctif par votre hébergeur et inspectez les journaux depuis le 20 octobre.
Si vous ne savez pas sur quelle version tourne votre site, envoyez-nous son adresse. Nous vous répondrons avec la version en service et ce qu'il reste à faire.