Une mise à jour de WordPress ne suffit pas à régler les nouvelles failles révélées dans PHP. Le 21 octobre, l’équipe du langage a publié des correctifs pour deux vulnérabilités critiques pouvant permettre une exécution de code à distance sans authentification. Le contrôle doit se faire du côté de l’environnement serveur, auprès de l’hébergeur ou de l’administrateur.
PHP exécute le code de nombreux sites dynamiques. Lorsqu’une faille touche son moteur, le problème se situe en dessous du thème ou des extensions du site. Cela explique pourquoi la publication concerne aussi bien des applications développées sur mesure que des sites utilisant un CMS.
Quatre branches reçoivent une version corrigée
L’avis officiel de PHP cite les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent CVE‑2026‑109618 et CVE‑2026‑109619. L’équipe recommande une mise à jour immédiate et ne présente pas ses mesures provisoires comme une solution complète.
La première vulnérabilité implique la gestion d’un manque de mémoire pendant l’initialisation de données internes. La seconde concerne un état conservé alors que la mémoire correspondante a déjà été libérée. Ces erreurs de gestion mémoire peuvent devenir dangereuses avant même que le code de l’application réalise ses contrôles habituels.
Le terme « sans authentification » ne veut pas dire que tous les serveurs ont déjà été attaqués. Il décrit une condition d’exploitation : l’attaquant n’a pas nécessairement besoin d’un compte valide dans l’application. Le périmètre réellement exposé dépend aussi de l’installation et des chemins d’exécution.
L’environnement PHP compte autant que le site qu’il héberge
L’avis officiel vise les installations qui traitent des requêtes Web, avec différents modes d’exécution dont PHP‑FPM, mod_php ou php-cgi. L’équipe considère le risque particulièrement élevé avec mod_php et décrit une exploitation démontrée avant le lancement du code de l’application. Un site n’a donc pas besoin d’une extension vulnérable pour être concerné par un défaut situé dans le moteur.
Les travaux sont détaillés par Wiz Research sous le nom PHP2Shell. Pour un propriétaire de site, la priorité n’est pas de reproduire l’attaque : il faut identifier l’environnement qui sert effectivement les pages, puis obtenir la confirmation du correctif adapté. L’absence d’alerte dans l’administration du CMS ne prouve rien sur cet environnement.
Demandez si les deux CVE sont corrigées sur le serveur de votre site
Sur un hébergement administré, demandez si le moteur PHP utilisé par votre site a reçu les correctifs des deux CVE. Une version affichée dans un panneau de contrôle peut aider à démarrer la vérification, mais elle ne remplace pas la réponse du fournisseur. Certaines distributions maintenues appliquent des correctifs rétroportés sans reprendre exactement la numérotation des versions publiées par le projet PHP.
Cette différence évite deux erreurs opposées : se croire protégé parce que le CMS est à jour, ou considérer automatiquement un serveur comme vulnérable parce que son numéro semble ancien. Le renseignement utile est la présence du correctif dans le paquet et l’environnement réellement déployés.
Sur un serveur que vous administrez, la procédure doit suivre la distribution et les services utilisés. Une mise à jour de paquet et la prise en compte du nouveau moteur par les services constituent des contrôles différents. Pour un site en production, les vérifications de fonctionnement et la sauvegarde restent des précautions d’exploitation ordinaires, à organiser sans repousser indéfiniment une correction critique.
Les anciennes branches exigent une réponse spécifique
PHP rappelle que les branches 8.1 et antérieures ne reçoivent plus de mises à jour du projet. Des fournisseurs peuvent proposer une maintenance prolongée, mais celle-ci doit être vérifiée auprès d’eux. L’équipe a également fourni des rétroportages minimaux destinés à certains anciens environnements ; ce n’est pas l’équivalent d’une maintenance générale rétablie.
Si plusieurs sites partagent le même hébergement, vérifiez aussi les environnements affectés à chacun. Un correctif appliqué à une instance PHP ne renseigne pas automatiquement sur toutes les autres instances du compte ou du serveur.
Changer seulement un mot de passe, vider un cache ou installer un outil de sécurité WordPress ne répare pas une erreur du moteur PHP. Le contrôle décisif se situe bien sur le serveur : quelle version corrigée, ou quel paquet rétroporté, exécute les requêtes de votre site ?
Eric Thomas suit l’actualité de Windows, des logiciels, de la cybersécurité grand public et des outils web. Il s’intéresse aux mises à jour système, aux nouveautés informatiques et aux solutions pratiques qui améliorent l’expérience numérique au quotidien.
