Amazon a indiqué que son système de leurres MadPot avait enregistré, le 17 octobre 2026, une tentative visant un honeypot, quatre jours avant la divulgation publique de PHP2Shell. Le 21 octobre, PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger les deux failles. Amazon précise que ses observations concernent ses propres capteurs et qu’elle n’a pas déterminé si les tentatives auraient réussi contre des systèmes réels.
Ce qu’Amazon a observé avant et après la divulgation
Un honeypot est un système leurre conçu pour attirer les activités malveillantes. Selon le compte rendu d’Amazon sur MadPot, le capteur a enregistré une tentative le 17 octobre, puis d’autres activités le 21 octobre. Amazon situe les premiers exploits de preuve de concept autour de 02 h UTC et rapporte des tentatives contre MadPot entre 02 h et 08 h UTC. Après la levée de l’embargo à 14 h UTC et la divulgation publique, d’autres preuves de concept ont visé ses capteurs dans les heures qui ont suivi.
Ces événements correspondent à des tentatives détectées sur les capteurs d’Amazon. Ils ne démontrent pas qu’un site ou un autre système réel a été compromis.
Les deux failles et les configurations concernées
PHP2Shell désigne deux vulnérabilités critiques du cœur de PHP, CVE-2026-109618 et CVE-2026-109619. PHP leur attribue à chacune un score CVSS v4.0 de 9,2 et indique qu’elles peuvent permettre l’exécution de code à distance sans authentification dans des installations qui traitent des requêtes web.
La première faille, CVE-2026-109618, concerne la gestion d’un épuisement de mémoire : des données de requête peuvent rester partiellement initialisées puis être traitées lors de l’arrêt de la requête. La seconde, CVE-2026-109619, implique un état global périmé et une utilisation de mémoire après sa libération. Un processus de travail peut conserver une référence à des données d’une requête précédente et y accéder avant qu’une requête ultérieure ne réinitialise cet état.
Le bulletin de sécurité de PHP cite PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed parmi les configurations concernées. PHP désigne Apache mod_php comme la configuration la plus risquée. La portée pratique dépend aussi du serveur API PHP et du chemin d’exécution concernés.
Quelles versions de PHP corrigent PHP2Shell ?
PHP a publié des versions corrigées dans quatre branches : PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les avis du projet listent comme concernées les versions antérieures aux correctifs correspondants dans chacune de ces branches.
PHP 8.1 et les branches antérieures ne reçoivent plus de mises à jour du projet PHP. Des distributions et des fournisseurs de maintenance à long terme peuvent toutefois rétroporter des correctifs vers leurs paquets. PHP a également fourni des rétroportages dans le code source pour PHP 7.4, 8.0 et 8.1. Pour un paquet distribué par un tiers, son statut dépend donc des correctifs appliqués par ce fournisseur, et pas seulement du numéro de version amont.
Un WAF remplace-t-il l’installation du correctif ?
Non. PHP indique qu’une version corrigée constitue la seule remédiation complète. Les mesures de configuration peuvent réduire certaines voies d’attaque, mais ne rendent pas une installation sûre à elles seules.
