PHP2Shell : quand l’IA réduit la fenêtre entre découverte, correctif et attaque

Fin septembre, nous écrivions dans « Rogue AI, wp2shell : le hacking change d’échelle » que l’IA réduisait déjà le temps, le coût et les compétences nécessaires pour rechercher et industrialiser certaines attaques. L’épisode PHP2Shell apporte aujourd’hui une pièce supplémentaire au tableau.

Le sujet n’est pas seulement qu’une IA a aidé à trouver des vulnérabilités critiques. C’est ce qui se passe ensuite : correctifs préparés sous embargo, protections déployées chez les fournisseurs, fuite partielle de l’information, publication avancée, sites coupés préventivement et premières tentatives d’exploitation observées dans un intervalle très court.

Autrement dit, la course ne s’accélère pas seulement du côté de la découverte. Elle compresse aussi le temps disponible entre le moment où une faille est comprise et celui où elle devient un risque opérationnel public.

Deux vulnérabilités critiques dans PHP lui-même

Le 21 octobre 2026, le projet PHP a publié PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 afin de corriger deux vulnérabilités critiques : CVE-2026-109618 et CVE-2026-109619.

Dans les deux cas, le problème se situe dans la manière dont PHP gère certains états internes lorsqu’une requête échoue brutalement. CVE-2026-109618 concerne notamment un épuisement de la mémoire (out-of-memory) : si une requête atteint le memory_limit au mauvais moment, PHP peut laisser derrière lui des données internes partiellement initialisées puis les traiter comme valides. CVE-2026-109619 peut, elle, laisser subsister un état interne pointant vers une zone mémoire déjà libérée. Dans certaines conditions, ces situations peuvent être transformées en exécution de code à distance sans authentification.

Le point important est que les failles se trouvent dans le moteur PHP, pas dans WordPressCMS open source dominant du web, basé sur PHP/MySQL, extensible via thèmes et plugins., Drupal, Joomla ou une extension particulière. PHP considère à risque toutes les installations qui servent des requêtes web, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet estime le risque le plus élevé avec mod_php, pour lequel une exploitation a été démontrée avant même l’exécution du code applicatif.

Le CERT-FR considère affectées toutes les versions 5.x, 6.x et 7.x, les branches 8.0.x et 8.1.x, ainsi que les versions antérieures à 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Pour les branches encore maintenues, les versions corrigées sont disponibles. Pour les anciennes branches, il faut passer par un correctif fourni par un distributeur ou migrer vers une version maintenue.

PHP est très clair sur un point : les mesures de contournement peuvent réduire l’exposition, mais la mise à jour est la seule correction complète.

Que faire si vous administrez du PHP ?

La priorité est de passer à PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou d’installer le correctif rétroporté fourni par votre distribution ou votre fournisseur LTS. PHP a également publié des backports source minimaux pour 7.4, 8.0 et 8.1.

Si la mise à jour immédiate est impossible, l’avis officiel détaille plusieurs mesures temporaires selon le vecteur concerné, notamment la désactivation de session.upload_progress.enabled et la réduction de post_max_size. Elles réduisent certains chemins d’attaque mais ne rendent pas une installation sûre et ne remplacent pas le correctif.

Une faiblesse ancienne, mais dont l’exploitabilité n’était pas évidente

Il serait trop simple de résumer l’affaire à « une nouvelle faille découverte aujourd’hui ».

La PHP Foundation explique que les premiers signes du problème d’épuisement de mémoire à l’origine de CVE-2026-109618 avaient déjà été repérés en 2024, lors d’un audit externe. Un scénario d’exploitation avait alors été envisagé, mais aucun vecteur concret n’avait été trouvé.

De son côté, Wiz affirme que toutes les versions de PHP publiées depuis une décennie sont touchées par au moins une de ces vulnérabilités, jusqu’à PHP 5.4. Selon ses chercheurs, transformer ces défauts en exploits fonctionnels nécessitait de chaîner plusieurs comportements de gestion mémoire, puis d’adapter l’exploitation aux versions, configurations et applications rencontrées.

C’est ici que l’IA entre réellement dans l’histoire.

OpenAI indique que Calif a identifié une faille critique avec GPT-5.6 Sol dans le cadre de son initiative Patch the Planet. Wiz dit avoir, indépendamment, utilisé Wiz Atlas, Gemini 4 Argon et GPT-5.6 Sol au cours de ses recherches. La PHP Foundation précise également avoir utilisé plusieurs outils d’IA dans son travail de sécurité : elle cite notamment un scan de PHP mené avec Claude Mythos d’AnthropicLaboratoire d’IA américain à l’origine des modèles Claude, accessibles par API et non téléchargeables., en collaboration avec Alpha-Omega, puis l’usage d’OpenAI Daybreak Red pour valider des rapports et des exploits.

Le constat documenté n’est donc pas que l’IA a créé la vulnérabilité. Elle a réduit l’effort nécessaire pour comprendre et exploiter une faiblesse déjà présente dans le code depuis longtemps.

Le problème change dès que la faille doit être rendue publique

Une vulnérabilité n’est pas corrigée simplement parce qu’un chercheur l’a comprise.

Il faut produire un correctif, le tester, vérifier qu’il ne casse pas les applications existantes, préparer les paquets pour les distributions, avertir les hébergeurs et les fournisseurs de sécurité, puis laisser suffisamment de temps aux opérateurs pour déployer les protections.

OpenAI appelle cet intervalle la « Defender’s Window » : une période pendant laquelle les défenseurs disposent de l’information et peuvent préparer des protections avant que les détails deviennent publics.

Dans le cas PHP2Shell, cette fenêtre a commencé à se refermer avant la date prévue.

La PHP Foundation explique que la divulgation coordonnée devait initialement avoir lieu le 22 octobre à 14 h UTC. Le 20 octobre vers 15 h UTC, les identifiants des deux CVE ont commencé à circuler sur des forums et les réseaux sociaux. Aucun détail technique complet n’avait alors fuité, mais le projet PHP a avancé son préavis puis la sortie des correctifs au 21 octobre à 14 h UTC.

Le choix illustre bien la difficulté : publier immédiatement aurait réduit le temps laissé aux attaquants, mais aurait aussi exposé de nombreux utilisateurs alors que leurs distributions et fournisseurs n’avaient pas encore de paquet prêt à installer.

Puis la divulgation s’est accélérée par étapes

Après cette première fuite, la PHP Foundation rapporte qu’une vidéo montrant un proof of concept a été publiée par erreur par Calif puis supprimée. Des copies ont toutefois continué à circuler. Selon la Foundation, cette vidéo a contribué à accélérer le développement d’autres preuves de concept le 21 octobre.

Quelques heures plus tard, le 21 octobre à 07 h 41 UTC, Chainguard a publié des images contenant déjà le correctif alors que l’embargo n’était pas encore levé. Un attaquant pouvait donc commencer à comparer les versions et étudier le correctif avant sa publication générale.

Cette chronologie est importante car elle montre que « communiquer sur une faille » n’est pas en soi l’erreur. Une divulgation publique est nécessaire pour permettre aux utilisateurs de comprendre le risque et de se protéger. Le point fragile est l’ordre dans lequel circulent les informations, les correctifs et les capacités d’analyse.

Plus le correctif devient facile à rétro-analyser, plus la fenêtre entre « les défenseurs savent » et « les attaquants peuvent reconstruire » se réduit.

Les premières tentatives étaient déjà visibles

Cloudflare faisait partie des acteurs prévenus en amont. L’entreprise indique avoir développé ses protections depuis début octobre et les avoir activées par défaut pour ses clients à 03 h 02 UTC le 21 octobre, environ neuf heures avant la divulgation publique.

Cloudflare affirme avoir observé du trafic d’attaque visant ses clients pendant la séquence de fuite et des variations successives des payloads destinées à contourner ses protections.

Il faut cependant garder une distinction importante : du trafic d’exploitation n’est pas la même chose qu’une compromission réussie.

La PHP Foundation indique qu’au moment de la publication, malgré la circulation de plusieurs preuves de concept, son équipe n’avait pas identifié d’exploit fonctionnel parmi ceux qu’elle surveillait. À ce stade, les informations disponibles ne permettent donc pas de parler sérieusement d’une vague mondiale de compromissions réussies.

Elles permettent en revanche d’affirmer que la phase offensive avait déjà commencé à s’organiser alors que la chaîne de correction était encore en cours de déploiement.

Des mises hors ligne par précaution

La gravité de la situation a conduit plusieurs organisations à couper temporairement certains services.

Dans sa factbox consacrée aux mises hors ligne, Reuters rapporte notamment qu’en France, le ministère de l’Intérieur a temporairement coupé les sites des préfectures dans l’attente d’un correctif pour le framework PHP qu’ils utilisent. Aux Pays-Bas et en Finlande, plusieurs services publics ont également été retirés du réseau par précaution.

Au Danemark, la situation est différente : ce n’est pas l’État central qui a coupé des services, mais Kombit, l’organisation informatique des municipalités danoises. Plusieurs solutions ont été arrêtées totalement ou partiellement, dont Aula, la plateforme nationale de communication entre écoles et familles, ainsi que des systèmes municipaux.

Il s’agit donc moins d’un « mouvement de panique » que d’une mesure classique de réduction du risque : lorsqu’un système exposé ne peut pas être corrigé immédiatement, le retirer temporairement du réseau peut limiter la fenêtre d’attaque.

L’épisode rappelle surtout qu’un correctif logiciel et son déploiement réel sont deux choses différentes. Préparer quelques lignes de code peut prendre moins de temps que les distribuer sur des millions de serveurs, vérifier les dépendances, redémarrer les services et contrôler que tout fonctionne encore.

Ce que nous pouvons attribuer à l’IA, et ce que nous ne pouvons pas

C’est probablement la frontière la plus importante à conserver dans ce dossier.

Nous savons que l’IA a été utilisée dans la recherche défensive. Calif, OpenAI et Wiz le documentent explicitement. Wiz explique également que les modèles ont facilité l’adaptation et le débogage de chaînes d’exploitation complexes pendant les travaux de recherche.

Nous savons aussi que Cloudflare a observé des tentatives d’attaque et des variations de payloads dans la séquence de divulgation.

En revanche, rien dans les sources disponibles au 21 octobre 2026 ne permet d’affirmer que ces tentatives d’exploitation ont été produites ou pilotées par une IA.

Le patch-diffing, les scanners automatisés, les scripts d’exploitation et la circulation rapide de preuves de concept existaient bien avant les LLMLarge Language Model : modèle de langage entraîné sur d’énormes corpus pour prédire et générer du texte.. Ils suffisent déjà à expliquer pourquoi une vulnérabilité critique peut commencer à être testée très vite après la diffusion d’indices techniques.

OpenAI avance néanmoins une conséquence logique : les mêmes capacités qui permettent aux défenseurs de découvrir et de valider plus rapidement une vulnérabilité peuvent aussi aider des attaquants à développer plus vite des outils offensifs. C’est une capacité démontrée en recherche et anticipée dans ce contexte, pas une attribution des attaques observées aujourd’hui.

De wp2shell à PHP2Shell : la même course, vue depuis l’autre côté

Avec wp2shell, nous avions surtout observé la réduction du coût de la recherche et de l’exploitation : une chaîne complexe pouvait être découverte avec l’aide d’un modèle, puis l’exploitation automatisée apparaître très rapidement après la publication du correctif.

PHP2Shell montre l’autre moitié du problème.

Cette fois, les défenseurs ont eux aussi utilisé des modèles de pointe, travaillé avec les mainteneurs, préparé les fournisseurs cloud et les WAF, informé des organismes publics et construit des protections avant la publication. C’est exactement le scénario dans lequel l’IA donne un avantage aux défenseurs.

Mais cet avantage dépend d’une ressource difficile à compresser : le temps nécessaire pour coordonner les humains et déployer réellement les correctifs.

Une fuite, une vidéo publiée trop tôt ou un binaire contenant déjà le patch suffisent alors à réduire brutalement cette avance.

La fenêtre de sécurité devient le vrai sujet

Il est encore trop tôt pour dresser un bilan de PHP2Shell en nombre de compromissions ou de victimes. Ce bilan demandera des données que nous n’avons pas encore.

En revanche, la séquence du 20 et du 21 octobre permet déjà un constat plus modeste et plus solide.

Des modèles d’IA ont aidé à transformer des faiblesses anciennes et extrêmement complexes en vulnérabilités exploitables et corrigeables. Les défenseurs ont utilisé cette avance pour préparer des correctifs et des protections. Puis, dès que l’information a commencé à circuler, les mécanismes classiques de divulgation, de rétro-ingénierie et d’automatisation ont rapidement réduit cette avance.

L’IA accélère donc bien la découverte des vulnérabilités. Elle peut aussi réduire la barrière technique nécessaire pour les exploiter. Mais entre les deux reste une contrainte très concrète : mettre à jour une infrastructure réelle prend du temps.

PHP2Shell ne démontre pas encore que les attaquants pilotés par l’IA ont gagné la course. Il montre que la course elle-même se déroule désormais beaucoup plus vite.