Le 20 octobre 2026, le mode d'emploi pour prendre le contrôle d'une bonne partie du web a fuité sur Internet. Pas le lendemain d'un correctif : la veille. Pendant près de 24 heures, le monde entier a eu entre les mains un code d'attaque fonctionnel contre PHP, sans qu'aucun patch n'existe encore.
Cette faille porte un surnom qui dit tout : PHP2Shell. Comme Log4Shell en 2021, elle touche une brique logicielle tellement répandue que presque personne ne peut dire « ça ne me concerne pas » sans avoir vérifié. On vous explique ce que c'est, comment savoir si vous êtes exposé, et quoi faire concrètement.
PHP2Shell, c'est le nom donné à deux failles critiques du langage PHP, découvertes presque en même temps : CVE-2026-109618 et CVE-2026-109619.
Les deux affichent un score de gravité de 9,2 sur 10, tout en haut de l'échelle. Les deux permettent la même chose : exécuter du code sur votre serveur sans mot de passe, sans compte, sans la moindre authentification.
PHP, c'est le moteur invisible qui fait tourner une énorme partie du web : environ 70 % des sites dont on connaît le langage serveur en dépendent. WordPress, Drupal, Joomla, Magento, votre boutique en ligne, votre intranet, le petit outil métier bricolé il y a six ans : tout ça, très souvent, c'est du PHP en dessous. C'est précisément ce qui rend PHP2Shell dangereux : la faille n'est pas dans une application, elle est dans le moteur lui-même.
Les correctifs sont sortis le 21 octobre à 16h00. Trop tard pour prendre les devants : le code d'exploitation circulait déjà, et Cloudflare a observé les premières attaques avant même la publication du patch. L'Office fédéral allemand de la cybersécurité (BSI), le CERT-EU, le NCSC britannique ont tous publié des alertes d'urgence. Aux Pays-Bas, certains services publics ont carrément été débranchés par précaution. Ce n'est pas un détail d'administrateur système.
Pour comprendre, il faut imaginer la mémoire d'un serveur comme un bureau partagé. À chaque visite sur votre site, PHP installe ses dossiers sur le bureau, travaille, puis range tout avant la visite suivante.
Les deux failles exploitent un défaut dans ce rangement.
La première (CVE-2026-109618) frappe quand PHP est brutalement interrompu, par exemple parce qu'une requête dépasse la mémoire autorisée : le ménage se fait mal, et des bouts de dossiers restent traînés sur le bureau.
La seconde (CVE-2026-109619) exploite des données fantômes d'une visite précédente qui survivent et sont prises, à tort, pour des données actuelles lors de la visite suivante.
Dans les deux cas, un attaquant qui envoie des requêtes soigneusement préparées peut glisser son propre code à la place de ces restes, et le faire exécuter.
Le déclencheur connu est une simple requête d'envoi de fichier (en langage technique, du multipart/form-data), traitée par PHP avant même que le code de votre application ne démarre. Autrement dit, même un site au code parfaitement propre est vulnérable, parce que la faille se joue en amont. Le pire, c'est que la fonction par défaut qui suit la progression des envois de fichiers (session.upload_progress) est l'une des portes d'entrée confirmées, et elle est active d'origine. Au-delà de la prise de contrôle, ces failles peuvent aussi faire fuiter de la mémoire (mots de passe, jetons de session, clés d'API).
La faille vit dans le moteur PHP, pas dans vos applications. Elle concerne toutes les manières de se servir du PHP sur le web : Apache mod_php, PHP-FPM, php-cgi, LiteSpeed. Le code vulnérable existe depuis PHP 5.4, sorti en 2012. Les chercheurs ont confirmé une prise de contrôle sans authentification sur des applications aussi courantes que WordPress, Drupal, Joomla, Magento, MediaWiki, Nextcloud, phpMyAdmin, Roundcube, Laravel, Symfony ou WHMCS. Si vous hébergez l'une de ces briques, partez du principe que vous êtes concerné jusqu'à preuve du contraire.
La première étape n'est pas de patcher, c'est d'inventorier. Vous ne pouvez pas corriger ce que vous ne savez pas avoir. Il faut lister toutes les installations PHP de votre parc : serveurs web, applications métier, appliances fournisseurs, conteneurs, et tout ce qui fait tourner un CMS .
Pour chaque installation, comparez la version à celles qui corrigent la faille : PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. En dessous, vous êtes vulnérable. Les branches PHP 8.1 et antérieures ne reçoivent plus de correctif officiel, seulement des pansements sur lecode source pour 7.4, 8.0 et 8.1. Une version de la ligne en commande (php -v) donne un premier indice, mais attention à deux pièges :
- La version servie au navigateur peut différer de celle de la ligne de commande, et surtout, ce qui compte, c'est la version réellement chargée en mémoire par le serveur web, pas celles installées sur le disque. Un correctif installé mais sans redémarrage des processus ne protège pas : les anciens processus PHP qui tournent encore avec l'ancien code. La règle c'est donc, on patche, puis on redémarre Apache, PHP-FPM et tous les workers.
- Point important, et rassurant : une vieille version de PHP installée mais pas utilisée ne présente pas de risque pour cette attaque. PHP2Shell a besoin d'une requête web qui atteint un interpréteur PHP utilisé. Un binaire PHP qui dort sur un disque, qu'aucun serveur web n'expose, qui n'écoute sur aucun port et ne traite aucune requête HTTP, n'est pas impacté par cette exploit. Cela reste une bonne hygiène de le mettre à jour ou de le supprimer, mais ce n'est pas une urgence du même ordre qu'un PHP exposé sur Internet. La priorité absolue, ce sont les installations exposées.
Prenons une PME fictive mais réaliste de 30 personnes. Site vitrine à jour, bien suivi. Sauf que sur le même serveur traîne un vieil outil interne, un formulaire de demandes de congés développé il y a sept ans, tournant sous PHP 7.4 en mod_php, accessible depuis Internet « parce qu'un commercial en avait besoin en déplacement ». Personne n'y pense plus. Il ne reçoit aucune mise à jour.
C'est exactement ce type d'outil qu'il faut identifier. Le site vitrine, surveillé, sera patché vite. Le formulaire oublié, lui, est une porte d'entrée en PHP 7.4 (sans correctif officiel), exposée, et invisible dans l'esprit de tout le monde. Quand on intervient sur ce genre d'incident, la première chose qu'on regarde, ce n'est pas le site principal : ce sont les services oubliés.
La seule correction complète, c'est la mise à jour vers une version corrigée, suivie du redémarrage des services. Quand on ne peut pas patcher dans la minute, le site officiel de la faille (php2shell.com) liste plusieurs mesures d'atténuation à poser en attendant. Les plus utiles :
session.upload_progress.enabled = 0) dans la configuration serveur. Les développeurs de PHP préviennent que cette seule mesure ne suffit pas.multipart/form-data en frontal.post_max_size) et la profondeur d'imbrication (max_input_nesting_level) à ce dont l'application a strictement besoin.display_errors = 0), et sur PHP 8.5, désactiver les traces d'erreur (fatal_error_backtraces = 0).expose_php = 0) : cela réduit l'information donnée aux attaquants, même si cela ne corrige rien.Un pare-feu applicatif (WAF) peut aider à filtrer les attaques connues le temps de patcher, nous en parlons dans notre article sur CrowdSec devant HAProxy, mais c'est un filet temporaire, jamais un substitut au correctif. Et pour tout serveur vraiment impossible à mettre à jour rapidement : on l'isole ou on le coupe du réseau, point. Enfin, si vous avez le moindre doute sur une compromission, considérez que tout ce que le processus PHP pouvait lire a pu fuiter, et faites tourner vos mots de passe et vos clés.
Avant de redémarrer un serveur suspect, pensez à conserver les journaux : ce sont eux qui diront si on a seulement frappé à la porte, ou si on est entré. En cas de doute sérieux, votre meilleure assurance reste une sauvegarde saine et testée.
PHP2Shell n'est pas une faille de plus dans un plugin obscur : c'est un défaut au cœur du moteur qui fait tourner la moitié du web, exploitable sans mot de passe, avec du code d'attaque déjà en liberté. Réalisez l'inventaire avant que quelqu'un d'autre ne le fasse à votre place.