PHP2Shell : deux failles critiques dans PHP, que faire maintenant

PHP fait tourner une très grande partie du Web : sites vitrines, CMS, intranets, portails clients, outils métiers. Le 21 octobre, l'équipe PHP a publié en urgence des correctifs pour deux vulnérabilités critiques, surnommées « PHP2Shell ». Elles permettent à un attaquant d'exécuter du code à distance sur le serveur, sans authentification.

Si votre organisation exploite un serveur PHP exposé sur Internet, ce sujet est prioritaire aujourd'hui.

Ce que l'on sait

Deux identifiants ont été attribués : CVE-2026-109618 et CVE-2026-109619. PHP les classe toutes deux comme critiques, avec un score CVSS v4 de 9,2 selon l'analyse publiée par Huntress.

La première concerne la gestion des erreurs de manque de mémoire pendant la préparation des données d'une requête : des données partiellement initialisées sont ensuite traitées comme valides.
La seconde vient d'un état propre à une requête qui reste en mémoire après avoir été libéré. Si le même processus traite une requête suivante, il peut réutiliser cet état périmé.

Dans les deux cas, le résultat possible est le même : l'exécution de code avec les droits du compte qui fait tourner le serveur web. Selon Huntress, PHP indique que toutes les installations qui servent des requêtes web sont concernées, quel que soit le mode d'exécution : PHP-FPM, mod_php sous Apache, php-cgi, FrankenPHP ou LiteSpeed. L'attaque peut être déclenchée avant même l'exécution du code de l'application : la qualité de votre code ne vous protège pas.

Le contexte est inhabituel. Les détails ont fuité la veille de la publication prévue, ce qui a conduit PHP à avancer la sortie des correctifs. Selon la presse, plusieurs sites publics français ont été placés en maintenance préventive le jour même, à la demande de l'ANSSI selon le ministère de l'Intérieur.

Les versions concernées

D'après l'alerte du CERT-FR, sont vulnérables :

toutes les versions 5.x, 6.x, 7.x, 8.0.x et 8.1.x, qui ne sont plus maintenues
PHP 8.2 avant 8.2.35
PHP 8.3 avant 8.3.36
PHP 8.4 avant 8.4.27
PHP 8.5 avant 8.5.12

Les versions corrigées sont donc 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Pour les branches plus anciennes, des correctifs minimaux ont été annoncés, et certaines distributions Linux publient leurs propres paquets corrigés. La recommandation reste de migrer vers une version maintenue.

Les mesures à prendre aujourd'hui

Faire l'inventaire. Recensez tous les serveurs qui exécutent PHP, y compris ceux que l'on oublie : appliances de fournisseurs, panneaux d'administration, CMS installés il y a des années, environnements de recette exposés.
Corriger en commençant par ce qui est exposé. Les serveurs accessibles depuis Internet passent en premier. Chez un hébergeur, vérifiez qu'il a bien déployé les versions corrigées, et choisissez la version la plus récente proposée.
Appliquer les contournements si la correction n'est pas possible tout de suite. Le CERT-FR mentionne deux mesures, qu'il ne qualifie pas : désactiver `session.upload_progress.enabled` dans `php.ini` (ou via `php_admin_flag` pour PHP-FPM), ce qui réduit la surface d'attaque pour l'une des deux failles, et bloquer ou surveiller les requêtes HTTP de type multipart au niveau d'un pare-feu applicatif.
Isoler ce qui ne peut pas être corrigé. Une version de PHP en fin de vie ne doit plus être exposée directement : retirez-la d'Internet ou placez-la derrière un VPN ou un pare-feu applicatif.

Comment savoir si vous avez déjà été visé

Corriger ne suffit pas si l'attaquant est déjà passé. Les signes à rechercher, cités par Huntress :

un processus PHP ou serveur web (php-fpm, php-cgi, httpd, apache2) qui lance un shell, un interpréteur ou un outil réseau comme `curl`, `wget` ou `nc`
des commandes de reconnaissance (`whoami`, `id`, `uname -a`) exécutées par le compte du serveur web
de nouveaux fichiers dans les répertoires du site, en particulier des scripts PHP inconnus
de nouvelles tâches planifiées ou de nouveaux comptes

En cas de doute, isolez le serveur et conservez les journaux du serveur web et de PHP avant toute remise en état : ce sont eux qui permettront de comprendre ce qui s'est passé.

Notre regard

Ce type d'alerte montre l'intérêt d'un inventaire à jour des composants exposés. Les organisations qui savent en quelques minutes où tourne PHP corrigent dans la journée. Les autres découvrent des serveurs oubliés pendant des semaines.

Vous voulez vérifier rapidement votre exposition ou faire analyser un serveur suspect ? Contactez nos experts : nous pouvons intervenir sur l'inventaire, la correction et la recherche de compromission.