Faille critique PHP php2shell: que faire maintenant

Selon l'annonce officielle de PHP du 21 octobre 2026, les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent deux failles critiques qui peuvent permettre l'exécution de code à distance sans authentification. Toutes deux ont obtenu 9,2 sur l'échelle CVSS v4.0, une note standard qui indique le degré de dangerosité d'une faille. L'exécution de code à distance signifie qu'un attaquant peut lancer des commandes sur le serveur avec les privilèges du compte du processus web.

Toute installation PHP qui répond à des requêtes web est touchée: PHP-FPM, mod_php, php-cgi, FrankenPHP et LiteSpeed. Amazon Threat Intelligence a écrit le 21 octobre que son réseau de pots de miel avait vu la première tentative d'exploitation le 17 octobre, quatre jours avant la divulgation. SecurityWeek rapporte que, selon watchTowr, les preuves de concept qui circulent n'ont pas encore atteint l'exécution de code. Des tentatives existent, la preuve d'un succès reste limitée, et ce n'est pas une raison d'attendre.

Si votre site tourne sur PHP, considérez qu'il est concerné. Selon l'agence Anadolu, le FBI estime que PHP est utilisé sur environ 70 % des sites web, et selon la CISA, il peut être intégré à d'autres logiciels sans que vous le voyiez. Notre outil de détection des technologies donne de l'extérieur une première idée de ce qui fait tourner votre site, mais n'attendez pas de lui qu'il confirme la version.

Pour connaître la version exacte, suivez la démarche de WordPress.org: dans l'administration WordPress, ouvrez Outils, Santé du site, Info, Serveur. Les panneaux d'hébergement l'affichent aussi le plus souvent, et pour les sites hors WordPress, c'est à votre développeur ou à votre prestataire de vous la donner. Si elle est inférieure au numéro de votre branche (8.2.35, 8.3.36, 8.4.27 ou 8.5.12), les avis de sécurité GitHub indiquent que vous êtes concerné.

Sur un hébergement mutualisé, le prestataire gère le serveur; votre rôle est donc de lui poser la question par écrit: PHP a-t-il été mis à jour pour ces failles, et sur quelle version suis-je? Selon WordPress.org, la position des hébergeurs a changé d'heure en heure: certains avaient corrigé, certains disaient être protégés par un WAF, certains y travaillaient encore. Un WAF est un pare-feu qui filtre les requêtes entrantes. Si la réponse est « vous êtes protégé », demandez vers quelle version vous avez été basculé.

D'après les notes de version de cPanel, EasyApache 4 25.91 corrige les deux failles de ea-php74 à ea-php85, et 25.92 recompile les paquets ea-php74, ea-php80 et ea-php81. Ces paquets arrivent généralement par mise à jour automatique, mais c'est notre lecture; l'administrateur du serveur doit vérifier les versions dans WHM. Avec Plesk, la même question s'applique: demandez à votre prestataire le nom du paquet et le numéro de version. Si vous avez votre propre serveur, la base de connaissances de Laravel Forge indique que les mises à jour de sécurité automatiques ne corrigent pas PHP; il faut mettre PHP à jour séparément sur chaque serveur. Le projet PHP précise aussi que les distributions Linux ont reçu le correctif en avance et conseille de « vérifier les paquets de votre fournisseur ».

PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet PHP. Son équipe de sécurité a fourni des correctifs minimaux du code source pour 7.4, 8.0 et 8.1, et certaines distributions les rétroportent aussi, mais ils peuvent ne pas être arrivés dans le paquet de votre hébergeur. WordPress.org rappelle également que PHP antérieur à 8.2 ne reçoit plus de mises à jour de sécurité. Selon VulnCheck, plus de 2,6 millions de serveurs PHP exposés à Internet ont été comptés, dont au moins 1 million tournent sur des versions arrivées en fin de vie.

La CISA recommande de mettre hors ligne les systèmes qui ne peuvent pas être mis à jour ou qui tournent sous 8.1 ou une version antérieure. WordPress.org, citant le NCSC britannique, conseille de mettre le serveur hors ligne jusqu'à la mise à niveau si vous le gérez vous-même. Si votre site ne rapporte rien, par exemple une simple page vitrine, c'est une option réaliste. PHP 8.2 arrive en fin de vie le 31 décembre 2026; passer à 8.2.35 ne vous laisse donc qu'un court répit, alors planifiez dès maintenant votre trajectoire de versions.

L'annonce de PHP est claire: seule la mise à jour est une solution complète; les mesures provisoires réduisent l'exposition à certaines voies d'attaque mais ne rendent pas une installation sûre. L'avis GitHub confirme que passer à la version corrigée est la seule mesure complète. La seconde faille exige que deux requêtes tombent sur le même processus; plusieurs processus et leur recyclage font baisser le taux de réussite sans supprimer le risque, et aucune configuration ne l'élimine entièrement. La CISA propose un WAF à titre temporaire, et le mot temporaire compte ici.

Ce sont les mesures citées par l'annonce de PHP, et c'est votre administrateur serveur, non vous, qui doit les appliquer. L'annonce mentionne aussi la correction des erreurs fatales et des dépassements de délai que l'attaquant peut déclencher, ainsi que la suppression des réglages INI invalides ou obsolètes appliqués à chaque requête. Selon Codeable, WordPress n'utilise pas session.upload_progress; interrogez tout de même votre administrateur au sujet des autres applications du serveur.

• memory_limit=-1, défini de façon que l'application ne puisse pas le remplacer (via php_admin_value)
• Un post_max_size bas: 8M sans envoi de fichiers, 32M avec, upload_max_filesize devant rester en dessous
• session.upload_progress.enabled=0 et redémarrage de tous les processus, défini dans php.ini ou dans la configuration du pool, et non via ini_set ou .user.ini
• fatal_error_backtraces=0 sous PHP 8.5
• Ne pas utiliser RLIMIT_AS ni RLIMIT_DATA, car ils peuvent déclencher la faille

Amazon Threat Intelligence indique que l'enquête doit commencer au moins au 17 octobre, jour où la première tentative a été observée. Ses indicateurs sont des requêtes POST vers des envois de formulaires contenant la chaîne PHP_SESSION_UPLOAD_PROGRESS, des entrées suspectes dans les journaux du serveur web, ainsi qu'une activité de processus ou des modifications de fichiers inattendues. Demandez à votre prestataire ou à votre administrateur de les rechercher. La CISA recommande en outre de surveiller les processus PHP qui ouvrent un shell ou téléchargent des outils. Notre outil d'audit de sécurité examine les réglages de base visibles de l'extérieur; il ne remplace ni les journaux ni les fichiers du serveur.

Le second sujet concerne les processus de longue durée. Selon la base de connaissances de Laravel Forge, une mise à jour redémarre PHP-FPM, mais les workers de file d'attente, Horizon et Octane lancés en ligne de commande continuent de tourner avec l'ancien PHP tant qu'on ne les relance pas. Pour vérifier, exécutez php8.4 -v et php-fpm8.4 -v sur le serveur (si vous utilisez 8.4); selon Qualys, la version renvoyée par php -v peut différer de l'installation qui répond aux requêtes web. Si vous avez défini memory_limit=-1 en solution de secours, rétablissez une valeur finie. Si vous trouvez des traces ou ne pouvez pas être certain, discutez avec votre administrateur du changement des mots de passe de base de données, des clés d'API et des mots de passe d'administration; c'est un principe général d'hygiène, que les sources n'énoncent pas.

Trois erreurs ressortent. Les éviter compte pour la plupart des entreprises autant que la mise à jour elle-même.

Amazon écrit qu'un délai de correction de 7 ou 30 jours suppose un retard qui n'existe plus; il faut compter en heures. La PHP Foundation a pour sa part expliqué que le correctif était préparé depuis août, que les identifiants CVE avaient fuité le 20 octobre avec des informations erronées et que la publication avait été avancée d'un jour. La leçon est simple: notez par écrit qui possède le logiciel sous votre site, qui le met à jour et qui appeler, et rattachez à un calendrier les versions arrivant en fin de vie.

• Croire qu'une mise à jour d'extension, de thème ou de WordPress suffit: selon WordPress.org, aucune mise à jour de WordPress n'est nécessaire ni prévue pour ces problèmes, et mettre à jour une extension ou un thème ne vous protège pas
• Se fier à php -v: la version en ligne de commande peut différer de l'installation qui répond aux requêtes web
• Voir dans un WAF la solution: la CISA le range parmi les mesures temporaires, et un hébergeur qui dit en utiliser un ne prouve pas que la version est à jour