Analyse approfondie : Attaque de manipulation du NAV du coffre-fort Morpho par prêt éclair USR déanchored

金色财经_ · 2026-03-26T06:47:30+00:00

Le 22 mars 2026, le protocole Resolv a subi une fuite de clé privée, entraînant une chute massive de l'USR et déclenchant une attaque complexe de manipulation de coffre-fort sur la plateforme Morpho. Les attaquants ont exploité la fonction supply non autorisée pour gonfler artificiellement les actifs totaux en USDC, permettant ainsi, dans un environnement d'oracle fixe, de réaliser des profits via des prêts flash, ce qui a finalement endommagé la liquidité normale du marché. Cet incident révèle plusieurs vulnérabilités et risques dans la conception de Morpho.

金色财经_

2026-03-26 06:47:30

Création du résumé en cours

22 mars 2026, le protocole Resolv a subi une fuite de clé privée, permettant à un attaquant de créer de toute pièce 80 millions d’USR sans garantie, faisant plonger le prix de l’USR de 1 $ à 0,025 $.

Les conséquences de cette catastrophe ne se sont pas limitées aux détenteurs d’USR. Un groupe plus intelligent a mené une attaque de manipulation sophistiquée du NAV du coffre-fort sur Morpho.

Cet article décompose étape par étape la logique sous-jacente de cette attaque.

Comprendre l’architecture à deux couches de Morpho

Avant de parler de l’attaque, il faut d’abord comprendre la conception de l’architecture de Morpho, sinon tout sera incompréhensible par la suite.

Le monde de Morpho se divise en deux couches :

Couche inférieure :

Morpho Blue (également appelé Morpho Core). C’est un protocole de prêt minimaliste, non upgradable. Sa philosophie de conception est “sans permission” — tout le monde peut créer un marché de prêt, déposer, emprunter, liquider.

Chaque marché est défini de façon unique par cinq paramètres : actif de prêt, actif de garantie, seuil de liquidation (LLTV), adresse de l’oracle, modèle de taux d’intérêt.

Les marchés sont totalement isolés entre eux : un problème dans un marché ne se propage pas aux autres.

Couche supérieure :

MetaMorpho Vault (le coffre). C’est un coffre conforme à la norme ERC-4626, équivalent à un “produit de fonds”.

Les utilisateurs déposent des USDC dans le coffre, et le gestionnaire (Curator) répartit ces fonds dans différents marchés Morpho Blue pour prêter et générer des intérêts.

Les utilisateurs détiennent des parts du coffre (shares), dont la valeur augmente avec les intérêts accumulés.

Formule clé — la valeur nette par action (NAV / Price Per Share) : Valeur nette par action = totalAssets / totalSupply

totalAssets correspond à la somme des positions de prêt dans tous les marchés (y compris celles déjà empruntées, car ce sont des “créances”). totalSupply est le total des parts émises par le coffre. Lorsqu’il y a accumulation d’intérêts, totalAssets augmente mais totalSupply reste inchangé, ce qui fait monter la valeur nette par action — c’est ainsi que vous gagnez de l’argent.

supply(onBehalf) — n’importe qui peut déposer pour le coffre

C’est le premier point clé de l’attaque.

Dans Morpho Blue, la fonction supply() possède un paramètre onBehalf. Ce design vise à faciliter la délégation — par exemple, un contrat de stratégie automatisée peut déposer pour l’utilisateur.

Mais cette fonction est totalement sans permission : n’importe qui peut désigner n’importe quelle adresse comme onBehalf, y compris l’adresse du coffre.

La documentation officielle de Morpho avertit clairement : “Warning: Anyone can supply on behalf of the vault so the call to updateWithdrawQueue that expects a market to be empty can be griefed by a front-run.”

Lorsque vous déposez 10 000 USDC pour le coffre, la position de supply dans ce marché augmente de 10 000, et totalAssets augmente aussi de 10 000. Mais le total des parts (totalSupply) du coffre ne change pas — car aucune nouvelle somme n’a été déposée via la fonction deposit() du coffre.

Résultat : la valeur nette par action est artificiellement gonflée.

Normalement, cela revient à “donner de l’argent” au coffre — vous augmentez les gains pour tous les détenteurs, ce qui est absurde. Mais dans certaines conditions, cela peut être exploité.

Supply Cap = 0 ≠ sécurité

Après le dépeg de l’USR, certains gestionnaires de coffres ont rapidement fixé le Supply Cap du marché USR/USDC à 0, empêchant toute nouvelle injection de fonds dans ce marché. La question est : le problème est-il résolu ?

Le problème réside dans le fait que : le Supply Cap est une limite au niveau du coffre, pas au niveau de Morpho Blue.

Le gestionnaire du coffre peut contrôler la fonction interne _supplyMorpho() du coffre.

Mais supply(onBehalf=vault) interagit directement avec le contrat Morpho Blue Core, en contournant totalement la logique du coffre : file d’attente de supply, limite de supply, vérification des permissions de l’allocateur, tout est bypassé.

Pour faire une analogie : le gestionnaire ferme la porte d’entrée (Cap=0), mais un attaquant peut passer par la porte dérobée de Morpho Core et y injecter de l’argent directement.

Oracles codés en dur — l’armure invisible des mauvaises créances

Second point clé.

L’oracle du marché USR/USDC est fixé à 1:1. Autrement dit, peu importe la chute du prix de l’USR sur le marché externe, dans l’univers Morpho, 1 USR vaut toujours 1 USDC.

Pourquoi le gestionnaire du coffre utilise-t-il un oracle fixe ? Parce que l’USR est une “stablecoin”, dont la volatilité est normalement faible. Un oracle fixe évite les “fausses liquidations” dues à une faible liquidité à court terme.

Mais quand l’USR se décolle réellement du peg, cet oracle fixe devient une catastrophe — les emprunteurs utilisent des USR dévalués comme garantie pour emprunter des USDC en quantité, sans que le protocole s’en rende compte.

Le mécanisme de gestion des mauvaises créances de Morpho échoue ici — la version 1.0 ne reflète pas en temps réel, la version 1.1 ne répartit pas équitablement, car le protocole doit pouvoir identifier les mauvaises créances.

L’oracle codé en dur ne permet pas cette détection.

Déroulement de l’attaque — boucle en cinq étapes

Maintenant que toutes les conditions sont réunies, voici l’enchaînement atomique en une seule transaction :

Pourquoi faut-il absolument un flash loan ?

C’est la question souvent négligée. Le profit de l’attaque repose sur “l’augmentation artificielle de totalAssets, puis la répartition proportionnelle de cette augmentation”. Si l’attaquant ne prend pas de flash loan, il détient 0% des parts — même si la valeur totale augmente, cette plus-value revient à tous les autres, et lui ne gagne rien.

Qui perd de l’argent ?

Les 12 300 USDC que l’attaquant vole ne sortent pas de nulle part. Cet argent provient de la liquidité réelle dans d’autres marchés sains du coffre.

Lors du retrait, le coffre extrait des USDC dans chaque marché selon l’ordre de la file de retrait. Or, dans le marché USR/USDC, l’USDC a déjà été emprunté en totalité, donc il ne reste plus de fonds. La liquidité provient donc d’autres marchés — comme wETH/USDC, cbBTC/USDC, etc., qui fonctionnent normalement.

L’effet combiné de trois vulnérabilités

Ce n’est pas une seule faille, mais la combinaison de trois problèmes de conception :

Conclusion

La philosophie minimaliste de Morpho — sans permission, non upgradable, avec une gouvernance minimale — est souvent un avantage. Mais cet incident montre que cette simplicité a un coût : elle transfère une partie de la responsabilité aux acteurs de haut niveau.

Le protocole ne vérifie pas l’oracle, le gestionnaire doit le faire lui-même. Il ne limite pas supply(onBehalf), le coffre doit donc prévoir des protections supplémentaires.

Pour les déposants, “choisir le bon Curator” est plus important que “choisir Morpho”. Le protocole est un outil, sa sécurité dépend de ceux qui l’utilisent.

MORPHO-5,77%

Voir l'original

Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.