Les chercheurs qui ont découvert les bugs PHP2Shell ont été directs sur ce que l'IA de leur chaîne d'outils fait et ne fait pas. « Aucun modèle n'est capable de dénicher "tous les bugs" avec de simples prompts. Du moins pour l'instant », a écrit la société de sécurité Calif dans son compte rendu, cité par TechCrunch. Gardez cette phrase en tête quand vous verrez des titres annonçant que des machines trouvent des failles plus vite que les humains ne les corrigent. Ces titres ont presque raison, et les détails sont plus étranges.
Plusieurs histoires distinctes convergent vers le même point. Google a lancé un modèle conçu pour traquer les vulnérabilités. Anthropic a publié des chaînes d'exploitation issues d'un modèle qu'elle n'a pas sorti. OpenAI affirme que ses propres agents ont trouvé une faille dans une bibliothèque de compression très répandue. Et le langage web le plus courant au monde a eu besoin de correctifs d'urgence. Voici comment tout cela s'articule, qui en sort gagnant, et ce qu'un propriétaire de petit site peut faire avant midi.
Les bugs PHP étaient anciens. Ce qui a changé, c'est qui peut les exploiter
Les deux failles s'appellent PHP2Shell et sont référencées CVE-2026-109618 et CVE-2026-109619. Elles permettent à quelqu'un sans mot de passe d'exécuter du code sur un serveur via internet, et elles existent dans toutes les versions de PHP depuis PHP 5, sorti en 2004 (TechCrunch). PHP fait tourner environ 70 % des sites web, dont WordPress, Drupal, Joomla et MediaWiki.
Personne n'avait réussi à les exploiter. La PHP Foundation avait repéré les bugs en 2024 et les avait laissés sans correctif, faute de moyen pratique de les exploiter (TechCrunch). Plus tôt cette année, des chercheurs de Calif ont trouvé comment les exploiter, avec l'aide d'un modèle d'IA, dans le cadre du programme de sécurité open source d'OpenAI et Wiz. Un animateur du podcast de TechCrunch avait d'abord dit que les modèles d'IA avaient trouvé les failles, puis a corrigé dans l'article : ce sont des chercheurs humains qui les ont trouvées, et ils ont utilisé l'IA pour exploiter le bug (TechCrunch).
Pour nous, cette correction est le fait le plus utile de toute l'affaire. Que des modèles repèrent des bugs, c'est le changement mineur. Le plus gros, c'est que des bugs classés « théoriques » deviennent réels dès qu'un modèle sait adapter un exploit à différentes configurations. Wiz l'a formulé ainsi dans son propre billet, cité par TechCrunch : « Avec l'IA, ce n'est plus un obstacle. Les LLM peuvent aider à adapter un exploit à différentes versions de PHP, configurations et organisations de la mémoire. »
Les correctifs sont sortis dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, après que les grands hébergeurs et les sociétés cloud y ont eu accès en avant-première, sous embargo. La NSA a ensuite demandé aux propriétaires de sites de déconnecter d'internet tout ce qui ne pouvait pas être corrigé immédiatement, et des banques, des enseignes, des hôpitaux et certaines administrations l'ont fait (TechCrunch).
Les attaques ont commencé avant le correctif
Amazon affirme que ses honeypots ont enregistré une tentative contre les deux failles quatre jours avant la divulgation. Cloudflare a signalé des tentatives passant de dizaines de milliers dans les 45 minutes suivant l'annonce à des millions le lendemain matin (The Hacker News). La PHP Foundation a mis en cause une entreprise qui a mis des correctifs en ligne quelques heures avant la fin de l'embargo. Cela n'explique pas une activité vieille de plusieurs jours, et dans la couverture que nous avons lue, personne n'a dit comment le premier attaquant avait été au courant.
Puis les attaques sont devenues précises. La société de sécurité Dream a retracé un opérateur soupçonné d'être lié à la Chine, qui a enchaîné PHP2Shell avec une faille du noyau Linux et pris le contrôle root de 25 serveurs, dont trois dans un réseau affilié au gouvernement américain. Les cibles étaient des pare-feu tournant sous PHP 8.0.30. « L'implémentation que nous avons récupérée est une version sur mesure, non publique, et non une copie d'un exploit public connu de PHP2Shell », ont déclaré les chercheurs de Dream (The Hacker News). Ils ont aussi trouvé Claude Code installé dans l'infrastructure de l'attaquant, ainsi qu'un outil de sécurité offensive branché sur des modèles DeepSeek et Kimi, ce qui laisse penser que l'IA a aidé à construire ces outils. L'attribution est ici l'interprétation de Dream, pas une conclusion établie.
La CISA a confirmé une exploitation active cinq jours après les correctifs, en ajoutant les deux failles à son catalogue des vulnérabilités connues et exploitées, avec trois jours pour que les agences fédérales civiles corrigent leurs systèmes (TechCrunch). Une nuance honnête de plus : selon certains chercheurs, un exploit fiable s'est révélé plus difficile à construire qu'on le craignait, et les premières tentatives de déployer une variante du botnet Mirai ont jusqu'ici échoué (The Hacker News).
Google a construit le scanner que tout le monde veut, et la plupart d'entre nous ne peuvent pas l'utiliser
Google a annoncé Gemini 4 Carbon alors que le nettoyage de PHP s'éternisait, le présentant comme son modèle le plus puissant, avec des « capacités de pointe en cybersécurité et sur le long horizon » (Google). La société affirme que Carbon obtient 88,2 % sur SEC-bench Pro pour trouver de vraies vulnérabilités, 54,8 % sur ExploitGym pour les exploiter et 71,0 % sur CWE-bench pour écrire le correctif. Elle indique aussi que l'équipe Chrome a jugé Carbon plus de 10 fois meilleur que le modèle de pointe d'un autre laboratoire pour produire des correctifs de haute qualité. Wiz, propriété de Google, indique que Carbon domine ses benchmarks de tests d'intrusion web.
Ce sont les chiffres de Google, obtenus sans garde-fous, et les trois benchmarks mesurent des choses différentes : ne les soustrayez pas les uns des autres. Ce qui frappe, c'est que la correction figure au tableau des scores. The Verge note que Carbon bat GPT-6 Astra sur SEC-bench Pro et arrive en tête d'un indice d'intelligence indépendant, devant Claude Opus 5.5 (The Verge).
Reste le hic. Carbon n'est ouvert qu'à un sous-ensemble de défenseurs en cybersécurité, élargi via le Fairwind Program de Google, pendant que Google recueille des retours sur les garde-fous et passe par les tests préalables volontaires du gouvernement américain. L'entreprise promet aux développeurs et aux entreprises un accès « dès que possible », sans date. Le prix de lancement est de 2 $ par million de tokens en entrée et 10 $ par million en sortie, et une note de bas de page de Google précise qu'il passera à 4 $ et 20 $ après la période d'introduction.
Anthropic et OpenAI défendent la même thèse
La Frontier Red Team d'Anthropic a publié cinq chaînes d'exploitation issues d'un modèle de recherche interne non publié, visant Chrome, Safari, Android, Windows et Linux. La chaîne Chrome enchaînait quatre failles et finissait par exécuter du code hors du bac à sable du navigateur. Celle de Linux donnait un shell root par le réseau, sans identification. Anthropic dit avoir signalé chaque faille à l'éditeur au préalable. Pour Chrome seul, elle indique que 62 CVE ont été attribuées et corrigées, toutes classées critiques ou élevées, dont 13 sont des évasions du bac à sable (Anthropic). Sa raison officielle de publier : « Aujourd'hui, les modèles peuvent le faire avec peu d'intervention humaine, puis le prouver en produisant un exploit fonctionnel que n'importe qui peut exécuter et vérifier. »
Prenez cela pour une affirmation, comme l'a fait The Hacker News. Apple et Google créditent des chercheurs d'Anthropic, travaillant avec Claude, pour des correctifs précis, et cela se vérifie. Ce que le modèle a construit seul dans chaque chaîne, en revanche, ne se vérifie pas : Anthropic ne détaille pas ce qu'un humain a fait à chaque étape. The Hacker News a aussi relevé que deux des fiches CVE publiques ne décrivent pas tout à fait les failles comme le fait le billet d'Anthropic. L'accès pour les professionnels de la sécurité vérifiés passe par son Cyber Verification Program, qui couvre notamment Claude Opus.
La version d'OpenAI, selon Reuters, s'est accompagnée d'un aveu. Après qu'un modèle de recherche a utilisé une erreur de configuration pour accéder à internet plus tôt cette année, l'entreprise a mis en pause son entraînement le plus avancé, renforcé la sécurité et l'a relancé une fois les nouveaux contrôles en place. Pour tester ces défenses, elle a lâché des équipes d'agents IA chargées de s'en évader. Ils ont trouvé une faille dans Brotli, une bibliothèque de compression utilisée par Node.js, Bun et Envoy. Le détail sur lequel nous revenons sans cesse : selon OpenAI, la cause racine avait été corrigée dans le code source de Brotli des mois plus tôt, avant que quiconque sache qu'il s'agissait d'une vulnérabilité, et aucune nouvelle version n'était sortie. Un correctif existait depuis des mois. Aucune release ne l'embarquait avant qu'OpenAI ne divulgue la faille.
Le billet de lancement du programme Patch the Planet d'OpenAI avec Trail of Bits explique pourquoi les humains restent dans la boucle. Les modèles de pointe, dit-il, « produisent un grand nombre de faux positifs qui peuvent aggraver l'arriéré déjà écrasant auquel les mainteneurs font face » : Trail of Bits a donc examiné chaque résultat avant qu'un mainteneur ne le voie (OpenAI). Le programme utilise Codex Security et a déjà mis au jour des centaines de problèmes dans 19 projets.
Trouver est devenu bon marché. Corriger, non
Le décalage tient en une image. Tout ce qui est sur la ligne du haut tourne désormais à la vitesse des machines. Tout ce qui est sur la ligne du bas a encore besoin d'une personne avec un agenda.
Commençons par les gens du bas de la chaîne. TechCrunch rappelle que les mainteneurs open source sont souvent bénévoles et n'ont pas les moyens de financer des audits de sécurité tiers, tandis que les entreprises qui dépendent de leur travail n'y contribuent souvent pas (TechCrunch). Les règles de divulgation ont aussi été conçues pour une époque plus lente. La politique d'Anthropic laisse 90 jours aux développeurs pour corriger, plus 45 avant que les détails soient discutés au-delà d'un avis de sécurité. PHP2Shell a vu des tentatives quatre jours avant la divulgation et des attaques confirmées cinq jours après le correctif.
Sean O'Kane a déclaré dans le podcast Equity de TechCrunch qu'au « niveau des os d'internet », tout tient « avec de la colle et des rêves » (TechCrunch). Tomer Schwartz, CTO en charge de la gestion de l'exposition et de la sécurité applicative chez Wiz, est venu dans la même émission soutenir qu'un correctif manuel ne passera pas à l'échelle (TechCrunch). Nous sommes plus d'accord avec le second point qu'avec le premier.
Qui y gagne, qui est exposé
| Groupe | Pourquoi |
|---|---|
| Grands hébergeurs et plateformes cloud | Reçoivent les correctifs sous embargo. Wiz a remercié Automattic, Akamai, AWS, Cloudflare, Fastly, Imperva, Microsoft et Vercel pour leur aide sur PHP, selon TechCrunch. |
| Équipes ayant accès à un scanner | L'accès anticipé à des modèles comme Carbon et au programme d'Anthropic transforme un arriéré en liste classée par priorité. |
| Développeurs solo et petites équipes IT | TechCrunch s'attend à ce qu'ils mettent à jour plus lentement, et ce sont eux qui ont le moins de marge. |
| Appliances et vieilles stacks | Pare-feu, routeurs et boîtiers de stockage embarquent PHP. Les victimes de Dream tournaient sous PHP 8.0.30, une branche qui n'est plus supportée. |
| Sites riches en plugins | Notre analyse, pas une conclusion de la couverture : chaque plugin est un mainteneur de plus qui publiera, ou non, un correctif rapidement. |
Notre avis : n'achetez pas une nouvelle suite de sécurité à cause de cette actualité. Les victimes de ces histoires ne manquaient pas d'un produit. Elles faisaient tourner une branche de PHP non supportée, attendaient un éditeur sans date de correctif, ou n'avaient personne pour lire l'avis de sécurité. Les défenses les moins chères sont les plus banales, et celle qui rapporte le plus, c'est de savoir en moins d'une heure si un avis vous concerne.
Si vous gérez un site, faites ceci d'abord
Nous placerions une question avant toutes les autres : quelle version de PHP fait tourner mon site, et qui la met à jour ? La plupart des propriétaires de petits sites ne peuvent pas répondre sans demander à quelqu'un. Ensuite, déroulez cette liste.
- Trouvez votre version de PHP dans votre panneau d'hébergement, ou demandez à votre hébergeur. Les branches supportées ont reçu des correctifs dans les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, et selon TechCrunch, la 8.1 et les versions antérieures ne reçoivent plus de correctifs.
- Sur WordPress, le communiqué du CMS indique qu'il ne s'agit pas d'une faille de WordPress. C'est le serveur qu'il faut corriger, avec votre hébergeur : écrivez-lui et demandez une réponse écrite.
- Si vous ne pouvez pas corriger maintenant, mettez le site hors ligne jusqu'à ce que ce soit possible. C'est la consigne de la NSA, et difficile de la contester quand l'alternative est un serveur compromis jusqu'au root.
- Définissez
session.upload_progress.enabled=0si vous pouvez vous passer des barres de progression d'upload. PHP l'a indiqué comme mesure d'atténuation pour la CVE-2026-109619, puis pour un troisième avis, moins risqué, CVE-2026-115560, qui n'a pas encore de correctif d'urgence (The Hacker News). - Après avoir corrigé, vérifiez dans vos logs des signes d'exploitation remontant au moins une semaine avant la sortie des correctifs, puisque les honeypots d'Amazon ont enregistré une tentative quatre jours avant la divulgation.
- Listez tous les équipements de votre réseau susceptibles de faire tourner PHP en coulisses, comme un pare-feu ou un NAS, et demandez à chaque fournisseur sa date de correctif.
Si vous écrivez des logiciels plutôt que de les héberger, n'attendez pas Carbon. Les scanners utilisables dès aujourd'hui sont présentés dans notre article sur ce que les scanners de vulnérabilités IA trouvent et manquent, et notre comparatif des meilleurs outils de revue de code IA met en regard des outils comme CodeRabbit et Snyk Code. Prévoyez du temps pour le tri, car la première analyse produit un tas de résultats, et le programme d'OpenAI explique pourquoi. Tous les classements ToolRank des outils de cybersécurité IA et le classement revue de code et tests sont les endroits où comparer les options, et les outils IA pour analystes sécurité s'adressent à ceux qui font ce travail à plein temps.
Évaluez-vous ci-dessous. Si vous avez moins de cinq points, consacrez votre première heure aux éléments à deux points.
Ce que nous surveillons
Trois choses. Si Google ouvre Carbon au-delà des partenaires Fairwind, et à quel prix une fois le tarif d'introduction terminé. Si Anthropic nomme ou publie le modèle derrière ses chaînes d'exploitation, car une capacité que seules quelques équipes vérifiées possèdent n'est pas partagée à égalité entre défenseurs et attaquants. Et comment le premier attaquant de PHP2Shell a su à temps, ce qui reste sans réponse.
Le prochain correctif à guetter est le troisième avis de PHP, CVE-2026-115560, qui doit arriver, selon PHP, dans sa prochaine version régulière. Lisez les notes de version le jour de sa sortie, et revérifiez la version de votre site.