OWASP LLM Top 10 (2026) : ce qui change et comment tester

Qu'est-ce que l'OWASP LLM Top 10 ?

L'OWASP LLM Top 10 est un document de référence construit par la communauté qui classe les dix risques de sécurité les plus critiques des applications reposant sur de grands modèles de langage. Il est maintenu par le projet OWASP GenAI Security, et l'édition 2026 est la troisième depuis la première parution de la liste en 2023.

Il existe parce que les applications LLM échouent d'une manière que la liste web n'avait pas anticipée. L'injection SQL a un correctif : paramétrez la requête et l'entrée de l'attaquant ne peut plus devenir une instruction. Un LLM n'a pas d'équivalent. Le prompt système, votre question, un document récupéré, la réponse d'un outil et l'historique de conversation de la semaine dernière arrivent tous comme des tokens sur le même flux, sans rien pour marquer lesquels ont le droit de donner des ordres.

Ce seul fait de conception explique la majeure partie de la liste. Une fois qu'on l'accepte, les dix entrées cessent de ressembler à un fourre-tout et deviennent une seule défaillance qui se propage vers l'extérieur : dans ce que le modèle dit, ce qu'il mémorise, ce qu'il récupère et ce qu'il a le droit de faire.

Ce qui change dans l'édition 2026

Quoi de neuf dans l'OWASP LLM Top 10 2026 ? Huit des dix entrées ont changé de place, une a été renommée et la méthode de classement a évolué. Pour la première fois, l'OWASP a combiné le vote de la communauté avec des preuves tirées d'incidents d'IA répertoriés, en pondérant le vote à 75 pour cent et les données d'incidents à 25 pour cent. Parmi les incidents examinés, 6 639 étaient assez documentés pour être classés.

Ce changement de méthode explique l'essentiel des mouvements, et il a produit une anomalie vraiment intéressante. Prompt Injection reste numéro un malgré un historique d'incidents mince, parce que les organisations qui la bloquent avec succès ne génèrent pas d'incident. Misinformation a fait l'inverse : à peine visible chez les votants, dominante dans les données d'incidents, elle gagne deux places sur des preuves plutôt que sur une opinion.

Les responsables du projet ont résumé leur propre conclusion sans détour dans la couverture de la sortie : "Arrêtez d'essayer de construire un modèle qui ne peut pas être trompé. Construisez le système autour de lui, pour que le jour où le modèle sera trompé, et il le sera, rien d'important ne casse." Cette phrase résume à elle seule l'écart entre les listes 2025 et 2026, et elle explique pourquoi les entrées liées à l'autonomie et au rayon d'impact montent pendant que celle sur l'assainissement descend.

Les 10 risques, expliqués

Chaque entrée ci-dessous utilise l'identifiant officiel de style LLM01:2026 que vous verrez cité dans les rapports de pentest et les conclusions de red team IA. L'édition 2026 associe aussi chaque risque à NIST, CWE, à l'OWASP Top 10 for Agentic Applications et à MITRE ATLAS, ce qui est utile quand votre rapport doit parler le référentiel du client.

LLM01:2026 - Prompt Injection

Une entrée modifie le comportement du modèle d'une façon que le développeur n'avait pas prévue. Cette entrée n'a pas besoin d'être tapée par un utilisateur, ni d'être lisible par un humain, ni d'être visible dans la page affichée. Une page de wiki empoisonnée, un titre de ticket, la réponse d'un outil, une image ou une ligne écrite en mémoire longue durée atteignent le même flux de tokens. L'Unicode invisible est l'astuce à connaître : les caractères de bloc tag (U+E0000 à U+E007F), les sélecteurs de variation et les caractères de largeur nulle font passer des instructions sous le nez d'un relecteur humain.

L'injection indirecte est le cas le plus vicieux. L'attaquant ne touche jamais votre backend. Il laisse du texte là où votre assistant ira le lire, et votre assistant, qui tourne avec vos identifiants, fait le travail à sa place.

LLM02:2026 - Sensitive Information Disclosure

Le modèle expose des données qu'il ne devrait pas, et le texte de la réponse n'est qu'un canal parmi d'autres. Les arguments d'appels d'outils, les traces de raisonnement, les fragments récupérés, les journaux, les embeddings et même les schémas observables de latence ou de longueur de tokens fuient. L'OWASP cite l'attaque par divergence de novembre 2023, où des prompts à tokens répétés ont poussé gpt-3.5-turbo à produire plus de 10 000 exemples d'entraînement mémorisés uniques pour environ 200 dollars d'appels d'API.

La plupart des fuites réelles sont plus ternes. Un pipeline de récupération branché sur un disque partagé trop largement renvoie exactement ce pour quoi il a été construit, et le document sensible n'aurait jamais dû se trouver dans l'index.

LLM03:2026 - Excessive Agency

La promotion la plus marquante de la liste 2026. Un LLM doté d'outils peut agir, et Excessive Agency est ce qui transforme une sortie manipulée en conséquence réelle. L'OWASP découpe la cause racine en trois : fonctionnalités excessives (un outil de lecture de documents qui peut aussi supprimer), permissions excessives (une fonction en lecture seule qui se connecte avec un compte disposant d'UPDATE et DELETE) et autonomie excessive (aucune validation humaine sur une action irréversible).

Elle monte à la troisième place parce que les déploiements agentiques ont rendu la théorie concrète. La liste 2025 traitait l'autonomie comme un sujet secondaire. La liste 2026 en fait le contrôle qui décide si une injection est une gêne ou un incident.

LLM04:2026 - Supply Chain

Modèles tiers, jeux de données, adaptateurs LoRA, pipelines de conversion et frameworks de service forment tous une surface d'attaque. Les fichiers de modèles sérialisés avec pickle exécutent du code arbitraire au chargement, ce qui reste le moyen le plus fiable d'obtenir un shell depuis un artefact de modèle, et l'OWASP précise que passer à des formats plus sûrs réduit le risque sans l'éliminer : une porte dérobée peut aussi vivre dans un graphe de calcul ONNX.

La variante la plus récente porte le meilleur nom de la liste. Les assistants de code hallucinent des noms de paquets plausibles à grande échelle, des attaquants enregistrent ces noms à l'avance, et la dépendance suggérée par l'IA pointe vers du code malveillant. L'OWASP appelle cela le slopsquatting.

LLM05:2026 - Data and Model Poisoning

Un adversaire corrompt des données ou des artefacts de modèle pour que le comportement nuisible soit intégré plutôt qu'injecté à l'exécution. Cela peut arriver au pré-entraînement, au fine-tuning, à la création d'embeddings, à la génération augmentée par récupération, ou partout où un pipeline d'apprentissage continu ingère du contenu sans validation. Une porte dérobée peut rester dormante jusqu'à l'apparition d'une phrase déclencheuse, ce qui rend les tests comportementaux seuls peu rassurants.

La raison pour laquelle cela fait plus mal qu'un bug ordinaire : on ne peut pas le patcher. Remédier veut dire revalider les données, réentraîner ou remplacer le modèle.

LLM06:2026 - Unbounded Consumption

En hausse de quatre places, et recadrée autour de l'asymétrie des coûts plutôt que du simple déni de service. Un attaquant dépense presque rien pour déclencher un calcul qui coûte très cher au fournisseur. Les modèles de raisonnement aux budgets de sortie généreux, les entrées multimodales et les boucles d'agents qui transforment une requête en dizaines d'appels aval creusent l'écart. Le Denial of Wallet est désormais une conclusion légitime dans une évaluation LLM, et la limitation du débit de requêtes ne suffit pas, puisqu'une requête n'égale pas une unité de coût.

LLM07:2026 - Misinformation

Le modèle produit une sortie fausse mais assez crédible pour qu'on agisse dessus. C'est l'entrée que les données d'incidents ont poussée le plus fort. Elle a cessé d'être un problème de confiance utilisateur quand les sorties de modèles ont commencé à déclencher des appels d'outils, à déduire l'état d'un workflow et à alimenter d'autres agents. Une réponse fausse et assurée qu'un humain vérifie est une nuisance. La même réponse consommée par un workflow automatisé est une faute sans relecteur sur le chemin.

LLM08:2026 - Hidden Context Exposure

Renommée depuis System Prompt Leakage, et élargie. L'entrée couvre maintenant tout ce qui est assemblé dans le contexte du modèle sans être destiné aux utilisateurs : instructions système, textes de politique récupérés, schémas d'outils et règles de workflow. La consigne de l'OWASP est ici agréablement directe. Partez du principe que le contexte caché est découvrable, et concevez pour que sa divulgation ait peu d'impact sur la sécurité.

Extraire un prompt système fait une belle démonstration. La vraie trouvaille, c'est ce que ce prompt révèle : des identifiants, une logique de filtrage, ou les noms d'outils et formes d'arguments qui rendront l'attaque suivante précise.

LLM09:2026 - Vector and Embedding Weaknesses

Dès qu'une recherche par similarité se glisse entre une source de données et le prompt, la couche d'embeddings rejoint la frontière de confiance. Cela couvre le RAG, la mémoire d'agent adossée à des vecteurs, les caches sémantiques et la déduplication. Ces attaques exploitent la géométrie de l'espace vectoriel plutôt que l'obéissance du modèle aux instructions, si bien que beaucoup fonctionnent même quand le contenu récupéré ne contient rien de malveillant.

La fuite inter-locataires est le cas à tester en premier : la recherche par similarité parcourt souvent tout l'index avant que l'application n'applique le contrôle d'accès, et les nombres de résultats, distributions de scores et temps de réponse révèlent les documents d'autres locataires sans jamais les renvoyer. L'OWASP souligne aussi que des failles d'authentification classiques aggravent le problème, en citant CVE-2025-64513 dans Milvus et CVE-2025-69286 dans RAGFlow, toutes deux notées CVSS 9.3.

LLM10:2026 - Improper Output Handling

Une sortie de modèle qui atteint un composant aval sans validation. C'est le pipeline classique : du Markdown généré et rendu en HTML vous donne du cross-site scripting, du SQL généré et concaténé dans une requête donne une injection, des arguments de shell générés donnent une exécution de commandes. L'édition 2026 ajoute les terminaux et panneaux d'IDE qui interprètent les séquences d'échappement ANSI, et les clients qui téléchargent automatiquement les images Markdown, ce qui transforme une réponse affichée en canal d'exfiltration sortant.

Elle chute de cinq places, ce qui est facile à mal lire. Le risque n'a pas diminué. L'OWASP l'a déplacée parce qu'elle est bien comprise et directement corrigeable avec les pratiques d'encodage et de validation que les développeurs web connaissent déjà, contrairement aux entrées placées au-dessus.

Comment tester une application LLM face au Top 10

Comment tester une application LLM sur ces risques ? Cartographiez d'abord les frontières de confiance, puis attaquez par ordre de rayon d'impact : ce que le modèle peut atteindre, ce qu'il récupère et ce que sa sortie touche. Les jailbreaks dans la fenêtre de chat font les plus belles captures d'écran et les trouvailles les moins utiles, gardez-les pour la fin.

1. Inventoriez le contexte. Listez tout ce qui atterrit dans la fenêtre de contexte : prompt système, entrée utilisateur, documents récupérés, réponses d'outils, mémoire et historique de conversation. Tout élément de cette liste qu'un tiers peut alimenter est une surface d'injection.
2. Énumérez les outils. Récupérez les schémas d'outils, puis vérifiez l'identité derrière chacun. Une fonction en lecture seule connectée avec des droits d'écriture est déjà une conclusion LLM03, avant même d'avoir envoyé une charge utile.
3. Testez l'injection indirecte en premier. Placez des instructions dans un document, une page, un titre de ticket ou une réponse d'API que le système va ingérer, puis observez si elles influencent une session ultérieure. La persistance entre sessions via la mémoire ou un corpus RAG est la trouvaille à faire remonter.
4. Suivez la sortie. Tracez chaque destination atteinte par la réponse : navigateur, terminal, visionneuse de journaux, panneau d'IDE, gabarit d'e-mail, requête de base de données. Testez chacune avec l'encodage qu'elle interprète, y compris les séquences ANSI et les balises d'images Markdown.
5. Sondez les frontières de récupération. Dans un déploiement multi-locataires, interrogez du contenu que vous ne devriez pas voir et mesurez le nombre de résultats, les scores et la latence. Une déduction est une conclusion même si aucun document ne revient.
6. Bornez le coût. Mesurez le calcul aval qu'une seule requête peut déclencher. Les boucles de raisonnement et l'éclatement en agents sont là où vit le Denial of Wallet.

Sur des déploiements réels, le schéma le plus fréquent n'est pas un jailbreak exotique. C'est un outil câblé à un compte de service qui a bien plus d'accès que la fonction n'en a besoin, derrière un modèle qu'on finira par convaincre de l'appeler. La charge utile est la partie facile.

La trifecta létale, et pourquoi le filtrage perd

Les recommandations de prévention de l'OWASP sur l'injection de prompt s'ouvrent sur un aveu que la plupart des éditeurs ne feront pas : aucun mécanisme de prévention fiable n'existe aujourd'hui. Les filtres d'entrée se dégradent face à des attaquants adaptatifs, et un second modèle chargé de surveiller le premier n'est qu'un modèle de plus qu'on peut contourner.

Ce qui résiste au contact d'un attaquant, c'est l'architecture. L'édition 2026 cite la "lethal trifecta" de Simon Willison comme contrôle avant mise en production, et c'est l'idée la plus utile de toute la publication pour un testeur en activité. Un agent est en danger quand il peut faire ces trois choses en même temps :

• Accéder à des données privées via des fichiers, des bases de données ou une API authentifiée.
• Ingérer du contenu non fiable depuis des pages web, des e-mails, des documents ou des sorties d'outils.
• Communiquer vers l'extérieur en envoyant des requêtes, en écrivant des fichiers ou en affichant des ressources téléchargées.

Retirez l'un des trois piliers et le chemin d'exploitation à fort impact se referme. C'est une question de revue de conception, pas de charge utile, et elle a sa place en tête de toute mission agentique. Si un client affirme que son modèle garde-fou gère l'injection, demandez lequel des trois piliers il a retiré. Le silence est en général la conclusion.

Où cela se place si vous apprenez la sécurité offensive

Nul besoin de compétences en recherche sur l'apprentissage automatique pour tester ces systèmes. Sept des dix risques sont des problèmes web reconnaissables déguisés. Improper Output Handling, c'est de l'injection avec un saut de plus. Excessive Agency, c'est de l'élévation de privilèges. Vector and Embedding Weaknesses, c'est un défaut d'autorisation multi-locataires. Supply Chain, c'est de la confusion de dépendances plus de la désérialisation non sécurisée.

Le conseil de carrière honnête : apprenez d'abord correctement la sécurité des applications web, puis ajoutez les parties propres aux modèles. Un testeur qui comprend les frontières de confiance et sait lire un contrat d'API trouvera plus de choses dans une évaluation LLM que quelqu'un qui ne connaît que des prompts de jailbreak. Notre guide OWASP API Security Top 10 couvre le raisonnement sur l'autorisation qui se transpose directement, et la mécanique propre à l'IA se construit par-dessus.

Dernière vérification : août 2026. L'édition 2026 a été publiée le 4 août 2026. Classements et intitulés confirmés avec la publication officielle du projet OWASP GenAI Security et son dépôt source canonique.

Considérations légales et éthiques

• Ne testez que des systèmes qui vous appartiennent, des labs d'entraînement dédiés ou des cibles couvertes par une mission signée ou par le périmètre publié d'un programme de bug bounty.
• Lisez le périmètre avant de commencer. Beaucoup de programmes excluent encore le comportement du modèle, ou n'acceptent l'injection de prompt que si vous démontrez un impact sur un système connecté.
• Les tests d'extraction de données peuvent faire remonter de vraies données personnelles. Arrêtez-vous à la preuve d'impact, et ne conservez ni ne partagez jamais ce qui revient.
• Les tests de Denial of Wallet coûtent de l'argent réel à la cible. Fixez des limites par écrit au préalable.
• Ne placez des charges utiles d'injection que dans du contenu que vous contrôlez. Empoisonner un wiki partagé ou un dépôt public pour voir ce qui se passe touche des gens qui n'ont jamais accepté votre test.