L'injection de prompt est classée n°1 par l'OWASP, mais seulement n°12 dans les incidents recensés : l'attaque est indétectable par un scan
Une nouvelle analyse publiée le 18 août 2026 sur arXiv révèle un écart marqué entre la perception des experts en cybersécurité et les données réelles concernant l'injection de prompt, l'une des principales menaces visant les applications basées sur des modèles de langage. Cette technique occupe la première place du classement OWASP Top 10 des risques pour les applications LLM depuis trois années consécutives, mais elle ne se classe qu'en douzième position lorsqu'elle est confrontée à 6 639 incidents réels documentés. Cette étude a été menée par Kyriakos "Rock" Lambros, directeur des standards et de la gouvernance IA chez Zenity, et Steve Wilson, directeur IA et produit chez Exabeam, tous deux co-responsables du projet OWASP Top 10 pour les applications LLM. Les chercheurs ont compilé 7 714 incidents de sécurité liés aux LLM issus de bases comme CVE, GitHub Security Advisories, OSV et AIAAIC, puis en ont classé 6 639 selon une taxonomie de 20 catégories, en s'appuyant sur un modèle bayésien pour corriger les erreurs de classification. Le coefficient de concordance Cohen's kappa obtenu n'est que de 0,20, avec un intervalle de confiance à 90 % s'étendant de -0,16 à 0,57, ce qui signifie qu'aucun accord statistiquement fiable n'a pu être établi entre le jugement des experts et les données publiques d'incidents.
Résumé et traduction réalisés par Le Fil IA à partir de VentureBeat AI. Lire l'article original →
Cet écart s'explique par la nature même de l'attaque : l'injection de prompt dissimule des instructions malveillantes dans du contenu que le modèle lit ensuite, qu'il s'agisse d'un fichier journal, d'un ticket de support ou d'un document récupéré par un système de recherche documentaire. L'agent IA exécute alors l'action voulue par l'attaquant en utilisant ses propres identifiants légitimes, sans qu'aucune faille technique classique ne soit exploitée, ce qui rend l'attaque invisible aux scanners de vulnérabilités traditionnels et explique son faible nombre de CVE recensés. Pour les responsables de la sécurité informatique, cette découverte a une portée pratique immédiate, un faible score de vulnérabilités constatées ne doit pas conduire à sous-estimer ce risque, mais au contraire inciter à investir dans des contrôles architecturaux, comme des tests adversariaux sur les systèmes déployés et des limites strictes sur les capacités d'action des agents IA, plutôt que d'attendre des alertes qui, par construction, arriveront toujours trop tard.
Steve Wilson illustre concrètement la parade à privilégier, à travers l'exemple d'un agent qui lirait une charge malveillante dans un fichier journal et tenterait de modifier des enregistrements DNS avec des identifiants valides. Selon lui, la première mesure à déployer consiste à instaurer une porte d'autorisation externe au modèle, permettant à l'agent de proposer une action sans pouvoir s'octroyer lui-même l'autorité de l'exécuter, les règles de sécurité inscrites dans les prompts n'étant que des suggestions et non des contrôles réellement contraignants. Cette approche a un coût : l'agent perd sa capacité à improviser des changements d'infrastructure à fort impact de façon autonome, tout en conservant sa capacité d'investigation et de remédiation routinière bornée. Les auteurs précisent que leur analyse reste exploratoire, n'a pas fait l'objet d'une relecture par des pairs et ne remplace pas le classement officiel de l'OWASP ni son processus de validation, mais elle relance le débat sur la manière de mesurer et de prioriser les risques liés à l'intelligence artificielle générative dans les systèmes d'entreprise.
Pas d'impact direct sur la France/UE