Analyse approfondie : attaque de manipulation du NAV du coffre-fort Morpho après le désancrage de l'USR par un prêt éclair.

Écrire :菠菜菠菜

Le 22 mars 2026, le protocole Resolv a été victime d’une fuite de clé privée, permettant à un attaquant de créer de toute pièce 80 millions d’USRs sans garantie, faisant chuter leur valeur 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 sophistiquée de manipulation du NAV du coffre-fort sur Morpho.

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

1. 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.

L’univers de Morphe se divise en deux couches :

Couche inférieure :

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

Chaque marché est défini de façon unique par cinq paramètres : l’actif de prêt, l’actif de garantie, la ligne de liquidation (LLTV), l’adresse de l’oracle, et le 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) : chaque part = totalAssets / totalSupply

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

2. 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 dépôt dans ce marché augmente de 10 000, et totalAssets aussi. Mais le total des parts (totalSupply) ne change pas — car aucune nouvelle part n’est créée via la fonction deposit() du coffre.

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

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

3. 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, ce qui signifie qu’ils ne peuvent plus y déposer de fonds. Cela semble résoudre le problème ?

Le problème, c’est 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 toute logique du niveau du coffre : la file d’attente de dépôt, le plafond de dépôt, la vérification des permissions de l’allocateur, tout cela est ignoré.

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

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

C’est le deuxième point clé.

Le marché USR/USDC utilise un oracle 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 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 si l’USR se dépeg réellement, cet oracle fixe devient une catastrophe — les emprunteurs peuvent utiliser des USR dévalués comme garantie pour emprunter de gros montants en USDC, sans que le protocole en ait conscience.

Le mécanisme de gestion des mauvaises créances de Morpho échoue ici — la version 1.0, qui reflète en temps réel, et la version 1.1, qui répartit les pertes, supposent que le protocole peut identifier les mauvaises créances.

Mais si l’oracle est codé en dur, rien ne peut être détecté.

5. Processus complet de l’attaque — boucle en cinq étapes

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

[Insérer étape par étape de l’attaque]

6. Pourquoi une flash loan est indispensable ?

C’est une question souvent négligée. La rentabilité de l’attaque repose sur le fait de “gonfler artificiellement totalAssets, puis répartir la plus-value en proportion des parts”. Si l’attaquant ne prend pas de flash loan, il détient 0 % des parts — même si la valeur totale augmente, la plus-value revient aux autres actionnaires, et lui ne gagne rien.

7. Qui perd de l’argent ?

Les 12 300 USDC supplémentaires que l’attaquant a empochés ne sont pas apparus de nulle part. Cet argent provient de la liquidité réelle dans d’autres marchés sains du coffre.

Lors du rachat, le coffre retire des USDC dans l’ordre de la file d’attente de retrait, en puisant dans tous les marchés. Or, le marché USR/USDC a été vidé, impossible d’y retirer des fonds. La liquidité provient donc d’autres marchés — par exemple wETH/USDC, cbBTC/USDC, etc.

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

Cette attaque n’est pas le résultat d’une seule faille, mais de la combinaison de trois problèmes de conception :

[Insérer détails des vulnérabilités]

Conclusion

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

Le protocole ne vérifie pas l’oracle, c’est à l’administrateur de le faire. Il ne limite pas supply(onBehalf), le coffre doit donc mettre en place 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.