
Le plus gros piratage DeFi de 2026 : après avoir volé des fonds, le pirate a profité de l’occasion pour nuire à Aave.
TechFlow SélectionTechFlow Sélection

Le plus gros piratage DeFi de 2026 : après avoir volé des fonds, le pirate a profité de l’occasion pour nuire à Aave.
Une fausse information a permis de dérober 292 millions de dollars : le pont interchaînes de Kelp DAO vidé en 46 minutes
Texte : Xiao Bing, TechFlow
Le 18 avril à 17 h 35 (UTC), un portefeuille ayant blanchi des fonds via Tornado Cash a envoyé un message interchaîne au contrat EndpointV2 de LayerZero.
Ce message avait une signification simple : un utilisateur sur une autre chaîne souhaitait rapatrier des rsETH vers le réseau principal Ethereum. Conformément à sa conception protocolaire, LayerZero a fidèlement relayé cette instruction. Le contrat de pont déployé par Kelp DAO sur le réseau principal a, lui aussi conformément à sa conception, exécuté fidèlement la libération des actifs.
Ainsi, 116 500 rsETH — soit environ 292 millions de dollars américains à ce cours — ont été transférés en une seule transaction vers une adresse contrôlée par l’attaquant.
Or, aucun rsETH n’avait jamais été déposé sur l’autre chaîne. Cette « demande interchaîne » était entièrement fabriquée. LayerZero y a cru, tout comme le pont de Kelp.
Quarante-six minutes plus tard, la signature multi-signature d’urgence de Kelp a enfin activé la pause. À ce moment-là, l’attaquant avait déjà accompli la seconde moitié de son opération : il avait mis en garantie les rsETH volés — désormais dépourvus d’ancrage économique — sur Aave V3 et emprunté environ 236 millions de dollars américains en wETH.
Il s’agit du plus important vol DeFi survenu en 2026 à ce jour, dépassant même de plusieurs millions de dollars l’attaque subie le 1er avril par le protocole Drift, attribuée à des pirates nord-coréens. Toutefois, ce qui glace véritablement le sang des professionnels du secteur ne réside pas uniquement dans le montant volé.
Comment l’attaque s’est-elle produite ? Trois tentatives entre 17 h 35 et 18 h 28
Reconstituons la chronologie.
À 17 h 35 UTC, premier succès. L’attaquant a appelé la fonction lzReceive sur le contrat EndpointV2 de LayerZero à l’aide d’un portefeuille financé par des fonds blanchis via Tornado Cash, transmettant ainsi au contrat de pont de Kelp un paquet de données interchaînes falsifié. La validation du contrat a abouti, et 116 500 rsETH ont été libérés vers l’adresse de l’attaquant — en une seule transaction, propre et nette.
À 18 h 21 UTC, la signature multi-signature d’urgence de Kelp a gelé les principaux contrats rsETH sur le réseau principal Ethereum ainsi que sur plusieurs L2. Cela s’est produit 46 minutes après le début de l’attaque.
À 18 h 26 et 18 h 28 UTC, l’attaquant a lancé deux nouvelles tentatives, chacune accompagnée d’un paquet de données LayerZero visant à extraire à nouveau 40 000 rsETH (environ 100 millions de dollars américains). Les deux tentatives ont échoué avec une erreur revert, car les contrats étaient déjà gelés. Néanmoins, l’attaquant essayait clairement de récupérer la totalité de la liquidité restante.
Près de trois heures se sont écoulées entre le premier succès et la publication de la déclaration publique de Kelp.
Le premier message X (anciennement Twitter) de Kelp n’a été publié qu’à 20 h 10 UTC, avec une formulation très mesurée : « Une activité interchaîne suspecte impliquant des rsETH a été détectée ; les contrats rsETH sur le réseau principal et sur plusieurs L2 ont été suspendus ; une analyse approfondie de la cause racine est en cours en collaboration avec LayerZero, Unichain, les auditeurs et des experts externes en sécurité. »
Mais c’est ZachXBT, détective blockchain, qui a fourni la conclusion bien avant toute déclaration officielle : avant 15 h (heure de l’Est américain), il a alerté ses abonnés sur Telegram, listant six adresses de portefeuilles liées à ce vol et indiquant que tous les portefeuilles attaquants avaient préalablement blanchi leurs fonds via Tornado Cash. Bien qu’il n’ait pas nommé explicitement Kelp DAO, les analystes blockchain ont établi le lien entre ces adresses en quelques heures seulement.
Il s’agit donc d’une opération soigneusement planifiée et exécutée à la minute près. Portefeuilles préchargés et blanchis, paquets de données interchaînes soigneusement conçus, enchaînement fluide entre l’attaque et l’emprunt sur Aave : chaque étape semblait cadencée comme par un métronome.
Vol + sabotage
Si cette affaire ne relevait que d’une simple faille de pont, consistant à voler 116 500 rsETH puis à disparaître, elle ne serait qu’un incident majeur parmi d’autres en 2026. Kelp assumerait la perte, la communauté digérerait l’événement en quelques jours, et le secteur continuerait d’avancer.
Mais l’attaquant avait manifestement fait ses calculs. La liquidité secondaire des rsETH n’étant pas suffisante, vendre directement 292 millions de dollars américains de rsETH sur les DEX aurait entraîné un glissement (*slippage*) substantiel, grignotant une part importante du profit. Une sortie plus élégante consistait à transformer ces rsETH « obtenus ex nihilo » en garanties crédibles, afin d’emprunter des actifs véritablement liquides auprès de protocoles de prêt.
L’attaquant a donc procédé à une deuxième étape : il a déposé les rsETH volés comme garantie sur Aave V3 pour emprunter une importante quantité de wETH.
Pourquoi cette étape est-elle fatale ? Parce qu’à cet instant précis, le contrat Aave continuait d’évaluer la valeur de ces rsETH selon leur prix fourni par l’oracle, tandis que les réserves du pont avaient déjà été vidées. En réalité, le fondement économique de ces rsETH avait disparu. Pourtant, le protocole de prêt accordait encore des prêts comme si ces garanties conservaient une « teneur en or » de 100 % — alors qu’elles ne constituaient en fait qu’un chèque sans provision.
Le résultat est le suivant : l’attaquant a transféré le risque de liquidation de ces fonds à la réserve de wETH d’Aave.
Actuellement, la réserve de wETH d’Aave V3 absorbe ces créances douteuses. Le développeur Solidity et auditeur 0xQuit a alerté sur X les déposants : la pool wETH est effectivement endommagée, et certains retraits ne seront possibles qu’après que le module de secours Umbrella d’Aave aura comblé le déficit.
Le montant estimé des créances douteuses atteint actuellement 177 millions de dollars américains — et cela ne concerne que le réseau principal Ethereum.
Un test grandeur nature, prévu depuis longtemps
Pour les anciens adeptes du DeFi, ce scénario évoque une situation familière : lors de l’effondrement de Luna en 2022, le Safety Module d’Aave V2 avait déjà joué un rôle similaire.
Cette fois, c’est Umbrella qui entre en scène : le nouveau système de secours d’Aave, lancé fin 2025 pour remplacer l’ancien Safety Module, subit ici son premier test majeur en conditions réelles — celui de son mécanisme automatique de couverture des créances douteuses.
La logique d’Umbrella est simple : les utilisateurs gagent des aToken tels que aWETH, aUSDC ou GHO dans les coffres correspondants d’Umbrella. En échange, ils perçoivent des incitations supplémentaires. Toutefois, dès qu’un déficit apparaît dans le pool d’actifs correspondant, une partie de ces avoirs gagés est réduite proportionnellement (*slashing*) pour combler le trou.
Cette conception paraît impeccable sur le papier : durant le premier mois de fonctionnement d’Aave v3.3, le déficit cumulé de l’ensemble des pools s’élevait à environ 400 dollars américains, pour près de 9,5 milliards de dollars américains de prêts impayés — un ratio négligeable.
Mais un déficit de 177 millions de dollars américains appartient à une autre dimension. Pour les utilisateurs ayant gagé des aWETH sur Umbrella, cela signifie qu’ils vont ressentir pour la première fois concrètement le poids des mots « risque de *slashing* ». La position officielle d’Aave reste prudente : « En cas de créance douteuse, Aave prévoit d’utiliser les actifs d’Umbrella pour combler tout déficit financier. Toutefois, la capacité totale de couverture, le taux de *slashing*, ou encore la perte effective du capital des utilisateurs ne pourront être déterminés qu’après finalisation du processus de règlement. »
Le péché originel des ponts interchaînes
Ce qui inquiète davantage encore, c’est la nature même des rsETH volés.
Les rsETH sont déployés sur plus de vingt réseaux, notamment Base, Arbitrum, Linea, Blast, Mantle et Scroll. Leur transfert interchaînes repose sur la norme OFT de LayerZero. Or, les rsETH qui ont été vidés du pont constituent justement les réserves soutenant tous les rsETH « enveloppés » (*wrapped*) sur ces réseaux.
Cette architecture semble banale : la trésorerie principale détient des réserves à hauteur de 1:1, et les détenteurs de rsETH sur les L2 peuvent théoriquement les échanger à tout moment contre des rsETH sur le réseau principal. Mais ce mécanisme repose sur une hypothèse essentielle : la trésorerie doit réellement contenir des fonds.
Aujourd’hui, celle-ci est vide à hauteur de 18 %. En effet, environ 18 % de l’offre circulante totale de rsETH chez Kelp ont perdu leur réserve correspondante du jour au lendemain.
Cela déclenche une boucle de rétroaction : dès lors que les détenteurs de rsETH sur les L2 commencent à racheter massivement par crainte, la pression se transmet à la partie non affectée de l’offre sur le réseau principal, poussant potentiellement Kelp à dégager ses positions de *re-staking* afin de faire face aux demandes de retrait.
Dégager une position de *re-staking* n’est pas une simple question de clic. Le délai de retrait sur EigenLayer est contraignant, et la sortie des validateurs sous-jacents nécessite une période d’attente. Si les détenteurs de rsETH sur les L2 se précipitent collectivement vers la fenêtre de rachat, Kelp pourrait ne pas avoir le temps de mobiliser les liquidités nécessaires sur le réseau principal.
C’est là un risque structurel inhérent au modèle des réserves de pont : dès que le réservoir principal connaît un problème, la pression hydraulique s’effondre sur tous les canaux dérivés en aval. Chaque détenteur de rsETH sur une L2 se retrouve aujourd’hui confronté à la même décision : fuir immédiatement, ou faire confiance à Kelp pour assumer la garantie ?
En quelques heures, la panique a balayé l’ensemble du secteur du prêt DeFi.
Les marchés rsETH d’Aave V3 et V4 ont été gelés, et les nouveaux dépôts ainsi que les prêts basés sur rsETH ont été suspendus.
SparkLend et Fluid ont suivi en gelant leurs marchés rsETH.
Ethena, bien qu’ayant déclaré ne présenter aucune exposition aux rsETH et maintenir un excédent de garantie supérieur à 101 %, a néanmoins pris la mesure préventive de suspendre temporairement son pont interchaînes OFT via LayerZero depuis le réseau principal Ethereum — pour une durée prévue d’environ six heures. Cette réaction est particulièrement révélatrice : même les acteurs sans exposition directe cessent d’utiliser les ponts liés à LayerZero.
Lido Finance a suspendu les nouveaux dépôts sur son produit earnETH (car ce dernier intègre une exposition aux rsETH), tout en précisant que stETH et wstETH ne sont pas concernés, et que le protocole central de *staking* de Lido est totalement étranger à cet incident.
Upshift a suspendu les dépôts et retraits des caisses High Growth ETH et Kelp Gain.
Cette liste continue de s’allonger.
Commentaire de TechFlow : La sécurité du DeFi, un chemin semé d’embûches
À l’heure où cet article est rédigé, l’analyse de la cause racine menée par Kelp DAO est toujours en cours. Une partie des rsETH volés pourra-t-elle être récupérée grâce aux efforts des équipes de sécurité ou à des négociations avec des « chapeaux blancs » ? Umbrella d’Aave sera-t-il capable de supporter ce déficit ? Une ruée vers les rachats se déclenchera-t-elle parmi les détenteurs de rsETH sur les L2 ? Les cours d’AAVE et de rsETH parviendront-ils à se stabiliser avant la fin du week-end ?
Certaines questions, toutefois, se posent déjà avec acuité.
Par exemple : les LRT peuvent-ils encore être considérés comme des garanties acceptables par les protocoles de prêt ?
Les Liquid Restaking Tokens (jetons de *re-staking* liquides) ont été la vedette de l’écosystème Ethereum lors du précédent cycle. EigenLayer a lancé le récit d’« un seul ETH générant plusieurs couches de rendements », que des protocoles comme Kelp, ether.fi ou Puffer ont industrialisé. Résultat final : les LRT ont été intégrés aux listes blanches de garanties de nombreux protocoles de prêt en tant qu’actifs structurés.
Cette décision repose sur une hypothèse : le mécanisme d’ancrage des LRT serait suffisamment robuste, et les risques liés aux multiples couches d’actifs sous-jacents pourraient être pleinement modélisés et isolés au niveau des contrats intelligents.
L’incident Kelp a percé cette hypothèse en une seule après-midi. Le risque associé aux LRT ne provient pas uniquement des contrats intelligents sous-jacents, mais aussi de leur architecture de distribution interchaînes ; il ne découle pas d’un seul protocole, mais de chaque lien de dépendance reliant Kelp à EigenLayer, LayerZero et Aave. Chaque brique du « Lego DeFi » semble parfaitement sûre prise isolément, mais l’assemblage final multiplie les risques, plutôt que de les additionner.
Dans les mois à venir, tous les protocoles de prêt continuant de classer les LRT comme garanties de haut niveau devront réévaluer leurs paramètres de risque : les plafonds d’offre seront abaissés, les marges de liquidation élargies, et certains protocoles pourraient même retirer purement et simplement les LRT de leurs listes.
La « moat » (avantage concurrentiel durable) du DeFi a toujours été qualifiée de « composable ». Mais cet incident rappelle à tous que la composable est une arme à double tranchant : l’effet réseau dont vous êtes si fiers devient, entre les mains d’un attaquant, un amplificateur.
Cet attaquant avait anticipé sa voie de sortie bien avant même de lancer l’attaque. Il ne s’agissait pas uniquement de vol, mais d’utiliser la composable du DeFi comme une arme. Plus les relations de dépendance entre protocoles sont étroites, plus la richesse de la composable est grande — et plus la surface d’attaque s’élargit, offrant à l’attaquant davantage de « briques financières Lego » à sa disposition.
La sécurité du DeFi demeure, plus que jamais, un chantier immense.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News














