The $9M yETH Exploit: How 16 Wei Became Infinite Tokens

Exploitation du yETH : Une Brèche à 9 Millions de Dollars

Une faille critique dans le protocole yETH de Yearn Finance a permis à un attaquant de subtiliser près de 9 millions de dollars le 30 novembre 2025. L’exploit a consisté à émettre une quantité astronomique de tokens yETH, 235 septillions, pour un dépôt initial de seulement 16 wei (une valeur insignifiante).

Points Clés :

• Vecteur d’attaque : Une mauvaise gestion de l’état interne du protocole, spécifiquement dans le pool yETH.
• Mécanisme d’exploitation : L’attaquant a profité d’une optimisation de coût de gaz qui utilisait des variables packed_vbs[] pour stocker des soldes virtuels. Ces variables n’étaient pas correctement réinitialisées à zéro lors du retrait complet de toute liquidité du pool.
• Déroulement de l’attaque :
  1. L’attaquant a effectué de multiples cycles de dépôt et retrait pour accumuler des valeurs résiduelles dans les packed_vbs[].
  2. Il a ensuite retiré toute la liquidité restante, mettant l’offre à zéro tout en conservant ces soldes virtuels accumulés.
  3. Un dépôt minimal (16 wei) a été effectué, ce qui a déclenché la logique de “premier dépôt”. Le protocole a lu les valeurs obsolètes dans packed_vbs[] au lieu du dépôt réel, générant ainsi une quantité excessive de tokens LP.
  4. L’attaquant a échangé ces tokens nouvellement créés contre des actifs de valeur.

Vulnérabilité :

• Défaillance dans la réinitialisation de l’état : La fonction remove_liquidity() ne réinitialisait pas explicitement les variables packed_vbs[] à zéro lorsque l’offre totale de tokens LP devenait nulle. Des montants minimes persistaient en raison d’erreurs d’arrondi.
• Hypothèse erronée du protocole : La fonction add_liquidity() interprétait une offre nulle comme un “premier dépôt” dans un pool vierge, ignorant les valeurs résiduelles persistantes dans packed_vbs[].
• Absence de CVE spécifique mentionnée dans l’article.

Recommandations :

• Gestion explicite de tous les états : Les systèmes complexes nécessitent une gestion rigoureuse de toutes les transitions d’état, y compris les cas limites.
• Tests complets : Une validation approfondie des scénarios, y compris ceux impliquant le retrait complet de la liquidité, est cruciale.
• Simulation de transactions : Avant l’exécution, simuler des transactions pour détecter des ratios de génération de tokens anormaux.
• Surveillance de l’état sur plusieurs transactions : La détection doit pouvoir suivre l’évolution de l’état à travers une séquence de transactions.
• Protection en temps réel : Mettre en place des mécanismes qui bloquent automatiquement les activités suspectes lorsqu’un schéma de “drain” est détecté, plutôt que de simplement alerter après l’incident.

L’exploit souligne l’importance de la discipline d’ingénierie, d’une gestion méticuleuse de l’état et de la nécessité de solutions de sécurité capables de comprendre la logique du protocole, au-delà de la simple détection basée sur des signatures.

Source