PHP2Shell : l’IA accélère la course aux correctifs

Des agents d’IA trouvent des failles critiques plus vite que les équipes ne les corrigent. PHP2Shell en donne la mesure : comment s’organiser côté défense.

CyberPublié le 5 min de lecture
Illustration : dans une salle de serveurs, de petits drones lumineux posent des bandes de lumière bleue sur un panneau de code fissuré de rouge, comme pour réparer une faille.
Illustration générée par IA.

Le 21 octobre 2026, l’équipe de PHP a publié en urgence les correctifs de deux failles critiques, regroupées sous le nom PHP2Shell (CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10). Elles permettent d’exécuter du code sur un serveur web sans aucun compte, et concernent toutes les installations PHP qui servent des requêtes web. Les chercheurs de Wiz, de Calif et d’OpenAI qui les ont trouvées disent s’être appuyés sur des modèles d’IA.

Au-delà de sa gravité, l’affaire montre comment l’IA change la gestion des vulnérabilités : la découverte s’accélère, l’exploitation aussi, et le goulot d’étranglement se déplace vers la correction.

Des failles trouvées avec l’aide de l’IA

Selon Wiz, les modèles d’IA de pointe ont « fortement réduit » l’effort nécessaire pour transformer cette faiblesse ancienne de PHP en exploit fonctionnel. Les chercheurs affirment qu’une personne a pu faire en une semaine environ ce qui aurait demandé plusieurs mois à une équipe. Calif nuance : les modèles actuels « ne partent pas de façon fiable » de mécanismes obscurs vieux de vingt ans, et la connaissance de l’historique de PHP est restée déterminante. L’IA accélère l’expert, elle ne le remplace pas.

Ce travail s’inscrit dans Patch the Planet, un programme lancé le 22 juin 2026 par OpenAI et le cabinet Trail of Bits, avec HackerOne et Calif. Des modèles analysent des logiciels libres critiques (cURL, Python, Go, Sigstore, SQLite…) et des ingénieurs vérifient chaque résultat avant de contacter les mainteneurs. Le 22 octobre, le tableau de bord du programme affichait :

Étape Nombre
Bases de code examinées 68
Problèmes signalés 1 995
Correctifs rédigés 679
Correctifs acceptés par les projets 466

Ces chiffres sont publiés par le programme lui-même et n’ont pas été audités de façon indépendante. Ils donnent toutefois un ordre de grandeur : en quatre mois, près de 2 000 problèmes signalés, pour moins de 500 correctifs intégrés.

Les éditeurs de sécurité s’équipent aussi. Cloudflare utilise Daybreak, l’offre de cybersécurité qu’OpenAI a lancée en mai 2026, pour enquêter sur des vulnérabilités et proposer des correctifs soumis à une revue humaine. D’autres laboratoires d’IA proposent des programmes comparables, comme Anthropic avec son projet Glasswing.

Les attaquants vont aussi vite

L’avantage ne reste pas longtemps du côté des défenseurs. Pour PHP2Shell, les chercheurs d’Amazon ont détecté une première tentative d’exploitation le 17 octobre sur leurs pots de miel, quatre jours avant la publication des correctifs. La veille de cette publication, une démonstration de l’attaque avait été diffusée par erreur, et des tentatives d’exploitation ont été signalées dès 14 h 19 (UTC) le 21 octobre, moins de vingt minutes après la sortie du correctif.

Les attaquants utilisent eux aussi des agents. Le 21 octobre, Microsoft a décrit la campagne de Storm-0940, un groupe lié à l’État chinois, contre l’application ConnectWise Cloud Backup. Ses agents automatisés, construits avec l’outil ARTEX, ont mené des attaques par pulvérisation de mots de passe à près de 2 900 tentatives par minute. Dans certains cas, moins de trois heures se sont écoulées entre le premier ciblage et l’obtention d’un accès privilégié.

Quand la découverte et l’exploitation se comptent en heures, un cycle de correction mensuel ne suffit plus.

Ce qui change pour les équipes

La gestion des vulnérabilités reposait sur un rythme : un bulletin, une analyse, une fenêtre de maintenance. Trois choses changent avec l’IA :

  • Le volume : davantage de failles sont trouvées, y compris dans des composants anciens que l’on croyait éprouvés. Selon Wiz, toutes les versions de PHP publiées au cours des dix dernières années sont touchées par au moins une des deux failles de PHP2Shell.
  • Le délai : l’écart entre la publication d’un correctif et les premières attaques se réduit à quelques heures, parfois moins.
  • Le goulot : trouver n’est plus le plus difficile. Il faut savoir où tourne le composant, décider vite et déployer sans casser la production.

Automatiser sans perdre le contrôle

Les mêmes outils peuvent servir la défense, à condition de garder la main sur les décisions.

1. Savoir ce qui tourne réellement

Un inventaire qui s’arrête aux applications ne suffit pas. Pour PHP2Shell, c’est l’environnement d’exécution (PHP-FPM, mod_php, FrankenPHP…) qu’il fallait mettre à jour, puis redémarrer. Une distribution Linux peut aussi corriger un paquet sans changer son numéro de version : il faut vérifier la présence du CVE dans le journal des modifications du paquet.

2. Prioriser avec des sources fiables

Un score CVSS élevé ne dit pas si une faille est attaquée. Croisez plutôt :

  • les alertes du CERT-FR, qui signalent les menaces à traiter en priorité ;
  • le catalogue KEV de la CISA, qui recense les vulnérabilités exploitées dans la nature ;
  • l’exposition réelle du système : accessible depuis Internet ou non, données sensibles ou non.

3. Automatiser ce qui peut l’être sans risque

Mises à jour de sécurité automatiques des paquets système, reconstruction régulière des images de conteneurs, tests automatisés qui valident un correctif avant son déploiement : ces mécanismes absorbent le volume. Les correctifs proposés par une IA doivent passer par la même chaîne de tests et par une relecture humaine, comme le fait Cloudflare.

4. Préparer un plan B

Quand le correctif n’est pas encore disponible ou pas encore déployable, il faut des mesures d’atténuation : règles de pare-feu applicatif, désactivation d’une fonction, isolement d’un service. Pour PHP2Shell, ces mesures réduisaient le risque sans le supprimer. Elles font gagner quelques heures, pas davantage.

5. Surveiller les signes d’exploitation

Pour PHP2Shell, les signes à rechercher étaient des requêtes multipart inhabituelles suivies d’erreurs de mémoire, des erreurs HTTP 500 répétées, des cookies de session anormalement volumineux et des redémarrages inexpliqués des processus PHP. Préparer ce type de détection avant la prochaine faille fait gagner un temps précieux.

En résumé

  • L’IA multiplie les découvertes de failles, chez les chercheurs comme chez les attaquants.
  • Le délai entre correctif et exploitation se compte désormais en heures.
  • L’effort doit porter sur l’inventaire, la priorisation et un déploiement des correctifs automatisé mais contrôlé.

Sources

Articles liés