PHP2Shell : comprendre la faille PHP critique et comment s’en protéger

PHP2Shell désigne deux vulnérabilités critiques du moteur PHP, référencées CVE-2026-109618 et CVE-2026-109619, corrigées par l’équipe du projet le 21 octobre 2026. Notées 9,2 sur 10 selon la méthode CVSS v4.0, elles permettent à un attaquant non authentifié d’exécuter du code sur un serveur web vulnérable. Le CERT-FR et le Centre canadien pour la cybersécurité ont émis des alertes le jour même, et des tentatives d’exploitation ont été signalées dans les jours suivants. Trois semaines après la publication des correctifs, cet article explique ce qu’est la faille PHP2Shell, pourquoi elle concerne une si grande partie du web, quelles versions sont protégées et comment s’assurer concrètement qu’un site WordPress n’est plus exposé.

Qu’est-ce que PHP2Shell ?

PHP est un langage de programmation exécuté côté serveur : quand un internaute ouvre une page, c’est le moteur PHP qui reçoit la requête, exécute le code du site et renvoie la page au navigateur. WordPress, Drupal, Joomla ou Magento reposent sur ce langage : une faille dans PHP lui-même touche donc chacun d’eux, quelle que soit la qualité du code de l’application.

C’est précisément le cas de PHP2Shell. Le nom associe « PHP » à « shell », l’accès en ligne de commande à une machine : une requête web ordinaire peut, dans certaines conditions, se transformer en prise de contrôle du serveur. Selon l’équipe PHP, toutes les installations qui servent des requêtes web sont concernées, quel que soit le mode d’exécution : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP ou LiteSpeed.

Les deux CVE ont été découvertes par l’équipe de recherche de la société de sécurité cloud Wiz, qui les a signalées à l’équipe de sécurité de PHP le 24 août 2026. Les correctifs et les détails publics ont suivi le 21 octobre 2026. Selon Wiz, PHP fait fonctionner 70 % des sites web dans le monde : ce chiffre mesure la part du web qui utilise ce langage, pas le nombre de sites effectivement vulnérables, mais il donne l’ordre de grandeur de la vulnérabilité PHP2Shell.

Comment fonctionne la faille PHP2Shell

Les deux vulnérabilités relèvent de la même famille : des erreurs de sécurité mémoire. Un programme réserve des zones de mémoire pour stocker des informations le temps d’un traitement, puis les libère. Si une donnée continue d’être utilisée après la libération de sa zone, on parle d’utilisation après libération (use-after-free, classée CWE-416).

Le point commun des deux failles est la manière dont PHP gère une requête interrompue brutalement, par exemple par une erreur fatale. Selon l’avis publié par l’équipe PHP le 21 octobre 2026, le mécanisme général se décrit ainsi :

Un serveur PHP fait tourner des processus de travail (les « workers ») qui traitent les requêtes à la suite : si l’une laisse un état corrompu, la suivante en hérite. Wiz explique que cette corruption peut aboutir soit à la lecture de la mémoire du processus, où se trouvent parfois des mots de passe, des jetons de session ou des clés d’API, soit à l’exécution de code à distance.

Le facteur aggravant tient au moment où la faille se déclenche. Selon l’équipe PHP, le risque est le plus élevé avec mod_php sous Apache, car une requête non authentifiée peut déclencher l’attaque avant même l’exécution du code de l’application. Ni un mot de passe robuste ni une extension de sécurité ne protègent un serveur dont le moteur PHP n’est pas à jour.

Lire plus : Sécuriser les contrats intelligents : une approche multicouche

Versions de PHP concernées et versions corrigées

Le 21 octobre 2026, le projet PHP a publié quatre versions correctives, une par branche encore maintenue. L’alerte CERTFR-2026-ALE-014 du CERT-FR, dans sa mise à jour du 27 octobre 2026, et l’alerte AL26-026 du Centre canadien pour la cybersécurité reprennent la même liste.

Les branches anciennes posent un problème particulier. Le CERT-FR classe toutes les versions 5.x, 7.x, 8.0.x et 8.1.x parmi les versions affectées, et le projet PHP ne leur fournit plus de mises à jour de sécurité régulières. L’équipe PHP indique avoir publié des rétroportages minimaux pour PHP 7.4, 8.0 et 8.1, et certaines distributions Linux ou fournisseurs de support étendu proposent leurs propres correctifs. La recommandation des autorités reste toutefois la même : migrer vers une branche maintenue. Les sites sous PHP 8.2 devront aussi migrer avant la fin de vie de la branche, fixée au 31 décembre 2026.

Un point de vocabulaire évite bien des malentendus : la version de PHP n’a rien à voir avec la version de WordPress. Un site sous WordPress à jour peut tourner sur un moteur PHP vulnérable, et c’est généralement l’hébergeur, non l’éditeur du site, qui installe la mise à jour, comme le rappelle Malwarebytes dans son article du 21 octobre 2026.

Alertes du CERT-FR et du Centre canadien pour la cybersécurité

Le CERT-FR, centre gouvernemental de veille et de réponse aux attaques informatiques rattaché à l’ANSSI, a publié l’alerte CERTFR-2026-ALE-014 « Multiples vulnérabilités dans PHP » le 21 octobre 2026. Dans sa version du 27 octobre 2026, le CERT-FR indique avoir connaissance de preuves de concept et signale des tentatives d’exploitation visant certains déploiements. Il recommande d’isoler les équipements affectés, puis de migrer vers une version maintenue intégrant les derniers correctifs.

Le Centre canadien pour la cybersécurité a publié son alerte AL26-026 le même jour, mise à jour les 23 et 27 octobre 2026. Il y précise que des preuves de concept sont publiquement accessibles, que des sources ouvertes font état d’une exploitation active et que l’agence américaine CISA a ajouté les deux CVE à son catalogue des vulnérabilités exploitées (Known Exploited Vulnerabilities) le 26 octobre 2026.

Les deux alertes mentionnent une troisième vulnérabilité, CVE-2026-115560, annoncée par l’équipe PHP le 23 octobre 2026 et non corrigée par les versions du 21 octobre. Son exploitation suppose une combinaison peu courante de réglages PHP et de code applicatif. L’équipe PHP recommande, en attendant le prochain cycle de correctifs, de désactiver le suivi de progression des téléversements de session (session.upload_progress.enabled=0), une mesure qui vaut aussi contournement provisoire pour CVE-2026-109619.

La liste des logiciels tiers touchés reste longue : le CERT-FR et le Centre canadien renvoient tous deux vers l’inventaire non exhaustif tenu par le NCSC-NL, l’agence néerlandaise de cybersécurité, sur GitHub. Pour suivre ce type d’alerte dans la durée, la rubrique cybersécurité de Start in Blockchain regroupe nos analyses.

Le rôle de l’IA dans la découverte de PHP2Shell

PHP2Shell illustre une évolution que les chercheurs en sécurité observent depuis plusieurs mois : l’intelligence artificielle accélère la recherche de vulnérabilités. Selon Wiz, la faille existait de longue date dans le moteur PHP, et ce sont les modèles d’IA de pointe qui ont « substantiellement réduit la difficulté » de la transformer en exploitation fonctionnelle. Wiz indique qu’un modèle d’IA a contribué de façon déterminante à la découverte, à la détection et à la validation du correctif.

Selon la chronologie de Wiz, la première découverte date du 19 août 2026 et l’exécution de code à distance est démontrée sur Drupal le 20 août, puis sur WordPress le 21 août : trois jours entre l’anomalie et la démonstration sur deux des CMS les plus répandus.

Cette dynamique joue dans les deux sens. Les outils qui aident les défenseurs à trouver des failles avant publication sont aussi à la portée d’attaquants capables de comprendre un correctif et d’en déduire la faille qu’il bouche. Les enjeux de l’IA appliquée à la sécurité sont suivis dans notre rubrique intelligence artificielle.

Lire plus : Qu’est-ce que la cryptographie ?

Se protéger de PHP2Shell : la check-list pour les sites WordPress

L’équipe PHP est explicite : la mise à jour du moteur est la seule solution complète. Les contournements publiés réduisent l’exposition sans rendre une installation sûre. Pour un site WordPress, la démarche tient en quelques étapes.

• Identifier la version de PHP : dans l’administration WordPress, le menu Outils puis Santé du site, onglet Infos, rubrique Serveur, affiche la version de PHP utilisée. Elle doit être au moins égale à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 selon la branche.
• Obtenir l’assurance écrite de l’hébergeur : Malwarebytes conseille de s’assurer que le correctif est effectivement installé, et non simplement planifié.
• Migrer les sites sous PHP 8.1 ou antérieur : ces branches ne reçoivent plus de correctifs officiels. Avant la bascule, tester le thème et les extensions sur un environnement de préproduction.
• Redémarrer les processus PHP après la mise à jour : la faille repose sur l’état conservé par les workers, et un service non redémarré peut continuer à exécuter l’ancienne version.
• Surveiller les signes de compromission : fichiers PHP inconnus dans les dossiers du site, comptes administrateurs créés sans raison, redirections inattendues, tâches planifiées suspectes ou connexions sortantes inhabituelles.
• Faire tourner les secrets si le site est resté exposé après le 21 octobre : mots de passe de la base de données, clés de sécurité de WordPress, jetons d’API de services tiers.

Ce dernier point mérite d’être souligné. Une mise à jour ferme la porte, mais ne chasse pas un intrus déjà entré. Le Centre canadien pour la cybersécurité recommande de surveiller les journaux des serveurs web, des applications et de l’authentification, et d’enquêter sur tout processus, fichier, compte ou connexion sortante inattendu lié à PHP. Un site resté plusieurs jours sur une version vulnérable doit être considéré comme potentiellement compromis jusqu’à preuve du contraire.

Lorsque la mise à jour est impossible à court terme, les autorités recommandent d’isoler les applications exposées à Internet, voire de les mettre hors ligne. Les contournements techniques détaillés par l’équipe PHP, comme la désactivation du suivi de progression des téléversements de session ou l’ajustement des limites mémoire, relèvent de l’administrateur système et restent des solutions d’attente. Comme pour un contrat intelligent, la protection d’un site repose sur plusieurs couches, et le moteur qui exécute le code en est la première.

FAQ sur PHP2Shell

Mon site WordPress est-il concerné par PHP2Shell ?

Oui, si le serveur qui l’héberge utilise une version de PHP antérieure à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou une branche plus ancienne. La faille touche le moteur PHP lui-même, pas WordPress. Mettre à jour WordPress, son thème ou ses extensions ne corrige donc rien. La version de PHP s’affiche dans Outils, puis Santé du site, onglet Infos.

Une extension de sécurité WordPress suffit-elle à bloquer PHP2Shell ?

Non. Selon l’équipe PHP, dans la configuration la plus exposée (mod_php sous Apache), une requête non authentifiée peut déclencher la faille avant même l’exécution du code de l’application, donc avant qu’une extension WordPress n’intervienne. Selon Malwarebytes, le directeur technique de Cloudflare, Dane Knecht, rappelle que les règles de pare-feu restent une protection temporaire. Seule la mise à jour de PHP corrige la vulnérabilité.

Que signifie le score CVSS de 9,2 ?

Le CVSS (Common Vulnerability Scoring System) est une échelle de 0 à 10 qui mesure la gravité d’une vulnérabilité selon des critères comme la facilité d’exploitation, le besoin ou non d’authentification et l’impact sur le système. Un score de 9,2 en CVSS v4.0, attribué par l’équipe PHP aux deux CVE, les place dans la catégorie « critique », le niveau le plus élevé.

Les sites encore sous PHP 7.4 ou 8.1 peuvent-ils être corrigés ?

Le projet PHP ne publie plus de versions officielles pour ces branches. Il a diffusé des rétroportages minimaux pour PHP 7.4, 8.0 et 8.1, et certaines distributions Linux proposent leurs propres correctifs, mais le CERT-FR et le Centre canadien recommandent de migrer vers une branche maintenue. La migration impose de tester au préalable la compatibilité du thème et des extensions.

Un internaute risque-t-il quelque chose en visitant un site vulnérable ?

Le visiteur n’a aucune mise à jour PHP à installer sur son appareil : la faille se situe sur le serveur. Le risque indirect existe toutefois si un site compromis sert des contenus piégés. Malwarebytes recommande de se méfier des redirections, téléchargements ou demandes d’informations inattendus, et de quitter la page en cas de doute.

Ce qu’il faut retenir

PHP2Shell regroupe deux vulnérabilités critiques du moteur PHP, CVE-2026-109618 et CVE-2026-109619, notées 9,2 en CVSS v4.0 et corrigées le 21 octobre 2026 par les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles exploitent la manière dont PHP nettoie une requête interrompue et permettent, dans les cas les plus graves, l’exécution de code à distance sans authentification. Le CERT-FR et le Centre canadien pour la cybersécurité signalent des preuves de concept publiques et des tentatives d’exploitation. Pour un site WordPress, la protection passe par le contrôle de la version de PHP, l’engagement écrit de l’hébergeur, la migration des branches obsolètes et la recherche de traces de compromission. La découverte, que Wiz attribue en partie à l’usage de modèles d’IA, montre que le délai de réaction après un correctif se réduit.