L’IA trouve les failles plus vite. Le Web peut-il suivre ?
Avec PHP2Shell, l’IA a aidé des chercheurs à rendre exploitables des failles anciennes. Mais pour protéger les sites, il faut encore vérifier les signalements, corriger PHP et distribuer les mises à jour. Une course dont toutes les étapes ne s’accélèrent pas au même rythme.
Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux vulnérabilités critiques. PHP, c’est le langage qui fait fonctionner quantité de sites, notamment ceux construits avec WordPress, Drupal ou Joomla. Selon leur configuration, les serveurs concernés pouvaient laisser un attaquant lire des données sensibles ou leur faire exécuter son propre code, sans même avoir à se connecter.
L’affaire, connue sous le nom de PHP2Shell, montre ce que l’IA change dans la recherche de failles. Elle aide à découvrir des problèmes et à transformer des erreurs difficiles à exploiter en attaques fonctionnelles. Heureusement, elle aide aussi à vérifier les corrections. Mais entre une faille découverte et un serveur protégé, il reste pas mal de travail.
Photo d’illustration : serveurs de la Wikimedia Foundation (2012). Victor Grigas / Wikimedia Commons, CC BY-SA 3.0. Image redimensionnée.
Une faille connue, un danger devenu concret
Le problème se trouve dans le moteur de PHP lui-même. Une erreur fatale, notamment un manque de mémoire, peut interrompre un traitement en laissant des données internes dans un état incorrect. Un traitement suivant risque alors de réutiliser ces données. Cela ouvre la voie à des fuites d’informations ou à une prise de contrôle, même si le code du site est correctement écrit.
Une partie du problème avait été repérée dès 2024, raconte la Fondation PHP, qui finance des développeurs du langage. Mais aucun chemin concret vers une prise de contrôle à distance n’avait été trouvé. Les corrections envisagées posaient aussi des problèmes de compatibilité. Le travail avait piétiné.
Les recherches de 2026 ont levé le doute sur le danger. Parmi les équipes impliquées figure Wiz Research, l’équipe de recherche de Wiz, une entreprise de cybersécurité spécialisée dans la protection des infrastructures cloud, ces serveurs et services loués à distance. Ses chercheurs expliquent avoir utilisé plusieurs modèles d’IA pour mettre au point et adapter des attaques fonctionnelles en quelques heures. Ils en ont notamment démontré le fonctionnement sur des installations de WordPress, Drupal et Joomla.
En pratique, une attaque qui fonctionne sur une installation ne marche pas forcément sur la suivante. La version de PHP, sa configuration ou l’application peuvent imposer de nouveaux essais. Un modèle accompagné d’outils de test aide à comprendre les échecs, à modifier le code et à recommencer. C’est cette réduction du travail d’adaptation que décrit le compte rendu de Wiz. Le résultat est assez sérieux, sans en déduire que n’importe quel site tombe en quelques heures : ce délai correspond aux travaux rapportés par l’équipe.
Vérifier les signalements, puis corriger
Une démonstration d’attaque donne aux développeurs un moyen de reproduire le problème et de vérifier sa correction. Encore faut-il que le signalement tienne debout. Dans un bilan publié le 14 octobre, l’équipe de sécurité PHP comptait quinze vulnérabilités publiées depuis juillet, mais aussi 106 signalements clos : problèmes qui ne constituaient pas des failles, doublons ou erreurs impossibles à reproduire. Ce bilan ne permet pas d’attribuer ces 106 rapports à l’IA. L’équipe explique cependant que ces outils ont fait augmenter le nombre de rapports reçus. Chacun demande une vérification.
Les défenseurs s’en servent donc eux aussi pour trier les rapports, rapprocher ceux qui décrivent la même erreur et vérifier la portée des attaques annoncées. Wiz rapporte également leur emploi pour valider le correctif de PHP2Shell. L’assistance intervient ainsi des deux côtés : elle facilite la recherche de failles tout en aidant les équipes chargées de les traiter.
Mais corriger PHP demande de préserver le fonctionnement des applications et de leurs extensions. Une modification qui bloque l’attaque peut casser autre chose. Il faut tester ce compromis, puis décider. L’équipe PHP le rappelle : une personne examine chaque conclusion et écrit ou relit chaque correctif. Je serais assez circonspect devant une promesse de réparation automatique qui oublierait ce passage.
Du correctif aux serveurs
Une fois le code corrigé, il faut encore rendre la mise à jour installable. Les différents systèmes ont leurs propres versions et leurs propres méthodes de distribution. Le correctif doit y être intégré, vérifié, puis proposé sous forme de paquets, c’est-à-dire de logiciels prêts à installer. C’est à ce stade qu’intervient notamment Ondřej Surý, un développeur qui prépare des paquets PHP pour Debian et Ubuntu, deux systèmes Linux très utilisés sur les serveurs. Il explique faire largement ce travail sur son temps libre.
Cette étape a pesé sur le calendrier de PHP2Shell. Le 20 octobre, des informations sur les vulnérabilités ont commencé à circuler avant la date prévue. PHP a avancé sa sortie du 22 au 21 octobre. Publier immédiatement aurait laissé des utilisateurs sans moyen simple de se mettre à jour : les distributeurs préparaient encore leurs paquets.
À l’autre bout, les attaquants n’attendaient déjà plus. Amazon rapporte une tentative dès le 17 octobre, quatre jours avant la divulgation publique, contre ses serveurs pièges. Après la publication du correctif, d’autres démonstrations d’attaque sont apparues en quelques heures et ont été utilisées presque immédiatement contre ses capteurs. Amazon ne savait pas si les premières tentatives auraient réussi sur de vrais systèmes. Ces observations ne permettent pas non plus d’attribuer leur préparation à l’IA. Elles montrent en revanche le peu de répit laissé aux équipes qui doivent déployer les mises à jour.
Et le paquet disponible doit encore être installé. L’opération peut être automatisée, mais certains services demandent un redémarrage et certaines applications davantage de précautions. Trouver plus de failles ne raccourcit pas automatiquement toutes ces étapes.
La réussite technique est réelle. Pourtant, la Fondation PHP souligne aussi le manque d’ingénieurs expérimentés pour assurer ce travail. Gageons que les outils continueront de progresser. Les entreprises qui dépendent de ces logiciels peuvent aussi financer le travail nécessaire pour que leurs corrections arrivent jusqu’aux serveurs.
