~14 minutes
L’OWASP GenAI Security Project a publié le Top 10 for LLM Applications 2026 le 4 août dernier. Nouveauté cette année : le classement croise pour la première fois le vote des experts OWASP avec plus de 6000 incidents réels analysés, et les deux ne racontent pas la même histoire. Prompt Injection reste numéro un par vote, mais sort carrément du top 10 si on ne regarde que les incidents publics.
Source : OWASP GenAI Security Project — OWASP Top 10 for LLM Applications 2026, version datée du 4 août 2026.
Rappel sur la version 2025 : la liste complète, puis chaque entrée en détail, de LLM01 à LLM10. Dix-huit mois plus tard, l’écosystème a bougé assez pour justifier une refonte complète du classement, pas juste un toilettage de vocabulaire. Cet article compare les deux éditions elements par elements et détaille ce qui a vraiment changé
Note du PandaRedacteur : chaque sortie d’un Top 10 OWASP déclenche la même valse sur LinkedIn : “Voici les 10 risques IA à connaître”, posté par quelqu’un qui n’a manifestement lu que le sommaire. Ce document explique pourquoi le classement a bougé. Ce serait dommage de s’arrêter au tableau.
Ce qui change dans la méthode
C’est le vrai changement de cette édition, largement plus important que n’importe quel mouvemen.
Jusqu’ici, chaque version du Top 10 LLM se construisait sur un vote de centaines d’experts : qu’est-ce qui vous inquiète le plus ?
Cette année, l’équipe du projet a ajouté un deuxième axe. Elle a compilé un corpus de plus de 6000 incidents réels, tirés de bases de vulnérabilités publiques et d’une base de données liés à l’IA, puis construit des classificateurs pour trier ce qui contenait assez de détail exploitable : plus de 6000 incidents ont passé le filtre.
Question : Est-ce que ce que les experts redoutent correspond à ce que montre l’historique des incidents ?
Réponse : pas toujours. Et les écarts sont plus instructifs que les points d’accord.
Le cas Prompt Injection est le plus parlant. Les experts le classent numéro un, sans hésitation. Classez les catégories par volume brut d’incidents documentés, et il sort intégralement du top 10 ! Pas de contradiction ici, un effet de défense : les équipes matures se battent fort contre ce risque, ce qui veut dire que peu d’exploitations propres finissent dans une base publique, et le comptage public sous-estime donc un risque sur lequel les équipes sérieuses dépensent déjà de l’argent réel pour tenir la ligne. La surface reste partout où un modèle lit de l’input non fiable, ce qui revient à dire : partout. Vous ne pouvez pas fermer cette surface, alors vous construisez pour le jour où elle sera utilisée contre vous.
Misinformation va dans l’autre sens, et c’est l’entrée sur laquelle je vous recommande de ralentir. Le vote la place près du bas. L’historique d’incidents la place près du haut, l’écart le plus large dans le sens qui fait mal.
Résultat de compromis : elle atterrit au milieu du classement, le vote pesant plus lourd, mais l’évidence l’a clairement tirée vers le haut. Quand une sortie fluide et confiante d’un modèle déclenche une décision ou un appel d’outil, une mauvaise réponse devient une mauvaise action, et l’historique montre que cet échec arrive plus souvent que ce que le vote seul laisse penser.
Comment la pondération a été faite :
- le vote de la communauté compte pour trois quarts,
- les données d’incidents pour le quart restant.
Volontairement. Ce Top 10 reste un produit de consensus, et une année de données bruyantes ne doit pas réécrire seule le jugement collectif des experts. Un quart de poids suffit à faire bouger une entrée d’un cran quand l’écart entre croyance et évidence est large. Ça ne suffit pas à laisser des données imparfaites réécrire la liste toutes seules.
Prompt Injection tient la première place sur la force du vote et de l’effet de défense qui le sous-compte dans les statistiques publiques. Misinformation, elle, doit sa remontée aux faits, pas aux craintes.
Note du PandaRedacteur: Je milite depuis 2006 au sein de l’OWASP, et le calcul des fameux Top10 a toujours faire polémique. M’es d’avis que ici encore une fois on va en parler
2025 vs 2026 vue globale
Trois familles de mouvement, on va les traiter séparément parce qu’elles ne racontent pas la même histoire.
Rangs inchangés : LLM01 Prompt Injection et LLM02 Sensitive Information Disclosure. Le seul endroit du classement où croyance et évidence se rejoignent purement, l’OWASP le dit lui-même, et c’est aussi là que la confiance dans le classement est la plus haute.
Escalades : Excessive Agency grimpe de la sixième à la troisième place, le mouvement le plus lourd de conséquences de toute la liste selon l’équipe du projet, parce que vote et données d’incidents s’accordent pour dire que les déploiements agentiques sont là où les dégâts atterrissent réellement.
Chutes : Improper Output Handling s’effondre de la cinquième à la dixième place, la chute la plus marquée du classement. Supply Chain et Data and Model Poisoning (probablement aussi a cause du focus OWASP Top10 Web 2025 sur la SCA) reculent chacun d’un cran, sans disparaître de l’attention, simplement dépassés par des risques jugés plus urgents cette année.
Renommage : System Prompt Leakage (LLM07 en 2025) devient Hidden Context Exposure (LLM08 en 2026), pas une simple étiquette différente sur le même contenu.
Focus sur -> LLM03:2026 Excessive Agency
Anciennement LLM06:2025. C’est le mouvement que l’OWASP qualifie lui-même de plus lourd de conséquences, et on ne peut qu’etre d’accord.
La définition reste stable : la capacité d’un système LLM à causer des dégâts en réponse à des sorties inattendues, ambiguës ou manipulées, indépendamment de la cause du dysfonctionnement (hallucination, injection directe ou indirecte, outil compromis, agent pair compromis dans un système multi-agents). Trois racines : fonctionnalité excessive, permissions excessives, autonomie excessive.
Ce qui a changé, c’est le poids qu’on lui accorde, pas le mécanisme. En 2025, c’est un risque documenté mais secondaire. En 2026, c’est le troisième risque le plus critique de tout l’écosystème LLM, parce que l’année écoulée a vu les déploiements agentiques passer du prototype à la production, avec des agents qui appellent des outils, gardent de la mémoire entre sessions, et enchaînent des actions sans validation humaine systématique. Le document établit explicitement une frontière avec le nouveau Top 10 OWASP pour les Applications Agentiques (ASI) : ce Top 10 LLM garde la responsabilité tant que le modèle reste un composant de votre application ; dès qu’il devient un acteur autonome avec des outils, de la mémoire persistante et des conséquences en aval, le risque bascule vers ASI02 (Tool Misuse & Exploitation), ASI03 (Identity & Privilege Abuse) et ASI08 (Cascading Failures).
Concrètement, si vous avez lu mon article sur les 7 risques MCP côté CISO, vous reconnaîtrez le terrain : Excessive Agency est le versant LLM Top 10 de ce que je documentais côté MCP. Les deux référentiels convergent sur le même diagnostic, avec des vecteurs d’entrée légèrement différents.
LLM04:2026 Supply Chain
Anciennement en troisieme position , il recule d’un cran. Ce n’est pas un satisfecit sur la maturité de l’écosystème, l’OWASP est clair là-dessus : le déplacement reflète une priorité relative, pas une disparition du risque.
Le contenu de Supply Chain s’étoffe en revanche sensiblement. L’édition 2026 absorbe explicitement ce que j’appellerais le problème de la promotion silencieuse : un artefact de modèle promu (adaptateur LoRA, checkpoint fine-tuné, sortie de conversion de format) qui n’est pas ce qu’il prétend être.
Les workflows de fusion et de conversion de modèles (merge, quantization) deviennent des surfaces d’attaque à part entière, documentées avec des scénarios précis comme le détournement du bot de conversion Safetensors sur Hugging Face.
C’est exactement la famille de problème qu’on retrouve dès qu’un dépôt de modèle exécute du code au chargement, garde-fou de confiance activé ou non ; j’y reviendrai en détail prochainnement.
Ce référentiel classe précisément ce type d’incident sous Supply Chain, avec en prime une recommandation de signature cryptographique des artefacts (OpenSSF Model Signing, Sigstore) que je n’avais pas vue documentée aussi explicitement précédemment.
LLM06:2026 Unbounded Consumption
Anciennement bon dernier, l’escalade la plus large en nombre de places (+4). Le raisonnement est direct : agents et modèles à raisonnement étendu ont fait exploser le coût par requête, et le simple rate limiting par requête ne suit plus.
Le scénario qui illustre le mieux le problème : une session agentique ouverte, où chaque échange réinjecte tout le contexte accumulé. Coût par tour : environ 0,001 $ au premier échange, environ 0,50 $ au centième. Aucune requête individuelle ne déclenche de limite de débit, chacune reste dans son budget pris isolément. L’agrégat sur de nombreuses sessions concurrentes ou longues atteint des centaines de dollars, sans qu’aucun seuil unitaire n’ait jamais été franchi.
C’est un Denial of Wallet qui se cache dans l’addition, pas dans un pic.
Note du PandaRedacteur : combien de comités FinOps découvrent encore la facture le mois suivant, plutôt que le jour même ? Un plafond de dépense qui alerte n’est pas un plafond de dépense. Un plafond qui coupe, si.
Autre ajout notable : les circuit breakers agentiques comme catégorie de mitigation à part entière (limites de profondeur de récursion, de nombre d’étapes, de durée, avec hashing d’état pour détecter les boucles), aux côtés du rate limiting classique et des plafonds de dépense non contournables.
LLM07:2026 Misinformation
Anciennement LLM09:2025, +2 places, pour les raisons méthodologiques détaillées plus haut.
Le cadrage 2026 insiste sur un point que je trouve juste : dans les systèmes agentiques, une désinformation n’est plus juste une réponse fausse affichée à un humain, elle devient un état incorrect consommé par un composant en aval, qui déclenche une action non désirée.
Le document introduit le pattern claim-check-act : séparer la génération de l’exécution, et vérifier les affirmations avant d’agir, plutôt que de faire confiance à une sortie fluide parce qu’elle est fluide.
Un des exemples fournis mérite d’être cité tel quel : un agent de sécurité classe à tort du trafic normal comme intrusion et bloque automatiquement un segment réseau de production.
La désinformation ne trompe personne ici, elle déclenche directement une panne.
LLM08:2026 Hidden Context Exposure
Anciennement LLM07:2025 System Prompt Leakage. C’est la seule entrée explicitement marquée “renamed/re-scoped”, et je pense que c’est le changement le plus sous-estimé de toute cette édition, car il ressemble à un simple rebranding en surface.
L’ancien cadrage se concentrait sur la fuite du prompt système. Le nouveau élargit à tout contexte non destiné à l’utilisateur final mais accessible au modèle : prompt système, instructions développeur, politiques récupérées depuis une base RAG, schémas d’outils et de fonctions exposés à l’agent, toute règle ou directive assemblée dans la fenêtre de contexte.
Le principe de conception explicite change aussi de nature : concevez en partant du principe que ce contexte caché est découvrable, et qu’aucun de ses contenus ne doit être considéré comme un secret. Un système prompt qui contient des identifiants n’est pas une fuite en attente, c’est déjà une mauvaise architecture, peu importe que la fuite ait eu lieu ou non.
L’apport le plus concret : une grille de sévérité à quatre niveaux (informational, medium, high, critical) qui dépend de ce qui se trouve dans le contexte caché et de la manière dont l’application s’y fie, pas seulement du fait qu’il y ait fuite ou non.
Un contexte caché qui ne contient ni secret ni logique de sécurité reste informational même exposé. Un contexte caché dont la confidentialité conditionne l’autorisation ou le filtrage de contenu grimpe direct en high, et si l’exposition ouvre la voie à de l’exécution de code ou de l’exfiltration à grande échelle, en critical.
C’est un changement de logique : la gravité se juge sur la dépendance architecturale, pas sur l’exposition brute.
LLM09:2026 Vector and Embedding Weaknesses et LLM10:2026 Improper Output Handling
Vector and Embedding Weaknesses (LLM08:2025) recule d’un cran, changement mineur, le contenu reste stable dans son périmètre : géométrie de l’espace d’embedding, recherche par similarité, RAG comme cas le plus fréquent mais pas unique (mémoire d’agent vectorisée, caches sémantiques, pipelines de déduplication).
Improper Output Handling (LLM05:2025) subit la chute la plus sévère de tout le classement, cinq places d’un coup, de la cinquième à la dixième position. Rien dans le contenu ne suggère que le risque a diminué : XSS, CSRF, SSRF, exécution de code restent des conséquences bien réelles d’une sortie de modèle non validée avant transmission à un système en aval.
La chute traduit une chose précise : par rapport aux autres catégories qui ont grimpé (agents, coût, désinformation), les équipes de sécurité considèrent aujourd’hui ce risque comme relativement mieux couvert par les pratiques AppSec existantes.
Encodage de sortie contextuel, CSP stricte, requêtes paramétrées : ce sont des contrôles que l’industrie sait déjà déployer, contrairement à la gestion de l’agentique ou du coût, où les pratiques matures manquent encore.
Ce qui a été ajouté transversalement, sans créer de nouvelle catégorie
L’équipe du projet est explicite sur ce choix : plusieurs risques plus pointus ont grandi à l’intérieur des entrées existantes plutôt que de créer de nouvelles catégories qui auraient fragmenté la liste sans gain réel.
- L’injection cross-modal rejoint LLM01 : des instructions cachées dans une image ou une piste audio, pas seulement dans du texte. Le document documente une attaque nommée “fun-tuning”, où un attaquant lit la perte par exemple depuis l’API de fine-tuning d’un vendeur pour optimiser une charge utile, avec un taux de succès de 65 à 82% observé contre Gemini. Autrement dit : même un modèle à poids fermés expose une surface d’optimisation en boîte blanche via son API de fine-tuning.
- La subversion par fine-tuning rejoint LLM05 (Data and Model Poisoning), déjà détaillée plus haut.
- Le code généré à l’échelle rejoint LLM10 (Improper Output Handling) : la production de code non sécurisé par des assistants de développement, à un volume que la revue manuelle ne peut plus suivre.
Autre ajout qui mérite d’être signalé : l’exigence de tests contre des attaquants adaptatifs, formalisée pour la première fois comme recommandation de mitigation à part entière sur LLM01. Le document cite un résultat qui devrait inquiéter quiconque valide une défense sur un jeu de test statique : succès d’attaque statique proche de zéro, mais succès d’attaque adaptative dépassant 90% pour la plupart de 12 défenses récentes testées.
Une défense qui n’a jamais été confrontée à un attaquant qui connaît sa spécification exacte ne prouve rien.
Ce que le document exclut désormais explicitement
Aussi important que ce qui entre : ce que la liste ne couvre plus, ou n’a jamais couvert, et le dit maintenant noir sur blanc.
La frontière la plus structurante : ce Top 10 possède le risque tant que le modèle est un composant à l’intérieur de votre application. Dès qu’il devient un acteur, avec des outils qu’il peut appeler, une mémoire qui traverse les sessions, et des conséquences qu’il déclenche en aval, le risque appartient au Top 10 OWASP pour les Applications Agentiques (ASI), annoncé le 9 décembre 2025.
Ce que ça change concrètement pour vos threat models
Trois actions, pas dix, si vous devez repriorer maintenant :
- Remontez Excessive Agency dans vos revues de conception.
- Traitez tout contexte assemblé dans le prompt comme non secret par construction, pas seulement le prompt système.
- Ne validez plus une défense de prompt injection sur un jeu de test statique. Si votre dernier red team n’a pas testé contre un attaquant qui connaît votre défense exacte, vous avez un chiffre qui ne veut rien dire.
📚 Quelques références pour aller plus loin
- OWASP GenAI Security Project — OWASP Top 10 for LLM Applications 2026
- OWASP Top 10 pour les Applications LLM en 2025 — La Liste
- OWASP Top10 LLM01-2025 — L’Injection de Prompt
- OWASP Top 10 LLM10-2025 — Consommation Excessive
- OWASP Top 10 MCP — la série complète