PHP corrige les failles critiques PHP2Shell révélées par des recherches assistées par IA

PHP a publié le 21 octobre des mises à jour de sécurité d’urgence pour deux vulnérabilités critiques regroupées sous le nom PHP2Shell, à la suite d’enquêtes impliquant Calif, OpenAI et Wiz. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. CVE-2026-109618 et CVE-2026-109619 présentent toutes deux un score de gravité CVSS 4.0 de 9,2. Lorsque les conditions nécessaires sont réunies, un attaquant peut exécuter du code sans authentification ; les chercheurs ont aussi démontré la divulgation de mémoire de processus contenant des informations sensibles.

Les deux avis classent comme affectées les versions antérieures au sein de ces quatre branches. Les chercheurs ont retrouvé le code concerné jusqu’à PHP 5.4, ce qui en fait un problème d’environnement d’exécution couvrant plusieurs générations d’applications. L’alerte de PHP vise les déploiements web utilisant notamment Apache mod_php, PHP-FPM, php-cgi, FrankenPHP et LiteSpeed. Un environnement vulnérable peut exposer une application dont le propre code est pourtant sûr, mais les voies d’attaque disponibles dépendent du déploiement et du cycle de vie des requêtes.

CVE-2026-109618 concerne le comportement en cas de manque de mémoire. PHP utilisait auparavant un saut non local pour abandonner le traitement, ce qui pouvait interrompre une opération avant l’initialisation complète de ses données internes de requête. Le nettoyage pouvait ensuite lire ces données incomplètes comme si elles étaient valides, provoquant une corruption mémoire. Il s’agit d’un défaut de gestion des erreurs et d’initialisation. Le correctif remplace cette sortie brutale par une réponse contrôlée à un point d’exécution sûr, avec un arrêt immédiat du processus à un seuil de mémoire plus élevé.

CVE-2026-109619 concerne un état interne qui survit à la requête propriétaire de sa mémoire. Une erreur fatale, ou certains diagnostics pendant l’arrêt, peut laisser un processus de travail persistant conserver une référence à un espace déjà libéré. Une autre requête adressée au même processus peut utiliser la valeur périmée avant que l’initialisation normale l’efface. L’avis décrit des cas confirmés liés aux traces d’erreurs fatales de PHP 8.5 et au suivi de progression des téléversements de session. L’exploitation nécessite une opération laissant un état résiduel et une autre, ultérieure, qui le consomme.

Apache mod_php présente le risque évalué le plus élevé : une attaque démontrée peut atteindre le traitement vulnérable avant l’exécution de tout code applicatif. PHP-FPM termine un processus de travail lorsque le démarrage d’une requête échoue, bloquant cette séquence particulière. Cependant, l’avis sur l’état résiduel confirme une voie FPM dépendant de l’application après un démarrage réussi, lorsqu’une opération interrompue laisse un état pour une requête ultérieure. Les métriques de gravité indiquent une complexité d’attaque élevée et des conditions d’exécution supplémentaires, ainsi que l’absence de privilèges ou d’interaction utilisateur nécessaires.

OpenAI a indiqué que Calif avait identifié une faille critique avec GPT-5.6 Sol dans le cadre de son initiative Patch the Planet. La PHP Foundation mentionne un signalement du chercheur Ryan A, de Calif, le 11 août et un signalement indépendant d’OpenAI de la même cause racine ce jour-là. Selon le récit de Calif, la connaissance de l’histoire des vulnérabilités de PHP par le chercheur a aidé à orienter l’enquête ; la découverte initiale ne dépendait ni d’un modèle inédit ni d’un dispositif spécial de test.

Wiz a enquêté et signalé les vulnérabilités de manière indépendante, transmettant ses découvertes le 24 août. Son équipe a utilisé Wiz Atlas, Gemini 4 Argon et GPT-5.6 Sol, attribuant à Argon un travail important dans la découverte, la détection et la validation du correctif. Wiz a démontré des attaques contre des déploiements de test de WordPress, Drupal et Joomla, ainsi qu’une divulgation mémoire distincte. L’équipe a décrit des tests répétés et des adaptations à différentes dispositions mémoire, plutôt qu’un seul exploit fonctionnant automatiquement contre toute installation PHP.

Les responsables de la maintenance de PHP ont dirigé les corrections et leur publication. La Foundation a expliqué que des signes du problème d’épuisement mémoire étaient apparus pendant le traitement de résultats d’un audit de Quarkslab réalisé en 2024 et organisé par l’intermédiaire d’OSTIF. Des arbitrages concernant la compatibilité, les performances et les extensions avaient retardé une solution. OpenAI a apporté un soutien aux recherches et une coordination avec les fournisseurs d’infrastructure, tandis que la Foundation finançait les ingénieurs chargés de la correction. Les nouveaux signalements ont établi l’impact pratique d’un problème dont les possibilités d’exploitation antérieures n’avaient pas été démontrées.

La divulgation a été accélérée après le début de la circulation des identifiants CVE le 20 octobre. La Foundation a déplacé la publication coordonnée du 22 octobre à 14:00 UTC au 21 octobre à 14:00 UTC. Elle a précisé que les distributeurs avaient encore besoin de temps pour terminer leurs paquets. Calif a ensuite publié par erreur une vidéo de démonstration, retirée par la suite, qui révélait quelques détails supplémentaires limités. Les correctifs et les avis techniques sont maintenant publics.

Cloudflare a déclaré que ses protections par défaut avaient été déployées pour les clients utilisant son WAF gratuit ou payant à 03:02 UTC le 21 octobre, et a signalé du trafic d’attaque avec des tentatives de variation des charges. Séparément, la Foundation a indiqué n’avoir trouvé aucun exploit fonctionnel parmi les preuves de concept en circulation qu’elle avait examinées au moment de la divulgation. Ces observations ne permettent pas d’établir un nombre confirmé de serveurs compromis. Cloudflare a continué à demander l’application des correctifs PHP, et PHP précise que les changements de configuration et le filtrage n’offrent qu’une protection partielle.

Les distributions et les fournisseurs de support à long terme ont reçu les correctifs à l’avance et peuvent fournir des paquets intégrant des corrections rétroportées. PHP 8.1 et les versions antérieures restent hors du support de sécurité ordinaire du projet d’origine, même si celui-ci a fourni des rétroportages minimaux du code source pour 7.4, 8.0 et 8.1 en raison de la gravité. Ces correctifs exceptionnels ne transforment pas les anciennes branches en versions prises en charge. Pour les applications hébergées, la correction dépend donc de l’environnement PHP fourni par l’opérateur, et pas seulement d’une mise à jour du système de gestion de contenu.