Analyse approfondie de l'incident de piratage de 9 millions de dollars en actifs Yearn : du vulnérabilité du protocole à l'évaporation de la valeur en dollars

2025年12月1日, l’accord Yearn a connu une attaque multi-niveaux soigneusement orchestrée dans l’histoire de la DeFi, aboutissant à la perte totale d’environ 9 millions de dollars d’actifs utilisateur. Il ne s’agit pas d’une simple exploitation d’une vulnérabilité isolée, mais d’une destruction systémique où l’attaquant a utilisé un flash loan pour mobiliser des fonds, a franchi étape par étape les mécanismes de protection du protocole, a créé à l’infini des LP tokens yETH liés à des pools de stablecoins, pour finalement épuiser la pool de liquidités. Cet incident rappelle une fois de plus à l’industrie : le risque de sécurité des protocoles DeFi ne réside pas dans une seule faille, mais dans la superposition de plusieurs défauts qui peuvent être déclenchés simultanément — c’est le mode d’attaque le plus difficile à défendre actuellement dans le secteur.

Aperçu de l’événement : comment le flash loan a servi de levier pour une attaque en plusieurs phases

La stratégie de préparation des fonds de l’attaquant semble banale, mais elle pose les bases d’une série d’opérations en chaîne. Il a lancé simultanément des flash loans depuis les protocoles Balancer et Aave, empruntant en une seule fois de grandes quantités de wstETH, rETH, WETH, ETHx, cbETH, etc., divers dérivés d’ETH. Ces actifs n’ont pas été directement échangés, mais répartis avec soin : 100 ETH sur 1100 ont été envoyés dans Tornado.Cash pour le mélange — cette étape a pour vrai but de dissimuler la provenance des fonds, préparant le terrain pour une opération de “blanchiment”.

Après le mélange, l’attaquant a transféré 100 ETH vers une adresse de contrat malveillant 0x3e8e7533dcf69c698Cf806C3DB22f7f10B9B0b97, et a déclenché la fonction fallback. Dans ce rappel caché, tous les actifs empruntés ont été convertis en LP tokens du pool weighted stableswap yETH — équivalent à l’achat d’une “part” dans ce fonds de liquidités. Apparemment une injection de liquidité ordinaire, mais en réalité la préparation ultime d’un “pool d’épargne” sophistiqué.

Trois vulnérabilités majeures : perte de précision, détournement de gains, initialisation à zéro de la supply menant à une combinaison fatale

Première vulnérabilité : perte de précision et manipulation d’état sans coût

Le cœur technique de l’attaque repose sur une faille apparemment mineure : la fonction remove_liquidity ne gère pas le cas où le montant est zéro.

L’attaquant commence par créer délibérément un déséquilibre extrême dans le pool. Il appelle à répétition add_liquidity (ajout de liquidité), en ignorant volontairement les tokens index 3 (rETH), 6 (wOETH) et 7 (mETH), ce qui augmente artificiellement le décalage entre ces trois actifs et les autres. Ensuite, il injecte massivement du rETH en une seule fois, accentuant encore le déséquilibre.

Dans cet état de déséquilibre extrême, il appelle remove_liquidity avec un montant d’entrée de 0. Selon la logique classique, retirer 0 tokens devrait simplement retourner sans changer l’état. Mais le contrat pool.vy ne le fait pas — il exécute toujours la boucle complète de calcul du produit virtuel vb_prod.

Dans ce contexte mathématique de poids extrêmes, la fonction _pow_down (qui effectue un arrondi vers le bas) génère une perte de précision notable. Le contrat calcule incorrectement une valeur de vb_prod trop petite, et écrit cette valeur falsifiée dans l’état global packed_pool_vb. En substance, l’attaquant, par une opération “zéro coût” (sans transférer de tokens), a réussi à falsifier la valeur comptable du pool.

Deuxième vulnérabilité : détournement de gains et dilution des parts

La seconde faille est plus insidieuse. Lorsqu’il appelle update_rates, cela déclenche la logique _update_supply. En raison de la baisse malveillante de vb_prod, le système croit à tort que la valeur totale du pool a fortement diminué. Pour équilibrer le registre, le contrat détruit automatiquement une grande quantité de LP tokens détenus par le contrat de staking.

L’attaquant profite de cette mise à jour pour faire de l’arbitrage. Il met à jour les taux de certains actifs (wOETH, mETH), puis appelle immédiatement remove_liquidity pour retirer ces actifs. La destruction massive des parts de staking augmente la proportion de LP tokens détenus par l’attaquant. En répétant ce cycle “mise à jour — retrait — destruction”, il vide progressivement la balance de wOETH et mETH, tout en poussant la supply totale du pool vers une limite critique proche de zéro.

Troisième vulnérabilité : création infinie de tokens à zéro supply

Après ces deux phases, le pool est presque vidé : la supply totale approche 0, et les balances de wOETH et mETH sont très faibles. C’est alors que l’attaquant lance le dernier coup fatal : il appelle add_liquidity avec le paramètre [1, 1, 1, 1, 1, 1, 1, 9], c’est-à-dire injecter 1 wei (la plus petite unité) dans chacun des sept premiers actifs, et 9 wei dans le huitième (mETH).

Ce qui semble absurde, mais dans le contexte critique du pool, provoque une erreur de calcul dans _calc_supply. La formule d’itération échoue à traiter ces très petits nombres, et le contrat crée à tort 235 443 yETH LP tokens — une création artificielle de plusieurs millions de dollars en faux actifs.

Quatre phases de l’attaque : de l’extrême déséquilibre à la création infinie

Phase 1 : préparation des fonds et initialisation du pool

• Emprunt de divers dérivés ETH via Balancer et Aave
• Mélange des fonds via Tornado.Cash pour dissimuler la provenance
• Conversion de tous ces fonds en LP tokens yETH

Phase 2 : déséquilibre artificiel extrême

• Injection répétée de liquidité en ignorant certains tokens (rETH, wOETH, mETH)
• Injection massive de rETH pour accentuer le déséquilibre
• Préparation mathématique pour la perte de précision

Phase 3 : détournement de gains et dilution des parts

• Appel de remove_liquidity(0) pour déclencher la perte de précision
• Mise à jour des taux, destruction des LP tokens de staking
• Arbitrage répété pour vider wOETH et mETH
• La supply totale du pool tend vers zéro

Phase 4 : création infinie à zéro supply

• Ajout de liquidité avec [1,1,1,1,1,1,1,9]
• Échec de _calc_supply, qui crée à tort 235 443 LP tokens
• Utilisation de exchange et redeem pour convertir en ETH, stablecoins, puis en BTC ou USD
• Transfert final de millions de dollars de fonds des pools vers le portefeuille de l’attaquant, puis en fiat ou BTC pour évasion

Traçage des fonds et processus de liquidation : de yETH à la perte de valeur en dollars

L’issue de cette attaque est une fuite de fonds spectaculaire. Les 235 443 LP tokens obtenus ont été échangés en ETH et stablecoins, puis convertis via des DEX en BTC ou autres actifs plus difficiles à tracer. Enfin, par des plateformes OTC, ces fonds ont été transformés en cash ou en BTC, permettant à l’attaquant de s’échapper avec plusieurs millions de dollars. En tout, environ 9 millions de dollars de fonds utilisateur ont été transférés de manière visible sur la chaîne, passant du solde du protocole à la wallet de l’attaquant, puis convertis en fiat ou crypto pour une fuite définitive.

Leçons pour l’industrie : comment prévenir les attaques combinées complexes dans la DeFi

Les enseignements clés de cet incident sont au nombre de trois :

Leçon 1 : renforcer la vérification des scénarios extrêmes Les protocoles DeFi doivent effectuer des contrôles stricts sur les cas limites comme “zéro montant” ou “déséquilibre extrême”. La fonction remove_liquidity doit immédiatement retourner si le paramètre est zéro, plutôt que d’exécuter la boucle de calcul. Ce type de “short-circuit” simple peut empêcher la manipulation d’état.

Leçon 2 : optimiser la logique de calcul de précision Les fonctions impliquant des ratios extrêmes, comme _pow_down, doivent intégrer des mécanismes de protection. On peut utiliser des bibliothèques de calcul plus précises, ajouter des vérifications d’overflow, ou adopter des algorithmes alternatifs en cas de valeurs extrêmes. L’histoire de Balancer montre que des erreurs de précision peuvent mener à des attaques — un précédent à ne pas négliger.

Leçon 3 : établir une surveillance multi-dimensionnelle des anomalies Il faut déployer des systèmes de monitoring en temps réel pour détecter :

• des injections de liquidité massives et asymétriques
• des fluctuations anormales de taux et des destructions automatiques
• des transactions à zéro montant ou avec des valeurs très faibles
• des variations brutales de la supply totale en peu de temps

Pour l’ensemble de l’écosystème DeFi, cet incident prouve une vérité fondamentale : la sécurité ne réside pas dans la correction d’une seule faille, mais dans la prévention systémique de la combinaison de plusieurs défauts. Les développeurs doivent examiner leur code sous tous les angles, sans laisser passer de “failles inoffensives”. Par ailleurs, l’industrie doit renforcer la traçabilité et la capacité à geler les fonds suspects, via des listes noires sur DEX, des contrôles OTC, etc. L’incident Yearn n’est pas une fin, mais un catalyseur pour faire évoluer la sécurité de la DeFi.