PHP2Shell est le nom donné à deux failles du moteur PHP, CVE-2026-109618 et CVE-2026-109619, rendues publiques le 21 octobre 2026 et notées 9,2 sur 10 (CVSS v4.0). Combinées, elles permettent d’exécuter du code sur le serveur, à distance et sans compte. Elles se trouvent dans PHP lui-même : un site WordPress, Drupal, Symfony ou un code sur mesure est exposé de la même façon dès lors que la version de PHP qui le sert n’est pas corrigée. Cet article rassemble, avec leurs sources, les trois gestes à faire dans l’ordre : vérifier la version réellement servie, poser une parade d’urgence si besoin, puis appliquer le correctif ou migrer.
Ce que l’on sait de la faille
Les avis de sécurité publiés par l’équipe PHP décrivent deux mécanismes. Le premier (CVE-2026-109618) survient quand une requête épuise la mémoire allouée à PHP : l’interruption laisse des données de la requête dans un état invalide, relu ensuite par la procédure de fin de requête. D’après l’avis, plusieurs façons de provoquer ce manque de mémoire passent par l’analyse des corps de requête multipart, le format des envois de fichiers. Sansec ajoute que cette faille peut renvoyer au client des fragments de mémoire du serveur.
Le second (CVE-2026-109619) tient à des états globaux de PHP qui gardent un pointeur vers la mémoire d’une requête déjà libérée : la requête suivante traitée par le même processus peut lire cet état périmé, ce qui ouvre l’exécution de code.
L’avis PHP décrit Apache avec mod_php comme le cas le plus exposé : l’exécution de code y a été démontrée par HTTP, avec la configuration par défaut, avant même que le code de l’application ne s’exécute. PHP-FPM est également concerné d’après l’analyse du code source. Les détails ont fuité la veille du correctif, et SecurityWeek comme Sansec annonçaient une exploitation de masse : le délai entre la publication et les premières attaques automatisées se compte en heures, pas en semaines.
Les versions concernées et corrigées
D’après Sansec, toutes les versions de PHP depuis 5.4 contiennent le code vulnérable. Le correctif officiel, publié le 21 octobre 2026 à 14 h UTC, ne concerne que les branches encore maintenues :
| Branche | Version corrigée | Support de sécurité jusqu’au |
|---|---|---|
| PHP 8.5 | 8.5.12 | 31 décembre 2029 |
| PHP 8.4 | 8.4.27 | 31 décembre 2028 |
| PHP 8.3 | 8.3.36 | 31 décembre 2027 |
| PHP 8.2 | 8.2.35 | 31 décembre 2026 |
| PHP 8.1, 8.0, 7.x, 5.4 à 5.6 | aucune | fin de vie |
Les dates de support viennent du calendrier officiel de php.net. Deux conséquences : une application en PHP 8.1 ou plus ancien n’a pas de correctif et doit migrer ; une application en PHP 8.2 se corrige aujourd’hui, mais sa branche cesse d’être maintenue dans deux mois.
Étape 1 : vérifier la version réellement servie
Sur un même serveur cohabitent souvent plusieurs PHP : celui de la ligne de commande, un ou plusieurs PHP-FPM, parfois mod_php, et ceux embarqués dans des conteneurs. La commande php -v ne renseigne que le premier.
- Lister les PHP installés.
php -vdonne la version de la ligne de commande (utile pour les tâches planifiées). Sur Debian et Ubuntu,ls /etc/php/montre chaque version installée. - Interroger chaque PHP-FPM. Chaque version a son binaire (
php-fpm8.3 -v, par exemple) et ses pools. Repérez ensuite, dans la configuration du serveur web, quel pool ou quel socket sert chaque site. - Contrôler une requête servie. Seule une page exécutée par le serveur web fait foi. Si la directive
expose_phpest active, l’en-têteX-Powered-Bydonne la version (curl -sIsur le site). Sinon, unphpinfo()temporaire, au nom imprévisible et à accès restreint, supprimé aussitôt après lecture. - Ne pas oublier les conteneurs. Dans un conteneur, PHP fait partie de l’image : mettre à jour l’hôte ne change rien. Interrogez chaque service, puis reconstruisez l’image sur une version corrigée.
Sur un hébergement mutualisé sans accès au serveur, seule la requête servie vous renseigne : demandez aussi la version à votre hébergeur.
Étape 2 : la parade d’urgence
D’après Sansec, tous les déclencheurs connus passent par une requête multipart/form-data, que PHP analyse avant que l’application ne s’exécute ; l’avis PHP recommande lui aussi de bloquer ces requêtes en amont quand l’application n’en a pas besoin. La parade consiste donc à les refuser dans le serveur web, avant qu’elles n’atteignent PHP : une règle de réécriture qui renvoie une erreur 403 aux requêtes POST de ce type sous Apache, ou une condition équivalente sous nginx.
Testez la configuration avant de recharger le serveur (apachectl configtest ou nginx -t), puis vérifiez qu’un envoi multipart est refusé et qu’un formulaire classique passe toujours. Gardez en tête l’effet de bord : la parade coupe tous les envois de fichiers (CV, documents, images), et certains formulaires de commande sont eux aussi envoyés en multipart. Ce n’est pas une correction : elle se retire dès que PHP est à jour.
Sur nos propres serveurs, nous avons appliqué cette parade dès le 21/10/2026.
Étape 3 : appliquer le correctif
Pour PHP 8.2 à 8.5, la correction est une mise à jour de version, à condition qu’elle atteigne le PHP qui sert vos sites.
- Récupérer la version corrigée par les paquets de votre distribution, l’image Docker officielle reconstruite ou votre hébergeur. Vérifiez que votre source de paquets propose bien la nouvelle version : Sansec signalait qu’un dépôt tiers courant ne la publiait pas encore le 21 octobre.
- Redémarrer tous les processus PHP. Un PHP-FPM ou un Apache déjà lancé garde l’ancien binaire en mémoire tant qu’il n’est pas redémarré.
- Revérifier sur une requête servie, site par site : c’est ce contrôle qui confirme la correction, pas le gestionnaire de paquets.
- Retirer la parade, puis tester de nouveau les envois de fichiers.
Si le serveur est resté exposé, Sansec rappelle que la première faille peut renvoyer de la mémoire contenant mots de passe, jetons de session ou clés d’API : faites l’inventaire des secrets qui transitaient par ce serveur et renouvelez les plus sensibles.
Versions sans correctif : migrer
PHP 5.x, 7.x, 8.0 et 8.1 sont en fin de vie : le projet PHP ne publie plus de correctif pour elles, ni pour PHP2Shell ni pour les failles à venir. Un correctif rétroporté par une distribution ou un hébergeur peut exister ; ce n’est pas une version maintenue par le projet PHP. La sortie durable passe par une migration vers PHP 8.3 ou 8.4, et souvent par celle du framework qui va avec. L’article sur la fin du support de PHP 8.2 détaille le calendrier et un plan de migration en six étapes.
Pour être accompagné : la page PHP2Shell reprend la fiche de la faille, l’offre de sécurisation comprend une intervention d’urgence au forfait, et l’offre de migration couvre les versions sans correctif.
