Comment 292 M$ ont été volés à KelpDAO sans toucher un smart contract ?

292 millions de dollars volés sans toucher à un seul smart contract. Le 18 avril 2026, le protocole de restaking liquide KelpDAO a été vidé via son bridge LayerZero — non pas à cause d'un bug dans Solidity, mais parce qu'un seul vérificateur était suffisant pour approuver les messages cross-chain, et l'attaquant a empoisonné les nœuds RPC que ce vérificateur consultait. En 46 minutes, Kelp a mis le protocole en pause et a évité 200 millions de pertes supplémentaires. Mais le mal était fait : Aave fait face à jusqu'à 230 millions de dettes irrécouvrables, le TVL de la DeFi a chuté de 25 % en quelques heures, et les chercheurs pointent du doigt le même groupe qui a vidé Drift Protocol 17 jours auparavant — le Groupe Lazarus de Corée du Nord. 575 millions de dollars de DeFi en 18 jours, avec deux vecteurs complètement distincts.

Cet article décortique la mécanique de l'exploit, pourquoi la configuration par défaut de LayerZero était une bombe à retardement, qui paie la facture, et ce que cela signifie pour quiconque détient des fonds dans des protocoles utilisant des bridges cross-chain.

Comment 292 millions ont-ils été volés sans exploiter un smart contract ?

À 17h35 UTC le 18 avril, l'attaquant a appelé lzReceive sur le contrat EndpointV2 de LayerZero, ordonnant à l'OFTAdapter de Kelp sur Ethereum de libérer 116 500 rsETH — environ 18 % de l'offre en circulation du token. Aucune destruction correspondante n'a eu lieu sur la chaîne d'origine (Unichain). L'attaquant a fabriqué un faux message cross-chain que le bridge a accepté comme légitime.

Comment ? Ils n'ont pas cassé la cryptographie ni trouvé de bug dans le code. Ils ont empoisonné l'infrastructure :

1. Ils ont obtenu la liste des endpoints RPC que le Decentralized Verifier Network (DVN) de LayerZero consultait pour lire l'état d'Unichain.
2. Ils ont substitué les binaires de deux nœuds indépendants par des versions modifiées qui renvoyaient de fausses données au DVN — mais répondaient correctement aux systèmes de surveillance.
3. Ils ont lancé une attaque DDoS contre les endpoints de secours pour forcer le DVN à utiliser les nœuds empoisonnés.
4. Le malware s'est autodétruit après l'attaque pour effacer les traces forensiques.

La condition qui a rendu cela possible : Kelp utilisait une configuration 1-sur-1 sur son bridge — un seul vérificateur était suffisant pour approuver n'importe quel message cross-chain. Pas de redondance, pas de deuxième vérification. Un point de défaillance unique pour 292 millions.

46 minutes ont-elles suffi pour éviter 200 millions de pertes supplémentaires ?

Le multisig d'urgence de Kelp a exécuté pauseAll à 18h21 UTC — 46 minutes après le drainage. À 18h26 et 18h28, l'attaquant a tenté deux transactions supplémentaires pour drainer 40 000 rsETH chacune (~100 millions par tentative). Les deux ont été annulées car le protocole était déjà en pause.

Si la pause était arrivée 10 minutes plus tard, le vol total aurait atteint 391 millions.

Ce que l'attaquant a fait des fonds

En quelques minutes, 89 567 des 116 500 rsETH volés ont été déposés comme garantie sur Aave V3/V4 via sept portefeuilles. Contre cette garantie, l'attaquant a emprunté 82 650 WETH (190,9 millions) et 821 wstETH (2,3 millions). Certaines estimations portent le total emprunté à 126 000 WETH (236 millions) en ajoutant d'autres protocoles. Le WETH emprunté a été acheminé via Tornado Cash — le même mixer qui avait financé le portefeuille de l'attaquant avec 1 ETH dix heures avant le vol.

Qui paie la facture de 230 millions de dettes irrécouvrables ?

Le vol direct de 292 millions n'est qu'une partie des dégâts. Parce que l'attaquant a converti les rsETH volés en actifs réels empruntés sur des protocoles de prêt, plusieurs plateformes font face à des dettes qui ne peuvent pas être recouvrées :

Les contrats d'Aave n'ont pas été compromis — le fondateur Stani Kulechov a confirmé que le vecteur était entièrement externe. Mais le protocole a subi plus de 5,4 milliards de retraits en quelques heures, poussant les pools de WETH, USDT et USDC à 100 % d'utilisation. Les déposants ont été piégés. Le même schéma que nous avons vu avec USR-Morpho en mars — lorsqu'une garantie se brise, la liquidité du pool s'évapore et les prêteurs ne peuvent pas sortir.

Le token AAVE a chuté de 10 à 18 %. Le TVL de la DeFi a dégringolé de ~110 milliards à ~82,4 milliards — une baisse de 25 % qui reflète une fuite des risques, pas seulement des pertes directes.

La seule récupération significative : le 21 avril, le Conseil de sécurité d'Arbitrum a gelé 30 766 ETH (~71 millions) dans un portefeuille intermédiaire, agissant sur la base d'informations des forces de l'ordre. Cela représente 24 % des fonds volés.

À qui la faute — LayerZero ou KelpDAO ?

La guerre publique entre les deux est importante car elle détermine si les ~47 % des applications intégrées à LayerZero doivent être reconfigurées immédiatement.

LayerZero dit : Kelp a "choisi" la configuration à vérificateur unique. L'exploit est une conséquence directe de cette décision. À partir de maintenant, LayerZero refuse de signer des messages pour les applications qui restent en configuration 1-sur-1.

Kelp répond : la configuration 1-sur-1 était la configuration par défaut documentée de LayerZero. Bien qu'ayant un canal de communication direct ouvert depuis juillet 2024, ils n'ont jamais été spécifiquement avertis qu'ils devaient la modifier.

Des développeurs indépendants ont corroboré la version de Kelp : le fichier de configuration par défaut de LayerZero V2 (layerzero.config.ts) est livré avec une configuration 1-required / 0-optional. Et le DVN compromis était une infrastructure propre à LayerZero Labs, pas un vérificateur tiers.

La lecture honnête : les deux partagent la responsabilité. LayerZero a créé des valeurs par défaut non sécurisées qui rendaient la configuration dangereuse triviale, et un protocole qui gère des milliards aurait dû renforcer sa sécurité au-delà des valeurs par défaut. L'incident révèle que la révision de la configuration des bridges est une discipline de sécurité différente des audits de smart contracts — et une que la plupart des protocoles ont traitée comme une simple case à cocher.

575 millions en 18 jours — que fait le Groupe Lazarus ?

Les chercheurs — y compris l'équipe de Chainalysis et ZachXBT — attribuent préliminairement l'attaque à la sous-unité TraderTraitor du Groupe Lazarus de Corée du Nord. C'est le même groupe lié à :

575 millions de dollars de DeFi en 18 jours avec deux vecteurs structurellement différents. Ce n'est pas un script kiddie qui répète le même tour — c'est une campagne sophistiquée qui identifie les failles entre les systèmes (bridges, gouvernance, oracles) où les audits de code n'atteignent pas.

Chainalysis l'a résumé : "Détecter le code malveillant ne suffit pas ; les protocoles doivent détecter quand un système entre dans un état impossible."

Qu'est-ce que cela signifie pour le restaking et les bridges cross-chain ?

Il n'y a pas de contagion structurelle au secteur LST/LRT plus large. stETH, wstETH, rETH et cbETH ne sont pas affectés. Les dépôts de rsETH sur Ethereum mainnet sont toujours garantis par des positions légitimes sur EigenLayer.

Mais le rsETH bridgeé vers d'autres chaînes fait face à une grave crise de parité : les détenteurs ne peuvent pas savoir si leurs tokens sont garantis, car l'attaquant a injecté 116 500 unités sans garantie dans l'offre en circulation. Kelp n'a pas publié de plan d'allocation des pertes.

La réponse préventive a été immédiate : Lido a mis en pause earnETH, Ethena a mis en pause ses bridges LayerZero pendant 6 heures (sans exposition au rsETH), et plus de 20 protocoles — Ether.fi, Curve, Morpho, Kamino, Lombard, Beefy, Maple, Mantle entre autres — ont temporairement mis en pause leurs bridges LayerZero. SparkLend et Fluid ont gelé les marchés de rsETH.

Que devrait vérifier tout utilisateur de DeFi maintenant ?

1. Avez-vous des tokens bridgeés ? Tout token qui a traversé un bridge (rsETH, mais aussi wETH, USDC bridgeé, etc.) hérite du risque de la configuration du bridge, pas seulement du contrat du token. Un wrapped token sur une L2 peut avoir un profil de risque fondamentalement différent du token natif sur sa chaîne d'origine.
2. Utilisez-vous rsETH comme garantie ? Si vous avez des positions sur Aave, Compound ou Euler avec du rsETH, votre Health Factor dépend maintenant d'un actif dont la garantie est contestée. Surveillez activement.
3. Vos protocoles utilisent-ils des bridges LayerZero ? Vérifiez si l'application utilise une configuration 1-sur-1 ou multisig. Environ 47 % des applications LayerZero étaient dans une configuration vulnérable avant l'attaque.
4. Diversifiez le risque de bridge. Ne concentrez pas l'exposition cross-chain sur un seul fournisseur de bridge. La base de votre pyramide de fragilité ne devrait pas dépendre d'un point de défaillance unique.

L'exploit de Kelp est le premier hack à neuf chiffres dont la cause première est entièrement en dehors de Solidity — dans la sécurité opérationnelle de l'infrastructure off-chain qui alimente un vérificateur de bridge. Pendant cinq ans, l'industrie a renforcé les smart contracts avec des audits, une vérification formelle et des bug bounties. Les attaquants se sont déplacés en amont, vers des couches d'infrastructure où ces défenses ne s'appliquent pas. La configuration par défaut n'est pas une configuration sécurisée à grande échelle — et cette leçon vient de coûter 292 millions de dollars.