Prompt injection en DeFi : la faille sans correctif confirmée par OWASP

Au début du mois de juin 2026, OWASP a reclassé le prompt injection dans la DeFi de menace plausible à fait avéré avec historique d'incidents — la semaine même où notre couverture le traitait encore comme un simple avertissement. L'organisation qui maintient le catalogue de référence en sécurité des applications a publié début juin 2026 son rapport State of Agentic AI Security and Governance 2026 (version 2.01), et le saut par rapport à l'édition précédente est majeur : là où 2025 listait des risques hypothétiques, 2026 liste des CVE (Common Vulnerabilities and Exposures : identifiants publics et standardisés de vulnérabilités concrètes), des avis de fabricants et des rapports de brèches réelles. La conclusion qui traverse le document est inconfortable : le prompt injection (injection d'instructions — texte malveillant caché dans les données qu'un modèle lit et exécute en le croyant être un ordre légitime) n'est pas un bug que l'on patche, mais un défaut de conception permanent. Un modèle de langage ne peut pas séparer les instructions de confiance des données non fiables car tout lui parvient mélangé dans le même stream de tokens (flux de tokens : la séquence unique de fragments de texte avec laquelle le modèle reçoit absolument tout). Cet article, en date du 8 juillet 2026, explique pourquoi cette limite est architecturale et non une maladresse d'implémentation, pourquoi la DeFi transforme cette limite en pertes irréversibles, et quels incidents de 2026 ont déjà fait passer la catégorie de « menace » à « facture ».

Qu'est-ce qui a changé en juin 2026 avec le rapport OWASP ?

L'OWASP (Open Worldwide Application Security Project) est l'organisation à but non lucratif dont le Top 10 des vulnérabilités est la référence utilisée par les équipes de sécurité du monde entier. Sa liste spécifique pour les modèles de langage place le prompt injection à la première place, LLM01, depuis deux ans. La nouveauté de l'édition 2026 n'est pas ce classement, mais la nature des preuves qui le soutiennent.

La version de 2025 cataloguait des menaces plausibles : des scénarios que les chercheurs considéraient comme possibles mais qui ne s'étaient pas encore matérialisés par des pertes documentées. La version 2.01, publiée début juin 2026, catalogue l'inverse — des vulnérabilités avec numéro CVE assigné, des avis de fabricants et des rapports de brèches réelles associés à presque toutes les catégories de risque agentique. C'est la différence entre une carte des zones de risque sismique et un registre des tremblements de terre déjà survenus.

Parmi les cas cités par le rapport et la couverture associée, trois CVEs illustrent la portée hors DeFi : EchoLeak (CVE-2025-32711), une vulnérabilité de type zero-click — sans que la victime n'ait à cliquer sur quoi que ce soit — dans Microsoft 365 Copilot avec une gravité de 9,3 sur 10 ; le CVE-2026-22708, un contournement de liste de commandes autorisées (allowlist bypass) dans l'éditeur Cursor ; et le CVE-2025-59532 contre l'outil de ligne de commande Codex d'OpenAI, où la propre sortie de l'agent parvenait à redéfinir les limites de son isolation. Aucun n'est lié à la DeFi, et c'est précisément le point : le défaut ne dépend pas du domaine, il voyage avec le modèle. La DeFi offre simplement le pire endroit possible pour qu'il se manifeste.

Pourquoi le prompt injection ne peut-il pas être patché ?

C'est ici que réside le cœur de l'argument, et il convient d'avancer prudemment car c'est ce qui distingue ce problème de n'importe quel autre défaut logiciel. Lorsqu'un modèle de langage traite une requête, il reçoit trois choses : les instructions de son créateur (le system prompt), l'entrée de l'utilisateur et les données externes qu'il consulte — une page web, un PDF, l'historique d'un contrat, la réponse d'un outil. Le détail décisif est que les trois arrivent sous la même forme : des tokens de langage naturel, sans étiquette indiquant lequel commande et lequel informe. Le modèle les pondère tous de la même manière. Il n'existe pas de frontière architecturale entre l'ordre privilégié et le contenu non fiable.

La comparaison avec une faille classique rend cela limpide. L'injection SQL — l'attaque qui, pendant deux décennies, a permis de voler des bases de données en glissant des commandes dans un formulaire — possède un remède complet et connu : les requêtes paramétrées, qui séparent le code des données au niveau du protocole. Le moteur sait, sans ambiguïté, quelle partie de la requête est une instruction exécutable et quelle partie est une donnée inerte. Le prompt injection n'a pas d'équivalent, car les instructions comme les données arrivent en langage naturel et aucune règle syntaxique ne peut tracer une ligne nette entre les deux.

Le fait qu'il ne s'agisse pas d'un pessimisme de blog est confirmé par ceux qui construisent les modèles. Le 13 février 2026, OpenAI a lancé un "mode confinement" (une configuration qui restreint ce que l'assistant peut faire avec des données non fiables) pour son navigateur avec IA et a reconnu publiquement que le prompt injection "pourrait ne jamais être totalement patché". Quand le fabricant du système admet que son attaque numéro un n'a pas de solution définitive, cela cesse d'être une opinion discutable pour devenir une prémisse de conception. Les routeurs LLM malveillants d'avril 2026 sont la démonstration pratique de cette même limite du stream de tokens ; le cas est disséqué dans le modèle de permissions des agents en DeFi.

Pourquoi l'isolation (sandboxing) ne comble-t-elle pas la faille ?

La réponse intuitive est "enfermons l'agent". Le sandboxing (isolation : exécuter l'agent dans un compartiment aux permissions restreintes pour qu'une faille ne se propage pas) est une défense réelle et nécessaire, mais elle ne résout pas le problème à la racine pour une raison que le rapport souligne lui-même. L'isolation limite ce que l'agent peut faire une fois qu'il est compromis ; elle n'empêche pas qu'il le soit. Et le CVE de l'outil Codex mentionné plus haut est didactique précisément parce que l'agent a réussi à redéfinir les limites de sa propre isolation à travers sa sortie : le confinement n'est pas un mur fixe quand celui qui l'habite peut en décrire la porte.

C'est pourquoi l'OWASP cadre la défense comme une architecture en couches, et non comme un patch : validation des entrées, permissions minimales, approbation humaine pour les actions sensibles, limites de dépenses, surveillance de la sortie. Chaque couche réduit la probabilité ou les dommages, aucune n'élimine la cause. C'est la différence entre un pare-feu qui corrige une vulnérabilité et une ceinture de sécurité qui n'évite pas l'accident, mais seulement ses conséquences. Lorsqu'un problème se gère avec des ceintures plutôt qu'avec des corrections, c'est parce que la cause ne peut être supprimée.

Pourquoi la DeFi amplifie-t-elle le rayon des dommages ?

Un prompt injection dans un assistant de messagerie peut faire fuiter une donnée embarrassante. La même faille dans un agent disposant d'une permission de signature sur un wallet déplace de l'argent de manière irréversible. La différence réside dans le blast radius (rayon de dommage : ce qu'un composant compromis peut détruire avant que quelqu'un ne l'arrête), et dans la DeFi, ce rayon explose en raison de trois propriétés que presque aucun autre logiciel ne possède.

• Pas de retour en arrière. Une signature sur la blockchain est finale. Un administrateur ne peut annuler la transaction ; l'erreur ne se corrige pas, elle se paie.
• La composabilité propage la permission. Une autorisation de dépense accordée à un smart contract peut se propager en cascade vers d'autres contrats que celui-ci invoque. La permission voyage plus loin que ce que l'utilisateur avait imaginé.
• Pas d'administrateur central. La DeFi est permissionless par conception : il n'existe pas de département pour mettre en quarantaine un agent rebelle ni d'interrupteur pour l'éteindre.

Ajoutez à cela que de plus en plus d'argent réel circule entre les mains des agents : le protocole de paiements agentiques x402 (standard ouvert de paiements via HTTP pour agents d'IA) a déjà dépassé les 100 millions de transactions sur le réseau Base, avec le gros du volume migrant des micropaiements vers des opérations supérieures à un dollar. Le résultat est une combinaison périlleuse : la vulnérabilité sans remède du modèle rencontre le système financier le moins indulgent qui soit. D'autres incidents — la brèche de Bankr, le drainage d'un wallet sur Base via des instructions cachées en code Morse — partagent cette racine et nous les avons déjà analysés comme des défauts d'architecture de permissions ; la nouveauté de juin est de comprendre que, sous les permissions, il existe une limite du modèle qu'aucune permission ne peut réparer.

Quels exploits réels sont passés de menace à facture ?

Le premier exploit DeFi de cette catégorie fut Resolv USR en mars 2026 (~25 millions de dollars), qui a déjà fait l'objet d'un article dédié. L'OWASP v2.01 marque le moment où ce type de cas a cessé d'être une anecdote isolée pour devenir un schéma avec un nom et un catalogue.

Le bilan de 2026 donne la mesure du phénomène. Selon l'inventaire des incidents d'agents d'IA en crypto compilé par KuCoin, les faiblesses au niveau du protocole dans les agents de trading autonomes ont provoqué plus de 45 millions de dollars d'incidents de sécurité au cours de l'année, avec des attaques ciblant le "cerveau" de l'agent — sa mémoire à long terme et les protocoles qui le connectent aux outils de trading —. Ce chiffre ne provient pas d'un seul vol spectaculaire, mais de l'accumulation de défauts d'authentification, d'isolation et d'intégrité de la mémoire.

Une donnée de prévalence explique pourquoi il ne s'agit pas d'une simple mauvaise passe : selon le rapport State of AI Security 2026 de Cisco (février 2026), le prompt injection apparaît dans environ 73 % des déploiements d'IA en production audités — non pas comme un incident rare, mais comme le défaut de fond le plus commun de l'écosystème agentique.

Est-ce un défaut sans patch, comme le code mort d'Aztec Connect ?

L'intuition correcte est de traiter le prompt injection comme une classe de risque que nous connaissions déjà en crypto : le défaut qui ne se corrige pas car sa cause est une décision de conception, et non un oubli. Le parallèle le plus net est l'exploit d'Aztec Connect via du code mort : un contrat désactivé restait déployé et exploitable, et la vulnérabilité ne résidait pas dans un bug ponctuel mais dans la décision de le laisser là. Dans les deux cas, chercher "le patch" est la mauvaise question — il n'y a pas de point où l'appliquer, car la faille est structurelle.

La différence est une question de degré. Le code mort peut être retiré ; la décision de conception d'Aztec était réversible, même si personne ne l'a inversée à temps. Le prompt injection n'admet même pas cette issue : tant qu'un modèle traitera des instructions et des données dans le même langage, la frontière ne pourra être tracée. Il n'y a pas de contrat à retirer, il y a une propriété du paradigme. C'est pourquoi le cadre mental imposé par l'OWASP v2.01 n'est pas "il faut réparer cela avant d'utiliser des agents", mais "cela ne se répare pas, alors décidez quel pouvoir vous donnez à quelque chose que vous savez pouvoir être détourné".

Les protocoles DeFi doivent-ils intégrer des agents d'IA maintenant ?

La réponse honnête n'est ni un oui ni un non, mais un changement dans l'unité de décision. Un protocole qui intègre un agent d'IA sans isolation n'assume pas un risque logiciel — du type que l'on audite, patche et ferme — mais un risque de conception sans atténuation connue au niveau du modèle. Cela ne le rend pas inviable, de la même manière que le fait d'accepter que les signatures soient irréversibles n'a pas rendu la DeFi inviable. Ce que cela exige, c'est de cesser de traiter la sécurité de l'agent comme un problème soluble et de commencer à la traiter comme un budget de dommages que l'on délimite par couches : permissions minimales, limites de dépenses, approbation humaine pour les actions sensibles, et la prémisse permanente que l'entrée de l'agent peut être empoisonnée.

La leçon de juin 2026 est une question de cadrage, pas de tactique. Pendant des mois, le débat portait sur la sécurité des agents d'IA dans la DeFi ; le rapport OWASP le reformule en demandant s'ils sont gouvernables sachant que leur attaque principale n'a pas de remède. Quiconque intègre un agent avec l'espoir qu'un "patch sortira bientôt" construit sur une prémisse que le fabricant du modèle lui-même a démentie. Et dans un système où une signature ne s'annule pas, la distance entre cette fausse attente et un wallet vide est exactement un prompt bien placé. Avant de déléguer toute opération, il convient de vérifier ce que votre wallet expose et à combien de permissions actives vous restez lié.

Sources et liens : Help Net Security — OWASP : le prompt injection continue de dominer les failles d'IA agentique en production (11-juin-2026) · OWASP GenAI — LLM01 : Prompt Injection · KuCoin — Agents de trading avec IA : 45 millions de dollars d'incidents en 2026 · TechTimes — Prompt injection : un défaut permanent, pas un bug patchable (14-juin-2026) · Cisco — State of AI Security 2026 : prompt injection dans 73 % des déploiements