Le 21 octobre 2026, PHP a publié des mises à jour d’urgence pour CVE-2026-109618 et CVE-2026-109619. Les deux vulnérabilités ont un score CVSS v4.0 de 9,2 et peuvent permettre une exécution de code à distance sans authentification dans les déploiements concernés. PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed sont concernés. PHP considère mod_php comme le cas le plus exposé, car une requête anonyme peut atteindre le cycle vulnérable avant l’exécution du code applicatif.

CVE-2026-109618 concerne la gestion de la mémoire après un échec d’allocation. Des données multipart complexes, un grand nombre d’en-têtes dans les parties, des noms de champs imbriqués et d’autres allocations contrôlées par l’attaquant peuvent pousser PHP vers un état de manque de mémoire. Le nettoyage peut ensuite traiter des données de requête qui n’ont pas été entièrement initialisées. L’impact confirmé est l’exécution de code sous l’identité du processus Web.

CVE-2026-109619 concerne un état de requête conservé au-delà de sa durée de vie. Un worker persistant peut garder un pointeur vers une zone mémoire libérée après une requête précédente. Une requête ultérieure rencontre alors une condition de use-after-free. PHP a confirmé un scénario avec les traces de fatal error dans PHP 8.5 et un autre avec le suivi de progression des téléversements de session. Le problème général dépasse un paramètre ou une extension précis.

La faille se situe dans le runtime PHP, pas nécessairement dans WordPress, Laravel, Magento ou un plugin. Une application à jour peut donc continuer à utiliser un binaire PHP vulnérable. La requête peut passer par un petit script, une route de vérification, un formulaire de connexion ou un point de téléversement avant que le framework ne produise ses journaux habituels. Cloudflare relie les scénarios concernés à la mémoire, aux erreurs et à l’état des requêtes HTTP.

Les versions corrigées sont PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 et PHP 8.2.35. Le projet PHP ne fournit plus de correctifs aux versions 8.1 et antérieures. Des fournisseurs de systèmes d’exploitation ou de support long peuvent toutefois rétroporter les correctifs. Le journal des paquets et l’avis du fournisseur sont donc plus fiables que la seule version amont affichée.

D’après la PHP Foundation, les premiers signes du problème de mémoire sont apparus lors d’un audit externe en 2024. Calif, OpenAI et Wiz ont ensuite démontré une voie fiable vers l’exécution de code. Les correctifs modifient le traitement des situations de manque de mémoire et réinitialisent un ensemble plus large d’états globaux propres aux requêtes. Un chemin d’échec mémoire différé et une terminaison forcée sûre empêchent le nettoyage de manipuler un état invalide.

Installer les nouveaux fichiers ne suffit pas. Les opérateurs doivent identifier le runtime et la source des paquets qui servent chaque application publique, déployer un paquet ou une image de conteneur corrigée, puis redémarrer Apache, PHP-FPM, les workers CGI, FrankenPHP, LiteSpeed et les autres processus PHP persistants. Il faut vérifier le binaire actif et le journal des paquets. Les contrôles doivent couvrir les téléversements, les sessions, les files de messages et les tâches en arrière-plan. Les journaux antérieurs au correctif doivent être conservés avant leur rotation habituelle.

PHP présente la mise à jour comme la seule mesure complète. En attendant, des limites prudentes sur la taille des requêtes et la complexité multipart peuvent réduire l’exposition. La suppression des erreurs memory_limit prévisibles et contrôlables par l’attaquant peut aider. PHP déconseille toutefois de remplacer cette protection par RLIMIT_AS ou RLIMIT_DATA, car ces limites peuvent provoquer le chemin d’échec d’allocation visé par le correctif. Il faut désactiver session.upload_progress.enabled et redémarrer les workers. PHP 8.5 doit aussi désactiver fatal_error_backtraces. Ces changements bloquent des chemins confirmés, mais pas toutes les sources possibles d’un état périmé.

Cloudflare a signalé des règles WAF combinant des signaux de requête et de réponse. AWS a décrit le blocage ou la détection de tentatives connues. Ces contrôles renforcent la défense, mais ne remplacent pas la mise à jour du runtime. Si le correctif ne peut pas être appliqué immédiatement, l’accès doit être réduit par un VPN, une allowlist ou une passerelle authentifiée. L’origine ne doit pas être joignable directement. Les téléversements multipart inutiles doivent être désactivés, les secrets superflus retirés du worker et ses privilèges système et réseau limités. Les journaux Web, PHP, proxy, processus et authentification doivent être conservés.

Amazon Threat Intelligence a signalé une tentative d’exploitation de PHP2Shell contre son honeypot MadPot le 17 octobre, quatre jours avant la divulgation publique. Amazon a ensuite observé plusieurs tentatives de preuve de concept issues d’infrastructures anonymisées différentes autour de la publication. Il n’a pas pu déterminer si la tentative antérieure aurait réussi contre une cible réelle. Les organisations doivent donc commencer leurs recherches le 17 octobre, ou à la date la plus ancienne fournie par leurs propres services de renseignement.

La recherche doit couvrir la télémétrie des processus, les journaux des reverse proxies et des erreurs PHP, les données de détection endpoint et les alertes d’intégrité des fichiers. Il faut surveiller le lancement de shells ou d’outils réseau par des workers Web, les erreurs memory_limit répétées, les réponses HTTP 500, les crashs, les redémarrages inhabituels et les requêtes multipart anormales. De nouveaux fichiers dans les racines Web, les répertoires temporaires ou les chemins de démarrage, des connexions sortantes inattendues, de nouveaux identifiants ou travaux planifiés, ainsi que des accès inhabituels aux secrets, certificats ou bases de données sont également pertinents. L’absence d’entrée dans le journal applicatif n’exclut pas une activité au niveau du runtime.

La réponse commence par l’inventaire de tous les services PHP exposés à Internet. Il faut inclure les conteneurs, machines virtuelles, hébergements mutualisés, panneaux d’administration, appliances, anciens sous-domaines, environnements de préproduction et installations gérées par des prestataires. Pour chaque service, noter le SAPI, la source du paquet, l’état du correctif, la méthode de redémarrage et le responsable. Les systèmes publics utilisant mod_php ou PHP-FPM sont prioritaires, surtout lorsqu’ils acceptent des téléversements. En cas d’exécution suspecte, isoler l’hôte, capturer les éléments volatils si possible, renouveler les identifiants exposés et éviter de supprimer les artefacts sur place.

PHP2Shell rappelle que les processus workers doivent eux aussi être traités comme des frontières de sécurité. L’exploitabilité dépend du build PHP, du SAPI, des extensions, de l’allocator, de la configuration frontale, de la réutilisation des workers et du chemin de requête. Tous les serveurs ne sont donc pas automatiquement compromis. Le statut de correction de l’application ne suffit cependant pas à évaluer le risque du runtime. Les paquets, les privilèges des workers, les connexions sortantes et la création de processus par les identités Web doivent être contrôlés régulièrement.