PHP2Shell : l’IA a aidé à trouver des failles RCE critiques dans PHP

Le 21 octobre, l’équipe PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent deux failles critiques permettant l’exécution de code à distance sans authentification : CVE-2026-109618 et CVE-2026-109619. Le même jour, Wiz Research les a décrites sous le nom de PHP2Shell et a révélé que les modèles Gemini 4 Argon et GPT-5.6 Sol avaient aidé à les trouver et à écrire l’exploit.

Qu’est-ce que la faille PHP2Shell ?

PHP2Shell, ce sont deux failles dans le moteur PHP lui-même, et non dans une application particulière. Toutes deux ont un score CVSS de 9,2. D’après l’avis publié sur php.net :

1. CVE-2026-109618 concerne la gestion du manque de mémoire (OOM). Le bug peut interrompre PHP alors que les données internes de la requête ne sont initialisées que partiellement, et le nettoyage de fin de requête les traite ensuite comme valides.
2. CVE-2026-109619 est un « état global obsolète » : l’état interne d’une requête peut survivre à la libération de la mémoire, et la requête suivante traitée par le même processus peut l’utiliser.

Toutes les installations PHP qui servent du trafic web sont exposées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le pire cas est mod_php, car c’est là qu’a été montré un exploit dans lequel une requête non authentifiée déclenche l’attaque avant même l’exécution du moindre code applicatif.

Selon Wiz, le code vulnérable se trouvait dans PHP depuis plus de dix ans, et le problème remonte jusqu’à PHP 5.4. Les chercheurs ont démontré l’exécution de code à distance sur les dernières images Docker de WordPress, Drupal et Joomla.

Quel rôle l’IA a-t-elle joué dans la découverte de PHP2Shell ?

Wiz explique avoir utilisé tout au long de ses recherches surtout son propre outil Wiz Atlas, ainsi que les modèles Gemini 4 Argon et GPT-5.6 Sol, et que Gemini 4 Argon a aidé à trouver la faille, à écrire l’exploit, à détecter l’attaque et à vérifier le correctif. Voici la chronologie tirée de l’article de Wiz :

1. 19 août 2026 : Wiz trouve la première faille.
2. 20 août : l’exécution de code à distance est confirmée sur Drupal.
3. 21 août : même chose sur WordPress.

Autrement dit, il s’est écoulé deux jours entre la découverte du bug et une attaque fonctionnelle contre WordPress. Wiz explique que les failles existaient depuis longtemps et que prouver leur exploitabilité exigeait une chaîne d’étapes très complexe, mais que les modèles d’IA ont « substantially reduced that barrier, turning a longstanding flaw into an exploit ». Raluca Ada Popa, responsable de la sécurité de Gemini chez Google DeepMind, a commenté que Wiz avait montré « why frontier AI is a game-changer for cyber defense ».

Google n’est pas seul. D’après heise, la première équipe à les trouver était Calif, qui auditait le code avec la PHP Ecosystem Security Team dans le cadre de l’initiative « Patch the Planet » d’OpenAI. Wiz et OpenAI ont reproduit les failles à l’aide de LLM et ont aidé à relire le correctif.

Pourquoi cela fait-il autant de bruit ?

D’abord, l’ampleur. WordPress, Drupal et Joomla tournent sur PHP, et la faille se déclenche avant le code de l’application. L’annonce du correctif sur la liste php.announce a récolté plus de 1300 points sur Hacker News avant même la publication des détails.

Ensuite, la fuite. Selon heise, la divulgation était prévue pour le 22 octobre, mais elle a été avancée d’un jour parce que des informations avaient fuité. SecurityWeek rapporte que watchTowr a reproduit CVE-2026-109618 avant même les correctifs, et Sansec prévoit que les attaques massives commenceront « within 15 minutes of the patch release ». Pour l’instant, ni watchTowr ni Huntress n’ont observé d’exploitation dans des attaques réelles.

Enfin, la tendance. Comme avec Claude Mythos chez Bank of America, les modèles d’IA trouvent des bugs graves plus vite que les humains ne parviennent à les corriger. Sauf que les attaquants disposent des mêmes outils, comme l’a bien montré la cyberattaque par IA sur la plateforme Cairn.

Que faire si l’on utilise PHP ?

1. Mettons à jour PHP vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Selon php.net et Wiz, c’est la seule protection complète.
2. Selon heise, les anciennes branches 7.4, 8.0 et 8.1 doivent recevoir des backports, et les distributions Linux doivent publier des paquets dans les heures qui viennent.
3. Avec Docker, il faut récupérer la nouvelle image et redémarrer le conteneur.
4. Vérifions aussi le matériel doté d’une interface web en PHP : NAS, routeurs, appliances (heise cite notamment pfSense, QNAP et Synology).
5. En attendant la mise à jour, les règles WAF de Cloudflare, Akamai ou AWS aident, mais l’équipe PHP qualifie les contournements de configuration de « a temporary crutch ».

(sur un hébergement mutualisé, demandez à votre hébergeur quand il installera les correctifs)

FAQ

PHP2Shell concerne-t-il WordPress ?

Oui. Wiz a démontré l’exécution de code à distance sur la dernière image wordpress:latest, ainsi que sur Drupal et Joomla. La faille se trouve dans PHP : c’est donc la mise à jour de PHP qui protège, pas celle de WordPress.

Quelles versions de PHP sont sûres ?

PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026, et les versions ultérieures. Les versions plus anciennes doivent être considérées comme vulnérables.

Les failles sont-elles déjà exploitées ?

Selon SecurityWeek, watchTowr et Huntress n’ont pas observé d’attaques réelles, mais les détails ont fuité avant la divulgation et Sansec s’attend à des attaques massives juste après la sortie des correctifs.

Qui a découvert PHP2Shell ?

Selon heise, l’équipe Calif a été la première, dans le cadre de « Patch the Planet » d’OpenAI. Wiz Research a décrit les failles sous le nom de PHP2Shell et les a trouvées avec l’aide de Gemini 4 Argon et GPT-5.6 Sol.