PHP2Shell : la situation à J+1

Il est complexe de généraliser l’exploitation des vulnérabilités de mémoire… mais les LLM peuvent aider. Wiz fait la remarque dans son tour d’horizon de PHP2Shell. La filiale de Google n’a pas découvert à elle seule cette famille de failles critiques qui touchent le cœur de PHP. Elle a toutefois pris le lead sur la narration, allant jusqu’à créer le site web php2shell.com – et vantant, au passage, la contribution « inestimable » du modèle Gemini 4 Argon. Le projet PHP propose un point de vue plus neutre dans son bulletin de sécurité . Il ne minimise cependant pas l’urgence de la situation : toutes les installations qui servent des requêtes web sont exposées à des exécutions de code arbitraire sans authentification. Wiz parle de 70 % des sites web. L’équipe Unit42 de Palo Alto Networks, de 22,6 millions d’instances potentiellement vulnérables. L’équipe sécurité de PHP a patché toutes les versions mineures encore prises en charge (8.5, 8.4, 8.3 et 8.2). Vu la gravité, elle fournit des rétroportages minimaux du code source pour PHP 8.1 , 8.0 et 7.4 . Deux vulnérabilités, beaucoup de chemins d’attaque 1. Épuiser la mémoire ( CVE-2026-109618 ) Lorsqu’un dépassement de mémoire survient, un saut longjmp() interrompt le traitement. Seulement, si cette saturation se produit pendant la phase d’initialisation de la requête, PHP ne gère pas correctement la sortie anticipée : il laisse la mémoire dans un état corrompu. La procédure d’arrêt de la requête peut ensuite lire ces données invalides, ouvrant la voie à l’exécution de code arbitraire. Plusieurs stratégies permettent de déclencher cette condition, en jouant entre autres sur les en-têtes, la longueur de contenu ou les métadonnées . Apache mod_php et FrankenPHP sont particulièrement vulnérables, car ils exécutent inconditionnellement la procédure d’arrêt, avant que le moindre code propre à l’application ne s’exécute.