PHP2Shell : l'IA aide à révéler deux failles critiques de PHP datant de 2012

Le 21 octobre 2026, le projet PHP a publié quatre versions d'urgence pour corriger deux vulnérabilités du moteur qui permettent une exécution de code à distance sans authentification. Les correctifs figurent dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, et les deux failles, CVE-2026-109618 et CVE-2026-109619, sont notées 9,2 sur l'échelle CVSS v4.0. La faiblesse sous-jacente est ancienne. Selon l'analyse technique de Calif, le chemin de code affecté le plus ancien remonte à PHP 5.4.0. Cette version date de 2012, soit bien plus d'une décennie. Ce qui rend le cas notable tient en partie à la fréquence à laquelle cette faiblesse avait déjà été repérée, puis écartée.

01Deux bogues, une seule cause

Les deux failles se situent dans l'environnement d'exécution de PHP, et non dans WordPress, Magento ou un quelconque plugin. Calif indique qu'un attaquant non authentifié pourrait exécuter du code sur des installations standard de Magento, WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel et Symfony, entre autres. Sansec relève que, la faille se trouvant dans le moteur, les boutiques en ligne sont touchées même lorsque leur propre code est sain.

Le mécanisme commun tient à la manière dont PHP traite les conditions fatales. Lorsqu'une requête dépasse sa memory_limit (128 Mio par défaut) ou rencontre une autre erreur fatale, le moteur en C ne peut pas dérouler sa pile pas à pas. Il appelle zend_bailout(), une enveloppe autour de longjmp(). Un longjmp abandonne le code C en cours d'exécution, sans laisser la possibilité d'achever des structures de données à moitié construites.

La table de hachage qui sous-tend chaque tableau PHP, y compris $_POST, illustre le problème. L'analyse de Calif, relayée par Pentera, montre que le compteur d'entrées est incrémenté avant l'allocation de la clé : un emplacement est donc compté comme occupé avant que sa clé et sa valeur n'existent. Si l'allocation de la clé franchit memory_limit, l'abandon se déclenche précisément à cet instant. Un champ dont le nom est imbriqué conduit PHP à insérer le nom externe comme nouvelle clé de tableau, de sorte que l'attaquant maîtrise la longueur de la clé. En la dimensionnant pour franchir memory_limit, il fait tomber l'abandon sur l'allocation. Le nettoyage fait ensuite confiance à l'entrée partiellement initialisée.

Les deux CVE se répartissent selon le cycle de vie de la requête :

• CVE-2026-109618 : corruption de mémoire lors du traitement d'un manque de mémoire, déclenchée pendant le démarrage de la requête, avant l'exécution de tout script applicatif.
• CVE-2026-109619 : un état interne propre à la requête survit à la libération de la mémoire qui le soutient, et une requête ultérieure traitée par le même worker peut utiliser cet état périmé avant que l'initialisation normale ne le réinitialise. Rapid7 rapporte que l'avis de sécurité confirme une exécution de code à distance (RCE) contre mod_php via la fonction de trace de pile (backtrace) sur erreur fatale de PHP 8.5, activée par défaut, ainsi qu'une RCE liée au cycle de vie des sessions contre mod_php et FPM.

La CISA recense comme surfaces exposées Apache avec mod_php (que PHP considère comme le cas le plus risqué), PHP-FPM, php-cgi, FrankenPHP et LiteSpeed.

02Pourquoi elles sont restées cachées

Provoquer un manque de mémoire est facile à décrire, mais difficile à réaliser à distance. Par défaut, PHP plafonne les envois entrants avec post_max_size, fixé à 8 Mio. Une requête aussi petite ne peut normalement pas épuiser un tas de 128 Mio. Calif a trouvé des moyens de contourner cette limite. PHP vérifie post_max_size par rapport à l'en-tête Content-Length déclaré, mais ne l'applique pas aux octets réellement consommés ; Apache peut donc transmettre des requêtes multipart en HTTP/1.1 fragmenté (chunked) ou en HTTP/2 sans longueur déclarée significative. Une seconde voie épuise memory_limit avec une requête multipart qui reste sous post_max_size.

La configuration compte néanmoins. CrowdStrike indique que le chemin par encodage d'URL qu'elle a démontré exige à peu près memory_limit < 4 × post_max_size, condition que les valeurs par défaut de PHP ne remplissent pas. Rapid7 constate de même que les preuves de concept publiques ne fonctionnent chacune que contre une combinaison précise de système d'exploitation, de version de PHP et de serveur web, et qu'aucune ne paraît fiable à grande échelle. C'est une limite des outils publics actuels. Cela ne rend pas le bogue inoffensif au point de le laisser en place.

L'historique explique cette décennie d'obscurité. Les récits s'accordent à dire que l'idée d'une interruption liée à la limite de mémoire a été publiée par Stefan Esser en 2004. Un problème voisin de manque de mémoire dans l'analyse des requêtes multipart a été signalé en 2020 (certains récits parlent de 2019), et un audit OSTIF/Quarkslab de 2024 a relevé un bogue apparenté sans que son exploitation soit démontrée. À chaque fois, une corruption plausible n'avait pas de chemin démontré vers l'exécution de code ; elle est donc restée un bogue de robustesse de faible priorité. Passer de « pourrait corrompre la mémoire » à « donne de façon fiable un shell » demande un effort soutenu et spécialisé, et c'est cet effort qui a changé.

03Ce que l'IA a réellement fait

L'attribution est plus compliquée que ne le suggèrent les titres. Calif affirme avoir découvert la première faille le 1^er août 2026 dans le cadre de l'initiative « Patch the Planet » d'OpenAI, et l'avoir signalée à PHP le 11 août. Une analyse secondaire indique que Calif décrit une analyse par IA guidée par l'hypothèse d'un chercheur, tandis que Wiz décrit une IA intervenant à la fois dans la découverte, le développement d'exploits, la détection d'attaques et la validation des correctifs. La même analyse précise que Codex Security d'OpenAI a déposé un rapport indépendant sur la cause racine le 11 août, puis d'autres vecteurs d'attaque le 18 septembre. Les noms de modèles (GPT-5.6 Sol et, pour Wiz, également Gemini 4 Argon) proviennent de sources secondaires, et non de l'avis de sécurité de PHP.

Tout le monde n'y voit pas une IA qui découvrirait du nouveau. Un détracteur soutient que chaque élément de PHP2Shell figurait déjà dans les données d'entraînement publiques. Cette lecture cadre avec le dossier retracé ci-dessus. Elle précise aussi l'enjeu. L'apport du modèle ressemble moins à la détection d'une classe de bogues inédite qu'au travail patient consistant à tracer des chemins d'exécution, à enchaîner des primitives et à construire un exploit fonctionnel. Un récit décrit des agents d'IA traçant des défauts dans l'ordre d'initialisation des tables de hachage et dans des chemins où une table d'état invalide était référencée pendant l'analyse des requêtes POST. Les audits humains s'étaient arrêtés avant d'en arriver là.

04Divulgation, fuites et course aux correctifs

Le processus de divulgation coordonnée a été perturbé. PHP a annoncé le 20 octobre que la publication aurait lieu le 21 octobre à 14 h 00 UTC. Bitdefender rapporte que Chainguard a publié des images de conteneurs contenant le correctif plus de six heures avant la sortie, rompant l'embargo. Il ajoute que PHP affirme qu'aucun détail technique n'a fuité, mais qu'une vidéo d'exploit a accéléré le développement de preuves de concept. Des chercheurs de Sansec s'attendaient à des attaques massives dans les 15 minutes suivant la publication, selon Ars Technica. Des responsables d'Amazon ont déclaré que des attaquants avaient commencé à tenter d'exploiter la faille « à grande échelle », selon l'article de Tech Xplore. Le 26 octobre, la CISA a ajouté les deux CVE à son catalogue Known Exploited Vulnerabilities.

La carte des correctifs est inégale. AWS recense comme plages affectées 8.5.0–8.5.11, 8.4.0–8.4.26, 8.3.0–8.3.35 et 8.2.0–8.2.34, sans correctif amont pour PHP 5.4–8.1. Tenable ajoute que l'équipe PHP a fourni des rétroportages minimaux du code source pour les versions 7.4 à 8.1, tandis que les versions 5.4 à 7.3 ne reçoivent rien du projet. Les réglages provisoires n'aident que partiellement. Pour la CVE-2026-109618, l'avis suggère memory_limit=-1 défini de manière non modifiable, un post_max_size bas et des limites de taille de requête au niveau du proxy. Calif avertit que supprimer le plafond de mémoire accroît le risque que le serveur manque de mémoire. Selon PHP, aucun changement de configuration n'atténue entièrement ces vulnérabilités. Les exploitants de parcs de serveurs doivent en outre redémarrer PHP-FPM ou le serveur web pour que l'environnement d'exécution corrigé soit effectivement chargé.

05Ce que cela implique pour le code hérité

La leçon pratique porte sur l'économie de l'exploitation. Michael Daniel, de la Cyber Threat Alliance, a déclaré à l'AFP que le délai entre la preuve de concept et les kits d'exploitation, autrefois de plusieurs mois, se mesure désormais en heures ou en jours. Il a aussi indiqué que le taux historique d'exploitation, de 5 à 6 % des vulnérabilités, ne montre aucun signe de hausse : ce qui change, c'est la vitesse, pas le volume. L'expression de l'ancien responsable de la NSA Rob Joyce, citée par Daniel, est « great cleansing forest fire of old software » (le grand incendie de forêt purificateur des vieux logiciels).

Trois conséquences s'imposent aux ingénieurs :

1. « Exploitabilité non démontrée » est une défense plus fragile. Un constat clos en 2024 faute de preuve de concept peut désormais être rouvert à moindre coût. Un tri qui suppose que l'effort de l'attaquant reste rare vieillira mal.
2. La fin de vie est une frontière de sécurité. Les applications sous PHP 8.1 ou antérieur exécutent soit des rétroportages de provenance incertaine, soit n'ont aucun correctif. Le coût de migration est désormais un coût de correction.
3. L'IA défensive ne passe à l'échelle que si le tri y parvient aussi. Daniel prévient qu'une grande partie du bruit entrant est irréelle ou concerne des logiciels jamais exposés à Internet ; les mainteneurs ont donc besoin de meilleurs filtres à mesure que les rapports générés par IA se multiplient.

Reste à prouver l'équilibre à long terme. Daniel s'attend à ce que l'IA soit appliquée aux logiciels avant leur livraison, ce qui pourrait signifier moins de bogues de ce type dans le code neuf. Pour l'heure, une faille de sûreté mémoire dans un environnement d'exécution en C, qui avait survécu 14 ans, un audit et un signalement antérieur, a été trouvée, transformée en arme et corrigée en environ 11 semaines. Les outils d'IA qui ont comblé cet écart sont aussi à la disposition des attaquants.