Oracle DeFi : quand la signature elle-même est forgée

Le 3 novembre 2026, un contrat baptisé InsurancePool a été vidé en une seule transaction sur BNB Chain. L’attaquant a emprunté près de 207 000 WBNB en flash loan, les a déversés dans une paire PancakeSwap pour tordre le prix au comptant, puis a demandé le rachat d’une position CoreVault dont la valeur était calculée sur ce même prix instantané. Le montant de remboursement a été gonflé d’environ 33 fois, et la caisse d’assurance a perdu quelque 160 BNB, soit près de 112 000 dollars (environ 100 000 euros), selon Crypto Briefing.

Cette attaque est un classique du genre. On l’a vue des dizaines de fois en 2026, de Tectonic à Nostra. Elle appartient à une famille que l’industrie comprend bien : pousser un marché peu liquide, tromper un oracle honnête, puis emprunter contre un collatéral artificiellement valorisé. Mais pendant que cette vieille école continue de faire des victimes, une autre famille d’attaques s’est installée en silence, et elle est beaucoup plus difficile à arrêter. Dans cette seconde famille, l’attaquant ne touche jamais au marché. Il forge directement la signature du prix.

Trois incidents de 2026 racontent cette bascule : Ostium sur Arbitrum, Bonzo sur Hedera et Switchboard sur quatre chaînes Move. Dans les trois cas, l’oracle a rapporté un chiffre qu’aucun marché n’a jamais produit, et la blockchain l’a accepté parce que, du point de vue du code, la signature était valide. Cet article est un démontage technique de cette couche précise, celle de la signature, et de ce qu’il faut pour la défendre.

Deux familles d’attaques que l’on confond trop souvent

Le terme « manipulation d’oracle » recouvre deux choses très différentes, et les confondre revient à déployer les mauvaises défenses. La première famille vise l’entrée de l’oracle. L’oracle reste honnête : il rapporte fidèlement un prix réel, sauf que l’attaquant vient de créer ce prix de toutes pièces, le temps d’une transaction, en vidant un pool peu liquide ou en gonflant un ratio interne par une attaque de donation. Le chiffre est « vrai » à cet instant précis, sur le marché que l’oracle observe. Le défaut n’est pas dans l’oracle, il est dans le protocole qui a cru qu’un prix instantané valait collatéral.

Marcin Kazmierczak, cofondateur de RedStone, a résumé cette première famille à propos du vol de 75 millions de dollars subi par Tectonic en août : « rapporter un prix et valider qu’un prix est sûr pour prêter sont deux métiers différents ». L’oracle a bien fait son travail de messager. C’est le protocole qui a accordé une confiance aveugle au message. On retrouve dans ce camp bZx en 2020, Mango Markets en 2022, UwU Lend en 2024, Tectonic et Moonwell en août 2026, Nostra en septembre, et CoreVault cette semaine. C’est la famille que la DeFi sait, en théorie, neutraliser : moyenne pondérée dans le temps (TWAP), médiane de plusieurs sources, plafonds d’écart, disjoncteurs. Les protocoles qui lient leurs plafonds d’emprunt à la liquidité réellement disponible, comme le rappelle la logique des mécaniques de liquidation douce explorées par Curve, rendent cette première attaque beaucoup moins rentable.

La seconde famille ne s’embête pas avec le marché. Elle vise l’authentification du prix. L’oracle y rapporte un nombre qu’aucun marché n’a produit, parce que l’attaquant a cassé le mécanisme par lequel la chaîne décide qu’un prix est authentique. Le TWAP ne sert à rien : il n’y a pas de pic de marché à lisser. La médiane ne sert à rien : le flux forgé est la source. Le plafond d’écart ne sert à rien si l’oracle affiche directement la cible. C’est pour cela que cette famille, plus rare mais plus brutale, mérite son propre démontage. Et pour la comprendre, il faut d’abord regarder ce que la blockchain voit réellement quand on lui donne un prix.

Ce que la blockchain voit vraiment : un message, pas un marché

Un contrat intelligent ne regarde pas Binance. Il ne consulte pas de carnet d’ordres, ne voit pas de bougies, n’a aucune notion de ce qu’est un marché. Tout ce qu’il reçoit, c’est un message : un nombre, un horodatage, un identifiant de paire, et une signature cryptographique censée prouver que ce message vient bien de l’oracle autorisé. Le contrat vérifie la signature. Si elle est valide, le nombre devient loi. S’il dit 10 millions de dollars pour un jeton qui en vaut un, et que la signature passe, alors ce jeton vaut 10 millions de dollars pour tout ce que le protocole fera ensuite.

Toute la sécurité d’un oracle repose donc sur une question : qui a le droit de signer, et comment la chaîne vérifie-t-elle cette signature ? Les grands fournisseurs répondent de manières différentes, mais le principe est identique. Chainlink fait observer un prix à un réseau décentralisé de nœuds (le DON), qui s’accordent sur une médiane hors chaîne via le protocole Off-Chain Reporting, puis écrivent un seul rapport signé sur la chaîne ; ce rapport doit porter au moins f+1 signatures valides, vérifiées par multisignature ECDSA, comme le détaille le livre blanc OCR. Pyth fonctionne en mode « pull » : les prix agrégés sur Pythnet sont signés par un réseau de dix-neuf gardiens Wormhole qui produisent une attestation (un VAA), que l’utilisateur récupère puis soumet lui-même ; le contrat vérifie les signatures Wormhole et une preuve de Merkle, selon la documentation de Pyth. Supra et Switchboard suivent des schémas voisins, l’un bâti sur des signatures BLS à seuil, l’autre sur l’attestation de clés de signature d’opérateurs.

Ce tableau est le cœur du problème. Chaque ligne décrit une chaîne de confiance qui s’arrête à une poignée de clés privées et à une poignée de lignes de code de vérification. L’oracle est, en pratique, une contrepartie que le protocole n’a jamais contractualisée : un intermédiaire invisible dont la défaillance se transmet instantanément à tout ce qui dépend de lui, un peu comme le risque de contrepartie que le carry des futures finit toujours par facturer. Casser la signature, c’est casser ce lien. Et il y a exactement trois façons de le faire : voler la clé, tromper le vérificateur, ou se faire inscrire soi-même comme signataire. Les trois ont été démontrées en 2026.

Ostium : la clé volée qui signe des prix futurs

Le 15 juillet 2026, Ostium, une plateforme de perpétuels sur actifs réels (RWA) déployée sur Arbitrum, a perdu entre 18 et 23,75 millions de dollars (soit grossièrement 16 à 21 millions d’euros). La cause racine n’a rien d’une manipulation de marché : un attaquant avait mis la main sur la clé privée d’un signataire de l’oracle. Avec cette clé, il pouvait produire des rapports de prix parfaitement signés, donc parfaitement valides aux yeux du contrat, sans jamais acheter ni vendre quoi que ce soit.

Le détail qui fait froid dans le dos, rapporté par crypto.news à partir de l’alerte de la firme de sécurité Blockaid, est que l’attaquant a pu soumettre des prix futurs favorables et enchaîner une vingtaine de trades en boucle via des actions déléguées, encaissant un profit à chaque tour sans la moindre exposition réelle au marché. Les analyses on-chain évaluent la ponction à environ 28 % des 63 millions de dollars de valeur verrouillée dans le coffre au moment de l’attaque. Ostium a suspendu les échanges, puis les a rouverts le 23 juillet, selon Protos.

Ostium est le cas d’école de la première méthode : la clé reste la bonne, le vérificateur fait son travail, mais la personne qui tient la clé n’est plus la bonne. Aucune médiane, aucun TWAP, aucun disjoncteur ne détecte cela, parce que du point de vue cryptographique rien n’est anormal : les signatures sont authentiques. C’est précisément le scénario que Ronghui Gu, cofondateur de CertiK, décrit quand il avertit, dans Forbes, qu’« un protocole peut passer un audit de code irréprochable et perdre quand même des millions à cause d’une clé d’administration compromise ». La façon dont ces clés fuitent, souvent via des campagnes d’ingénierie sociale de plus en plus industrialisées, est le même terrain que celui du phishing où le bot est devenu l’appât.

Bonzo et Supra : la signature qui n’était que des zéros

Le 11 juillet 2026 à 00h51 UTC, soit quatre jours avant Ostium, Bonzo Lend, le plus gros marché de prêt du réseau Hedera, a perdu 9,05 millions de dollars (environ 8 millions d’euros). Ici, l’attaquant n’avait volé aucune clé. Il n’en avait pas besoin, parce que le vérificateur de l’oracle acceptait une signature qui n’en était pas une.

Le mécanisme, décortiqué par QuillAudits et The Block, est une leçon de cryptographie appliquée. L’attaquant a soumis à l’oracle Supra une mise à jour de prix pour la paire SAUCE/wHBAR (paire 425) avec trois caractéristiques choisies : un identifiant de comité (committee ID 2) situé hors de la plage réellement peuplée, un champ de signature BLS fixé à [0,0], c’est-à-dire l’élément neutre, et une clé publique correspondante elle aussi nulle. Trois défauts se sont alors enchaînés. D’abord, l’identifiant de comité hors plage a conduit le vérificateur à renvoyer une clé publique nulle au lieu de rejeter la référence. Ensuite, la fonction de vérification n’a jamais contrôlé que la signature et la clé étaient non nulles et correctement situées sur la courbe avant de les transmettre au précompilé de couplage. Enfin, les mathématiques du couplage BLS ont fait le reste : une signature neutre couplée à une clé neutre donne une équation qui se vérifie automatiquement, les deux côtés valant l’élément neutre. Le précompilé de couplage de Hedera (le contrat système 0.0.8) a renvoyé « vrai », mathématiquement correct, mais ne prouvant strictement rien sur une quelconque autorisation.

En clair : l’attaquant a présenté un cachet vide, et le vérificateur a conclu que le cachet correspondait, parce qu’un vide comparé à un vide donne toujours une égalité. Avec ce prix forgé, il a déposé 250 SAUCE (environ 3 dollars), vu la valeur de ce dépôt grimper d’environ douze ordres de grandeur, puis emprunté 6 634 528 USDC et 34 518 389 wHBAR. La valeur verrouillée de Bonzo a chuté de 77 %, et celle de l’ensemble du réseau Hedera d’environ 40 % en vingt-quatre heures. Selon l’analyse publiée par rekt.news, le vérificateur fautif était en production, non corrigé et visible de tous sur la chaîne depuis deux ans.

Supra a déployé un correctif en quelques heures. Son post-mortem décrit trois contrôles là où il n’y en avait aucun : validation de plage sur la recherche du comité, rejet des clés et signatures égales à l’élément neutre, et vérification de l’appartenance à la courbe avant tout couplage. La firme reconnaît que « le seul contrôle de l’élément neutre aurait suffi à empêcher cette attaque ». Hedera a confirmé publiquement que Supra avait reconnu la faille de vérification et déployé un correctif sur le mainnet. Un seul test de nullité, une ligne, séparait Bonzo de ses 9 millions.

Switchboard : quand l’attaquant devient un signataire légitime

La troisième méthode est peut-être la plus élégante, et la plus inquiétante. Le 29 août 2026, Switchboard a dû suspendre ses flux de prix sur quatre blockchains de la famille Move (Sui, Aptos, IOTA et Movement) après la compromission de clés de signature. L’attaquant n’a pas volé une clé existante et n’a pas trompé un vérificateur bogué : il a ajouté à un flux Switchboard actif une clé de signature qu’il contrôlait, puis a simplement déclaré un faux prix. Devenu signataire autorisé, il écrivait des données de prix arbitraires directement dans l’oracle, sans se soucier du marché.

Sur la file IOTA de Switchboard, l’attaquant a fini par contrôler les quatorze clés de signature, selon Crypto Briefing. Les dégâts confirmés dépassent 546 000 dollars (environ 490 000 euros) et, surtout, ils se sont propagés. Full Sail, un protocole sur Sui, a été vidé d’environ 91 000 dollars sur trois coffres après une manipulation du prix à près de cent fois sous sa valeur de marché, et a annoncé sa fermeture. Sur IOTA, le prix du jeton a été poussé à 10 millions de dollars, ce qui a permis à l’attaquant de déposer 1 IOTA et d’émettre près de 4,94 millions de VUSD, le stablecoin du protocole Virtue. Des coffres gelés et des liquidations forcées ont suivi en cascade sur plusieurs réseaux, comme l’a documenté CryptoSlate.

Switchboard illustre un point que beaucoup d’utilisateurs ignorent : l’ensemble des signataires d’un oracle n’est pas gravé dans le marbre. C’est une liste, gérée par du code et par des clés d’administration, et qui dit liste modifiable dit cible. Si un attaquant peut y inscrire sa propre clé, il n’a plus besoin de forger quoi que ce soit : il signe en toute légitimité. Le système fonctionne exactement comme prévu, pour la mauvaise personne.

Trois façons de casser une signature

Mis côte à côte, les trois incidents dessinent une taxonomie propre de la famille « forgerie ». Tous contournent l’authentification du prix, mais chacun attaque un maillon différent de la chaîne de confiance décrite plus haut. Le premier vole le droit de signer, le deuxième casse le juge qui contrôle les signatures, le troisième s’octroie le droit de signer. Aucun ne requiert de capital de marché significatif : Bonzo a démarré avec 3 dollars de collatéral.

La lecture par maillon est utile parce qu’elle oriente la défense. Contre le vol de clé, la réponse relève de la gestion des secrets : modules de sécurité matériels, rotation régulière, signatures à seuil pour qu’une clé isolée ne suffise pas. Contre le vérificateur bogué, la réponse est l’audit formel de la logique de vérification cryptographique, le point aveugle de Bonzo. Contre l’inscription d’une clé pirate, la réponse est la surveillance de l’ensemble des signataires et un délai (timelock) sur toute modification de cette liste. Un même mot, « manipulation d’oracle », recouvre donc trois chantiers de sécurité sans rapport entre eux.

Pourquoi les défenses classiques ne servent à rien

La boîte à outils que la DeFi a passé cinq ans à affûter est entièrement calibrée pour la première famille, celle de la manipulation économique. Elle part d’un postulat : le prix signé est authentique, le seul risque est qu’il soit temporairement faux à cause d’un marché tordu. Toutes les parades découlent de ce postulat, et toutes s’effondrent dès que le postulat tombe.

Ce tableau explique pourquoi les attaques de 2026 ont frappé des protocoles qui pensaient avoir fait leurs devoirs. Un TWAP ne lisse pas une signature forgée : il moyenne une suite de faux prix et produit un faux prix lissé. Une médiane de trois sources ne protège pas si l’attaquant est devenu l’une des sources, ou si le vérificateur accepte n’importe quoi. Pire, un disjoncteur réglé pour bloquer un mouvement de plus de x pour cent peut être contourné par un attaquant patient qui injecte un prix juste sous le seuil, encaisse, recommence. Les défenses de la première famille ne sont pas mauvaises ; elles sont simplement hors sujet. Contre la forgerie, la seule ligne qui compte est la couche message elle-même : la clé, le vérificateur, la liste des signataires.

Le flash loan n’est pas le coupable

Les gros titres aiment accoler « flash loan » à « manipulation d’oracle », comme si l’emprunt sans collatéral était la faille. C’est une confusion utile à lever. Le flash loan est un amplificateur, pas une cause, et il n’appartient qu’à la première famille. CoreVault en est l’exemple parfait : les 207 000 WBNB empruntés servaient uniquement à tordre un marché assez peu profond pour bouger. Si le prix de rachat avait reposé sur une médiane robuste plutôt que sur le prix au comptant de la transaction en cours, le flash loan n’aurait rien donné.

Dans la famille forgerie, le flash loan disparaît presque. Bonzo n’a eu besoin que de 3 dollars, parce qu’une fois le prix forgé, la taille du dépôt initial n’a plus d’importance : il est multiplié par douze ordres de grandeur. Ostium n’a emprunté aucun flash loan ; il a bouclé des trades avec une clé. Switchboard a frappé avec 1 IOTA. La leçon pratique est que compter les attaques « à flash loan » sous-estime structurellement la seconde famille, qui ne laisse pas cette signature-là. Quand un attaquant contrôle le prix à la source, il n’a pas besoin de capital, il a besoin d’une clé ou d’un bug.

CoreVault, cette semaine : l’ancienne école tient toujours

Rien de tout cela ne signifie que la manipulation économique est morte. Au contraire, elle bat des records. CoreVault, le 3 novembre, s’inscrit dans une série que TRM Labs chiffre à 32 attaques par manipulation de prix sur l’année 2026 jusqu’au début septembre, un sommet historique, contre 12 pour toute l’année 2025 ; environ un piratage sur huit relève désormais de cette catégorie, contre un sur dix-sept en 2022, selon les données reprises par Shattered. La redemption gonflée 33 fois de CoreVault, l’oracle qui se rabat sur le prix au comptant de la même transaction, tout cela aurait pu être écrit en 2020.

Mais ce décompte de 32 attaques raconte précisément ce qu’il ne compte pas. Ostium, Bonzo et Switchboard n’y figurent pas comme « manipulations de prix », parce que, techniquement, aucun marché n’a été manipulé. Le prix n’a pas été poussé : il a été écrit. La statistique qui rassure (la manipulation économique reste la norme) masque donc une seconde courbe, plus discrète, que personne n’agrège vraiment, celle des attaques qui s’en prennent à l’authentification du flux. C’est une angle mort de mesure autant que de défense. Pour un lecteur qui suit les mécaniques de prix des actifs dérivés comme le stETH, la nuance est tout sauf académique : un wstETH ou un VUSD dépend d’un prix signé quelque part, et ce quelque part a désormais trois façons connues de mentir.

Clés, pas code : la surface d’attaque a monté d’un étage

La forgerie de signature n’est pas un phénomène isolé. Elle est la déclinaison, côté oracle, d’une tendance de fond de 2026 : l’attaque ne vise plus le code, elle vise les clés et les personnes. CertiK a recensé plus de 1,31 milliard de dollars de pertes au premier semestre 2026 (environ 1,17 milliard d’euros), et des bilans plus larges parlent de 2,55 milliards sur 277 incidents jusqu’en septembre, avec une constante : environ 70 % de ces pertes proviennent de compromissions d’identifiants et d’infrastructure, pas de bugs de contrats, selon l’analyse relayée par crypto.news.

Comme le résume la firme CredShields, la surface d’attaque est montée « d’un étage, vers la gouvernance, vers les signataires, et vers les personnes qui construisent les protocoles ». L’oracle est le dernier maillon de cette chaîne à céder. Ostium, c’est une clé de signataire, exactement la même catégorie de faille qu’un portefeuille d’administration piraté. La bonne nouvelle, relative, est que ce déplacement rend le problème lisible : il ne s’agit plus de traquer une réentrance obscure dans 2 000 lignes de Solidity, mais de gérer des secrets et des listes d’autorisation comme le ferait n’importe quelle banque. La mauvaise, c’est que la DeFi a toujours sous-traité cette discipline à des middlewares qu’elle ne contrôle pas.

Défendre la couche message, pas le marché

Si les parades classiques sont hors sujet, que reste-t-il ? La défense de la famille forgerie se joue sur la couche message, et elle se décline en quelques principes concrets que les constructeurs peuvent appliquer dès aujourd’hui. Aucun n’est spectaculaire ; c’est précisément ce qui les rend fiables.

• Vérifier le vérificateur. Le bug de Bonzo était une absence de contrôle de nullité, de courbe et de sous-groupe avant le couplage BLS. Toute logique de vérification cryptographique doit rejeter l’élément neutre, les points hors courbe et les identifiants de comité hors plage, et cette logique doit être auditée formellement, pas seulement relue.
• Gérer les clés comme un secret bancaire. Modules matériels (HSM), rotation, et surtout signatures à seuil pour qu’une seule clé volée ne suffise jamais, comme dans la logique d’un bon dispositif anti-compromission.
• Surveiller l’ensemble des signataires. Toute modification de la liste des clés autorisées doit déclencher une alarme et, idéalement, passer par un délai (timelock) laissant le temps d’intervenir. L’attaque Switchboard aurait été visible avant d’être rentable.
• Recouper les sources de façon indépendante. Un deuxième oracle, de conception différente (push contre pull, BLS contre ECDSA), qui déclenche un gel dès que l’écart dépasse un seuil, transforme une forgerie silencieuse en divergence bruyante.
• Plafonner par la liquidité réelle. Même avec un prix forgé, lier le montant empruntable à la liquidité exécutable plafonne la casse. Un dépôt de 3 dollars ne devrait jamais pouvoir libérer 9 millions, quel que soit le prix affiché.

Aucune de ces mesures n’est nouvelle. Ce qui est nouveau, c’est la nécessité de les appliquer à l’oracle lui-même, et pas seulement au contrat qui le consomme. Pendant des années, les équipes ont audité leur propre code et considéré l’oracle comme une boîte noire fiable. Les incidents de 2026 ferment cette ère : l’oracle fait partie du périmètre de sécurité, point final.

Le prix forgé devant la loi : forgerie, pas « stratégie »

La famille forgerie a une vertu inattendue : elle est juridiquement limpide, là où la manipulation économique reste un marécage. L’affaire Mango Markets l’a montré. Avraham Eisenberg avait vidé le protocole de 110 millions de dollars en 2022 en poussant le prix du jeton MNGO, puis avait plaidé qu’il n’avait fait que trader sur une plateforme sans règles. Un juge fédéral a annulé l’ensemble de ses condamnations pénales en mai 2025, estimant notamment que le protocole ne comportait aucune interdiction de ce type d’opération. La frontière entre manipulation et stratégie agressive y est restée floue.

Voler la clé privée d’un signataire d’oracle, comme chez Ostium, ou inscrire frauduleusement sa propre clé dans un flux, comme chez Switchboard, ne laisse aucune place à cette défense. Il n’y a pas de « j’ai juste tradé » quand on s’introduit dans l’infrastructure de signature d’autrui : c’est un accès non autorisé à un système informatique et une falsification, des qualifications classiques du droit pénal, bien antérieures à la crypto. Le cas de Bonzo est plus subtil, puisque l’attaquant a exploité un bug public sans rien « voler » au sens matériel, ce qui rappelle les débats sur l’abus de faille, mais soumettre une signature que l’on sait invalide pour tromper un vérificateur reste une tromperie caractérisée. La forgerie déplace le curseur du « est-ce de la manipulation de marché ? » vers le « est-ce une intrusion ? », et la seconde question a des réponses beaucoup plus établies.

AMF, MiCA, DORA : l’oracle hors du périmètre

Pour un lecteur français, la question naturelle est : qui régule tout cela ? La réponse courte est : presque personne, pour la partie qui a cassé. MiCA encadre les prestataires de services sur crypto-actifs (PSCA) et les émetteurs de jetons, pas les oracles ni les protocoles pleinement décentralisés sans intermédiaire identifiable. Un oracle comme Supra ou Switchboard est un middleware : il se tient entre le marché et le protocole, et ne relève d’aucune catégorie d’acteur régulé. La victime d’un prix forgé sur un protocole DeFi n’a donc, en pratique, aucun recours auprès de l’AMF.

Cette zone grise s’est durcie avec le calendrier. La période transitoire qui permettait aux acteurs enregistrés PSAN d’opérer avant l’agrément PSCA complet s’est achevée le 1er juillet 2026, et l’AMF a rappelé que les acteurs non conformes doivent se retirer. Mais même un PSCA agréé consomme des oracles non régulés. Le règlement DORA impose aux entités financières régulées une résilience opérationnelle sur leurs systèmes informatiques, or une clé de signataire d’oracle est exactement ce type de contrôle opérationnel ; sauf qu’un réseau d’oracle DeFi n’entre pas dans le périmètre DORA. Il existe un décalage structurel entre l’endroit où le risque se matérialise (la couche signature) et l’endroit où la régulation s’applique (le prestataire visible).

Le cas d’Ostium ajoute une couche, puisqu’il s’agit d’une plateforme de perpétuels. En droit européen, un perpétuel est un contrat financier (un CFD) relevant de MiFID II, pas de MiCA, avec un effet de levier plafonné à 2:1 pour les particuliers. Une plateforme DeFi de perpétuels sur actifs réels échappe à ce régime comme au régime MiCA : ni contrepartie régulée, ni oracle régulé, ni levier plafonné. Ce chevauchement de vides juridiques est précisément ce que suit notre compte à rebours réglementaire, et il ne se refermera pas avant l’extension de MiCA à la DeFi, attendue au mieux pour 2027 ou 2028.

Ce qu’un utilisateur peut réellement regarder

Face à une couche aussi technique, l’utilisateur n’est pas totalement démuni. Quelques signaux, vérifiables avant de déposer des fonds, séparent les protocoles qui prennent la couche message au sérieux de ceux qui la traitent encore en boîte noire.

• Quel oracle le protocole utilise-t-il, et combien de sources indépendantes recoupe-t-il ?
• Le flux est-il signé par un quorum (plusieurs clés) ou par un signataire unique, point de défaillance idéal ?
• La logique de vérification de l’oracle a-t-elle été auditée formellement, et pas seulement relue ?
• Les modifications de configuration de l’oracle et de la liste des signataires passent-elles par un délai (timelock) public ?
• Les montants empruntables sont-ils plafonnés par la liquidité réelle, de sorte qu’un petit dépôt ne puisse jamais libérer une fortune ?

Ces questions ne garantissent rien, mais elles trient. Le standard OWASP SC03:2026 classe d’ailleurs la manipulation de prix parmi les risques majeurs des contrats intelligents, un rappel que le sujet n’est ni marginal ni résolu. La forgerie de signature est simplement la version la plus pure du problème : non pas un prix faussé par le marché, mais un prix inventé et pourtant valide. Tant que la DeFi dépendra d’un petit nombre de clés et de quelques lignes de vérification, l’oracle restera la contrepartie que personne n’a signée, et la signature forgée, l’attaque que rien dans l’arsenal classique n’arrête.

Foire aux questions (FAQ)

Qu’est-ce que la manipulation d’oracle en DeFi ?

C’est une attaque qui fausse le prix qu’un protocole DeFi utilise pour valoriser des actifs. Elle prend deux formes : pousser un marché peu liquide pour tromper un oracle honnête, ou forger directement le prix signé transmis à la blockchain, comme lors des incidents Ostium, Bonzo et Switchboard en 2026.

Quelle différence entre manipulation de marché et forgerie de signature d’oracle ?

Dans la manipulation de marché, l’oracle rapporte un prix réel que l’attaquant a créé le temps d’une transaction ; l’oracle ne ment pas. Dans la forgerie de signature, l’attaquant casse l’authentification du prix (clé volée, vérificateur bogué ou clé pirate inscrite) et fait afficher un chiffre qu’aucun marché n’a produit.

Le TWAP protège-t-il contre la manipulation d’oracle ?

Un TWAP (moyenne pondérée dans le temps) aide contre la manipulation de marché, car il lisse un pic de prix d’un seul bloc. Il ne protège pas contre la forgerie de signature : moyenner une suite de faux prix forgés produit simplement un faux prix lissé.

Les flash loans sont-ils la cause des attaques d’oracle ?

Non. Le flash loan est un amplificateur de la manipulation de marché, pas la faille. Les attaques par forgerie de signature n’en ont pas besoin : Bonzo a démarré avec 3 dollars de collatéral et Ostium a utilisé une clé volée, sans aucun emprunt éclair.

L’AMF ou MiCA protègent-elles en cas d’attaque d’oracle DeFi ?

Très peu. MiCA encadre les prestataires de services sur crypto-actifs et les émetteurs, pas les oracles ni les protocoles pleinement décentralisés. Une victime d’un oracle forgé sur un protocole DeFi n’a donc généralement aucun recours auprès de l’AMF, l’oracle restant une infrastructure non régulée.

Par Anneke de Vries, rédactrice spécialisée sécurité DeFi et exploits on-chain pour HOGE Wire.