php2shell : deux failles critiques dans PHP lui-même, attaquées avant le correctif

Le 17 octobre, un piège à attaquants d'Amazon a enregistré une attaque contre une faille de PHP qui n'avait encore ni nom ni correctif. Quatre jours plus tard, le 21 octobre 2026, le projet PHP a publié des mises à jour d'urgence pour deux vulnérabilités appelées ensemble php2shell.

Mettez à jour : PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35

PHP fait tourner le côté serveur d'environ sept sites sur dix dont le langage est connu, dont la plupart des sites WordPress. Les failles sont dans le moteur PHP lui-même : mettre à jour WordPress, les extensions ou le code du site ne suffit pas.

Quel est le problème ?

Les deux failles permettent à un attaquant non connecté d'exécuter son propre code sur le serveur, avec les droits du processus web. PHP les note 9,2 sur 10 (CVSS 4.0), selon son bulletin de sécurité.

• CVE-2026-109618 : si PHP manque de mémoire alors qu'une requête n'est qu'à moitié préparée, le nettoyage peut se fier à ces données incomplètes.
• CVE-2026-109619 : un état résiduel d'une requête pointe vers de la mémoire libérée que la requête suivante du même processus peut atteindre.

Toutes les façons de servir PHP sur le web sont touchées : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed, selon la synthèse de Tenable. Le code le plus ancien touché remonte à PHP 5.4.

Les failles sont-elles exploitées ?

Oui, des tentatives sont confirmées. Amazon Threat Intelligence a vu la première le 17 octobre, puis d'autres de plusieurs acteurs le 21 octobre. Cloudflare et watchTowr signalent aussi des attaques. On ne sait pas encore si elles réussissent ; la PHP Foundation n'avait trouvé aucun exploit public fonctionnel à la publication. Du code qui prétend en être un circule et peut lui-même contenir un logiciel malveillant.

La publication a été avancée du 22 au 21 octobre parce que les numéros CVE avaient fuité.

Que doivent faire les propriétaires de sites ?

1. Mettre à jour PHP vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou installer le paquet corrigé de l'hébergeur ou de la distribution Linux, puis redémarrer tous les processus PHP.
2. Anciennes versions : PHP 7.4 à 8.1 n'ont que des correctifs en code source, 5.4 à 7.3 rien. Passez à une branche maintenue. PHP 8.2 s'arrête le 31 décembre 2026.
3. Si la mise à jour est impossible aujourd'hui : fixer memory_limit=-1 sans que les applications puissent le changer, et session.upload_progress.enabled=0 (sur PHP 8.5 aussi fatal_error_backtraces=0), puis redémarrer. Ce sont des palliatifs, pas des correctifs, souligne Datadog Security Labs.
4. Remonter jusqu'au 17 octobre : formulaires énormes avec des noms de champs de plusieurs mégaoctets, erreurs de mémoire « Unknown on line 0 », processus Apache plantés et surtout un processus web qui lance un shell.

Ce que l'on ne sait pas encore

Combien de serveurs ont été compromis, et s'il existe un exploit public fiable. Les estimations de serveurs PHP exposés vont de 1,3 à plus de 1,9 million. Article à jour au 22 octobre 2026, sans suivi des informations ultérieures.

Les sites d'ARMSMA, armsma.org et Nocton, ne tournent pas sous PHP. Notre suivi des vulnérabilités gratuit liste les failles déjà exploitées, et la vérification de domaine montre ce que votre site expose.