Distributeur automatique de vulnérabilités : une IA qui trouve et exploite des zero-days

De quoi s’agit-il ?

Le 15 juillet 2026, la société de sécurité Intruder a publié le compte rendu de ce qu’elle appelle un distributeur automatique de vulnérabilités : un pipeline automatisé qui associe l’analyse de programme classique à des grands modèles de langage et qui, selon l’équipe, transforme des tokens d’IA en zero-days. La démonstration est concrète et non théorique — le pipeline a fait émerger plus de 300 résultats sur du code réel et, dans au moins un cas, a mené une faille de la découverte jusqu’à un exploit fonctionnel sans intervention humaine.

Le résultat le plus marquant est une injection SQL non authentifiée, jusque-là inconnue, dans un plugin d’e-mail marketing WordPress très répandu, utilisé sur plus de 300 000 sites. La faille elle-même a reçu un identifiant CVE et a été divulguée publiquement en mai 2026 ; ce qui est nouveau dans la publication de juillet, c’est la révélation de la mécanique qui l’a produite. Il s’agit ici de rendre compte d’une démonstration de capacité offensive par un acteur identifié, appuyée sur des vulnérabilités déjà documentées publiquement — pas d’un mode d’emploi. Nous ne reproduisons pas la technique d’injection.

Comment ça marche

L’astuce centrale du pipeline n’est pas « demander à un LLM de trouver des bugs dans ce fichier ». Fournir un dépôt entier à un modèle produit du bruit : failles hallucinées, flux de données inter-fichiers manqués, fenêtres de contexte saturées avant d’atteindre le chemin intéressant. L’approche d’Intruder repose au contraire sur le code slicing — une technique d’analyse de programme qui extrait uniquement les instructions pertinentes pour une variable ou un point sensible donné — afin de fournir au modèle une tranche de code réduite et sémantiquement complète plutôt qu’un dépôt entier. Le LLM raisonne sur cette tranche ciblée, propose des vulnérabilités candidates, et le cadre tente ensuite de les valider.

D’après le compte rendu, l’exécution a produit un large éventail de types de failles : exécution de code à distance sans authentification, injection SQL dissimulée derrière des annotations de désactivation de linter, élévation de privilèges via le système de hooks de WordPress, falsification de requête côté serveur (SSRF) et une chaîne d’attaque par rétrogradation. Le cas du plugin d’e-mail est éclairant précisément parce qu’il s’agit du genre de bug que les scanners classiques ratent : il est non authentifié mais accessible seulement lorsqu’un plugin e-commerce complémentaire est installé, et il exige plusieurs requêtes chaînées pour se déclencher, si bien qu’aucune signature à requête unique ne réagit. À noter, l’équipe indique avoir travaillé avec des modèles de pointe disponibles avant le palier Mythos — l’idée étant que cette capacité ne dépend pas d’un modèle non encore publié.

Pourquoi c’est important

L’enjeu est économique autant que technique. Help Net Security a résumé la même tendance en mai 2026 par un chiffre brutal — environ 20 dollars par zero-day est déjà la réalité des plugins WordPress — et l’image du distributeur automatique rend l’incitation explicite : si une faille coûte quelques dollars d’inférence à trouver, ratisser tout un écosystème de plugins devient rationnel pour les attaquants, pas seulement pour les chercheurs. Le marché des plugins WordPress, avec ses dizaines de milliers d’extensions de qualité de code très inégale, en est une surface de cible presque idéale.

C’est le miroir offensif d’une tendance que nous suivons côté défense. Cela fait écho à l’intégration par Microsoft de la découverte assistée par IA dans le cycle de correctifs Windows, au déluge de signalements de vulnérabilités open source dopé par l’IA, et à des pipelines de recherche comme la découverte en boucle fermée OpenAnt de Knostic et le scan multi-modèles MDASH de Microsoft. La même capacité qui permet à un défenseur d’anticiper les bugs permet à un attaquant de les distribuer ; le facteur décisif est de savoir qui exécute le pipeline et à quelle vitesse les mainteneurs réagissent. Cela s’inscrit aussi dans le schéma des empreintes de zero-days rédigés par IA : les failles trouvées par IA deviennent une entrée courante de l’économie de la divulgation plutôt qu’un événement exotique.

Défenses

Pour les mainteneurs de plugins et d’applications, la leçon actionnable est que les causes racines ici sont anciennes et corrigeables. L’injection SQL existait parce qu’une entrée utilisateur atteignait une requête sans paramétrage — la mitigation standard, ce sont les requêtes préparées ($wpdb->prepare() sous WordPress) et une validation stricte de chaque paramètre contrôlable de l’extérieur, y compris ceux qui ne sont atteignables qu’à travers un second composant installé. Ne traitez pas une annotation de désactivation de linter comme une sécurité : le pipeline a précisément trouvé une injection dissimulée derrière un commentaire d’exclusion PHPCS, or supprimer un avertissement d’analyse statique ne supprime pas le bug, cela le cache seulement au prochain relecteur. Cartographiez les chemins d’interaction entre plugins, car « non authentifié mais exploitable uniquement si le plugin X est aussi présent » est exactement la condition composite que l’outillage automatisé excelle désormais à trouver et que la relecture humaine a tendance à négliger.

Pour les exploitants, partez du principe que vos dépendances sont scannées à la vitesse de la machine et calez votre cadence de correctifs en conséquence. Inventoriez les plugins et leurs dépendances complémentaires, abonnez-vous aux flux de vulnérabilités pour ceux que vous utilisez, et priorisez selon l’exploitabilité et l’exposition plutôt que de traiter chaque avis de la même manière. Accordez le moindre privilège aux comptes de base de données afin qu’une injection en lecture ne puisse atteindre les hachages d’administrateur et les secrets, placez un pare-feu applicatif (WAF) devant les schémas de requêtes chaînées, et surveillez les séquences de requêtes multi-étapes que la détection à signature unique manque. L’enseignement plus large : l’IA réduit le coût de découverte des classes de bugs banales et bien comprises — la victoire défensive reste donc de livrer du code qui en est exempt, et de réduire la fenêtre entre divulgation publique et correctif déployé.

Statut

Élément	Détail
Divulgation	Intruder, « We built a vulnerability vending machine », 15/07/2026
Méthode	Code slicing + raisonnement LLM sur des tranches ciblées, avec validation automatisée
Portée signalée	300+ résultats : RCE non authentifiée, injection SQL, élévation de privilèges, SSRF, chaînes de rétrogradation
Cas phare	Injection SQL non authentifiée dans le plugin WordPress Creative Mail (Constant Contact), 300 000+ installations ; accès en lecture à la base ; nécessite WooCommerce ; CVE-2026-3985 (CVSS 7.5), affecte ≤ 1.6.9, divulguée en mai 2026
Modèles utilisés	Modèles de pointe disponibles avant le palier Mythos
Nature	Démonstration de capacité offensive sur des vulnérabilités divulguées publiquement ; aucun exploit reproduit ici

Cet article synthétise les informations de l’éditeur et de sources tierces au 15 juillet 2026. La disponibilité d’un correctif pour le plugin cité a pu évoluer depuis la divulgation de mai 2026 — vérifiez la version corrigée actuelle sur le dépôt de plugins WordPress avant de vous appuyer sur toute mitigation.