Auteur : Lianxi Cryptolab
1. Contexte de l’événement : une configuration d’oracle qui cache des risques
La cause de l’attaque remonte à une proposition de gouvernance (MIP-X43), qui a activé une nouvelle configuration d’oracle Chainlink sur le marché Moonwell des réseaux Base et Optimism. (Note : un oracle est un outil permettant d’obtenir des données en temps réel avant leur soumission à la blockchain)
Dans des protocoles de prêt comme Moonwell, les utilisateurs déposent des actifs comme cbETH en tant que garantie pour emprunter d’autres tokens. Si le marché chute et que la valeur de la garantie devient inférieure à la dette, le robot liquide automatiquement la position (les fonds totaux de l’utilisateur), rembourse la dette et saisit la garantie à prix réduit.
Avant l’incident, le marché cbETH de Moonwell disposait de beaucoup de fonds et de garanties, mais le test de l’oracle était insuffisant, omettant une étape de multiplication, ce qui a entraîné une erreur grave de prix, amplifiant considérablement le risque.
2. Analyse de l’événement : une erreur de code générée par l’IA
Cet incident est la première erreur de sécurité en chaîne causée par Vibe Coding (codage assisté par IA), dont le cœur est une vulnérabilité de configuration d’oracle simple mais fatale.
1. Cause de la vulnérabilité
La racine du problème réside dans une mauvaise tarification de l’actif cbETH par l’oracle. cbETH est un jeton de staking liquide, dont la valeur inclut les récompenses de staking accumulées. Normalement, 1 cbETH peut être échangé contre environ 1.12 ETH.
Ainsi, la logique correcte pour calculer le prix en dollars est :
Prix en dollars de cbETH = (taux de change cbETH/ETH) × (prix en dollars de l’ETH)
Par exemple : si 1 cbETH ≈ 1.12 ETH, et 1 ETH ≈ 2200 USD, alors la valeur réelle de 1 cbETH devrait être environ 2464 USD.
Cependant, dans le code généré par l’outil IA Claude, faute de vérification logique complète, le prix de cbETH a été directement lié à la source cbETHETH_ORACLE. Cette source ne fournit que le taux de change cbETH/ETH (c’est-à-dire 1.12), sans accès au prix en dollars de l’ETH.
Cette omission de la multiplication clé a conduit le programme à considérer le « taux de change » comme la « valeur en dollars ». Un actif normalement évalué à plus de 2400 USD a été erronément marqué comme valant 1.12 USD, sous-estimant de plus de 99,9 %, avec une différence de prix proche de 2000 fois.
2. Rétroaction de l’attaque
La sous-estimation grave de l’actif a directement conduit à ce que de nombreux utilisateurs normaux voient leur position de garantie considérée à tort comme insolvable. La procédure d’exploitation de la vulnérabilité a été extrêmement efficace, avec une forte automatisation :
16 février 2026, 2h01 UTC+8 : la proposition MIP-X43 est exécutée, et l’oracle cbETH mal configuré sur Base est activé.
Les robots de liquidation en chaîne surveillent les opportunités de profit. En utilisant un flash loan, ils empruntent rapidement une petite somme de USDC à très faible coût, remboursent la dette du prêteur (car le système pense que 1 cbETH vaut un peu plus d’un dollar), et obtiennent ainsi le droit de liquider.
Après avoir saisi une garantie cbETH d’une valeur très élevée, les robots la revendent immédiatement sur DEX au prix du marché. Plusieurs robots ont tourné en boucle pendant quelques minutes, saisissant au total 1096,317 cbETH.
Cette attaque n’était pas planifiée par un hacker, mais par des robots de liquidation exécutant un code absurde. N’étant pas un « voleur » traditionnel, où est donc passé ce montant de 1,78 million de dollars qui a disparu ? La réponse dépendra des flux financiers suivants.
3. Flux de fonds : pas de hacker, seulement des arbitrageurs
Puisqu’il n’y a pas de hacker traditionnel, à qui revient cette somme de 1,78 million de dollars évaporée ?
Où est passé l’argent ?
Réponse : aux arbitrageurs derrière le déploiement des robots de liquidation.
Les robots de liquidation ne sont pas apparus spontanément, ils sont créés et déployés par de véritables programmeurs ou équipes quantitatifs (chercheurs MEV) via des scripts automatisés sur la chaîne. Lorsque le système, à cause d’une erreur IA, vend à la hâte un actif valant 2400 USD à un prix dérisoire, ces robots, comme des chasseurs, repèrent immédiatement l’opportunité.
Ils remboursent automatiquement la dette de plus d’un dollar en comptabilité, saisissent la garantie de grande valeur, puis la revendent au prix du marché. Au final, cette différence de près de 178 000 USD a été entièrement transférée dans le portefeuille crypto personnel des propriétaires des robots. En exploitant la faille du système, ils ont légitimement et conformément à la loi réalisé cette opération de plusieurs millions de dollars.
Dans cet incident, 11 types d’actifs ont été affectés, avec des pertes spécifiques comme suit :
Après l’incident, l’équipe Moonwell a rapidement suspendu les fonctions de prêt et de liquidation, puis soumis une nouvelle proposition de correction pour reconfigurer les paramètres de l’oracle. Pour restaurer la confiance, le protocole a dû puiser dans ses fonds de réserve pour combler le trou de 178 000 USD, indemnisant intégralement les utilisateurs innocemment liquidés.
4. L’IA à la tête : efficacité accrue ou risque accru ?
Après l’incident, la majorité des commentaires ont accusé « Claude d’avoir écrit une vulnérabilité fatale », mais objectivement, mettre cette perte de 1,78 million de dollars sur le dos de l’IA est un peu injuste.
Ce bug n’est en rien une vulnérabilité complexe, c’est une erreur de configuration super simple — il manquait une multiplication par un taux de change.
Honnêtement, ce genre d’erreur basique pourrait tout aussi bien être commise par un programmeur humain.
Ce qui est réellement critique, c’est que tout le processus de vérification du projet est défaillant. Avant le lancement, personne ne vérifie manuellement si le « prix est raisonnable » dans le code. Si vous donnez une instruction correcte, l’IA peut parfaitement générer ces tests de prévention d’erreur de façon claire et précise.
La plus grande leçon à tirer de cette erreur n’est pas que « l’IA ne peut pas coder », mais que, pour gagner du temps, on a négligé la dernière étape cruciale de contrôle.
Peu importe à quel point l’IA est utile ou performante, elle n’a pas de concept de l’argent réel ni de responsabilité. L’IA ne peut jamais remplacer l’humain ; c’est un outil très pratique, mais c’est l’humain qui doit l’utiliser, et non l’inverse. L’IA ne doit jamais devenir la voix dominante.
5. En conclusion : quand l’IA écrit du code, l’humain doit rester vigilant
L’incident de Moonwell n’est pas complexe en soi : pas de hackers de haut niveau, pas de vulnérabilités sophistiquées, ni d’attaques compliquées. C’est simplement une erreur de code faite par l’IA, et l’humain n’a pas vérifié.
Mais dans le monde de la blockchain, une simple négligence dans le code peut représenter des millions de dollars en argent réel. Dans la DeFi, le code, c’est la règle. Une fois inscrite sur la chaîne, elle est exécutée sans hésitation par la machine. Plus de projets dépendent de « Vibe Coding », plus la vérification du code et la gestion des risques doivent devenir la dernière ligne de défense.
La technologie peut devenir de plus en plus automatisée, mais la sécurité ne doit jamais l’être.
