Que pensent les experts techniques de l'incident de piratage de Kelp DAO ?

Auteur : Grvt Deep Research Institute

Au petit matin du 19 avril, le pont inter-chaînes rsETH basé sur LayerZero de Kelp DAO a été piraté, 116 500 rsETH ont été transférés hors du OFTAdapter principal sans aucune trace de destruction correspondante, ce qui équivaut à environ 292 millions de dollars au prix du moment. En une heure, Kelp a rapidement exécuté pauseAll, mais l’attaquant a ensuite lancé deux attaques supplémentaires. Si le contrat n’avait pas été mis en pause, la perte totale aurait frôlé 391 millions de dollars.

Moins d’une journée après l’incident, Aave a gelé les marchés rsETH et wrsETH, le taux d’utilisation des pools clés a atteint 100 %, et les utilisateurs ont eu du mal à retirer ETH, WETH, voire USDT, USDC. Au moins 9 protocoles ont déclenché une réponse d’urgence. C’est le plus grand record de perte unique en DeFi en 2026, après que le protocole Drift ait subi une attaque de 285 millions de dollars il y a trois semaines. La juxtaposition de ces deux incidents soulève une question de plus en plus incontournable dans l’industrie : le cadre de sécurité actuel de la DeFi est-il encore suffisant pour faire face aux menaces d’aujourd’hui ?

Comment l’attaque s’est-elle produite

Pour comprendre cet incident, il faut d’abord saisir l’architecture inter-chaînes de Kelp.

Kelp utilise la norme OFT de LayerZero. La chaîne principale détient via le contrat OFTAdapter le pouvoir de mint et de redeem rsETH, et plus de 20 L2 sont reliés par des contrats OFT standard pour la correspondance. Il n’y a pas de version wrapped pour l’interopérabilité, le mécanisme de règlement est un débit-crédit 1:1 — la destruction sur L2 correspond à la libération sur la chaîne principale, et la chaîne principale verrouille pour mint sur L2.

Le point d’entrée central de ce mécanisme est lzReceive, qui ne doit accepter que des messages inter-chaînes vérifiés par LayerZero. L’attaquant a contourné cette vérification, en falsifiant un message sans trace de destruction source, déclenchant directement la libération de réserve par l’Adapter principal. Absence de débit source, mais crédit cible. La conservation de la masse omnichain est alors brisée.

Le CTO de Cyvers, Meir Dolev, a comparé cette attaque à : « La banque n’a pas de problème, les gardiens sont honnêtes, la serrure fonctionne normalement. Le mensonge est chuchoté directement à la seule personne capable d’ouvrir la porte. » Cette métaphore décrit précisément le problème — ce n’est pas une faille de conception du système, mais une faiblesse dans la chaîne de vérification, un seul point de confiance pouvant être compromis.

Que pensent les experts : une défaillance structurelle prévisible

Kelp a choisi la configuration de sécurité la plus faible autorisée par LayerZero : 1/1 DVN, c’est-à-dire qu’un seul validateur suffit pour valider un message inter-chaînes.

Shalev Keren, co-fondateur de Sodot, société spécialisée en cryptographie, a déclaré lors d’une interview que c’était « une faille unique, peu importe comment le marketing la présente ». Il a ajouté qu’un seul validateur compromis suffit à faire sortir des fonds du pont, et que cette faiblesse ne peut être corrigée par aucun audit ou revue de sécurité. La seule solution est de « supprimer la confiance unilatérale dès la conception ».

Ce qui est encore plus préoccupant, c’est que ce n’est pas une faiblesse découverte après coup. Déjà en janvier 2025, une équipe de développement avait explicitement conseillé sur le forum de gouvernance d’Aave d’étendre à plusieurs validateurs. Quinze mois plus tard, le second validateur n’avait toujours pas été ajouté.

LayerZero a indiqué après coup avoir plusieurs fois exhorté Kelp à passer à une configuration multi-validateurs, et a annoncé qu’il cesserait d’approuver les applications utilisant un seul validateur. Mais cette déclaration soulève une autre question : si le risque était connu, pourquoi le protocole n’a-t-il pas imposé des mesures plus strictes plus tôt, laissant le choix à l’application ?

Ce débat sur la « responsabilité du protocole » versus la « responsabilité de l’application » n’a pas encore de réponse claire. Haoze Qiu, responsable blockchain chez Grvt, a déclaré dans une interview : « Kelp DAO a opté pour une configuration de sécurité de pont avec une redondance insuffisante, ce qui crée un point de défaillance unique dans la vérification. En même temps, LayerZero doit aussi répondre de sa responsabilité, car cette attaque concerne l’infrastructure liée à ses validateurs, même si ce n’est pas une vulnérabilité du protocole central. Dans la DeFi interconnectée, les utilisateurs ne se soucient pas de savoir quelle couche est compromise, ils veulent simplement que le système soit suffisamment robuste pour protéger leurs actifs en cas de crise. »

Comment la contagion s’est-elle produite

Les défaillances techniques ne sont que la première moitié de l’incident. La véritable faille structurelle s’est révélée dans la seconde moitié de l’attaque.

L’attaquant a déposé le rsETH volé dans des plateformes de prêt comme Aave V3, V4, Compound V3, Euler, pour emprunter des actifs réels avec des garanties quasi sans valeur. Sur Aave seul, cela représente environ 196 millions de dollars empruntés, avec une dette totale dépassant 236 millions. Dès leur dépôt, ces garanties ont vidé la réserve principale, rendant impossible leur liquidation normale.

Aave a ensuite gelé ces marchés, provoquant une forte contraction de la liquidité et une vague de retraits dépassant 10 milliards de dollars. Fluid a également gelé le marché rsETH, Upshift a suspendu deux de ses vaults, Lido Earn a suspendu ses dépôts en raison d’une exposition à earnETH sur rsETH, et Ethena a, par précaution, suspendu son pont LayerZero OFT pendant environ six heures.

La propagation de la contagion en quelques heures n’est pas due à une erreur de gestion d’un seul protocole, mais résulte directement de la sur-structuration des garanties LRT — staking, re-staking, déploiement inter-chaînes, emprunt et garantie. Chaque couche supplémentaire repose sur une hypothèse de confiance implicite. Quand la réserve de base est vidée, toute la chaîne s’effondre.

À titre de comparaison, SparkLend avait déjà retiré rsETH de sa liste d’actifs en janvier 2026. Face à LRT, d’autres protocoles ont adopté des stratégies de gestion des risques très différentes. Cette divergence montre que l’industrie n’a pas encore de consensus sur le risque systémique lié aux actifs de type LRT.

Controverse d’attribution : ce que l’on sait et ce que l’on ignore

LayerZero a attribué l’attaque au groupe Lazarus de la North Korea, via sa branche TraderTraitor, en indiquant que les attaques contre Axie Infinity Ronin Bridge et WazirX étaient également liées à cette organisation.

Mais Cyvers, dans une analyse indépendante, n’a pas confirmé cette attribution. Dolev a indiqué que, bien que certains motifs de l’attaque présentent des similitudes avec des opérations connues de la DPRK, aucune preuve concluante ne relie encore des wallets à cette organisation.

Les logiciels malveillants utilisés par l’attaquant ont été automatiquement effacés après l’attaque, rendant la collecte de preuves très difficile.

Les deux sociétés de sécurité ont tiré des conclusions différentes, ce qui met en lumière un problème : le secteur DeFi manque encore de mécanismes systématiques de partage d’informations et de collaboration pour le suivi des attaques. Qui a lancé l’attaque est important, mais comprendre comment elle a été planifiée, exécutée, et comment l’industrie peut renforcer la détection de telles menaces est une priorité.

Comment faire évoluer la gestion de la sécurité

Après cet incident, plusieurs niveaux de discussion ont émergé, qu’il faut prendre au sérieux.

Au niveau de la conception du protocole, la configuration à un seul validateur, déjà autorisée, constitue une vulnérabilité intrinsèque. La décision de LayerZero d’arrêter d’approuver les applications avec un seul validateur est une mesure tardive mais nécessaire. La question fondamentale est : quels seuils et mécanismes doivent être mis en place pour empêcher la dégradation de la sécurité par l’application ?

Au niveau de la gestion des garanties, les protocoles de prêt doivent appliquer des critères d’évaluation plus stricts pour les actifs LRT. La sécurité des ponts inter-chaînes, la traçabilité des réserves, la faisabilité de la liquidation en cas de crise — ces dimensions ont été jusqu’ici souvent basées sur des déclarations des protocoles eux-mêmes, plutôt que sur des vérifications indépendantes. La décision de SparkLend de retirer rsETH trois mois avant l’incident montre qu’une évaluation prudente est possible, à condition d’être prêt à sacrifier une partie du TVL à court terme. Pour les plateformes intégrant des fonds utilisateurs, la surveillance continue, la prise de décision rapide, et l’ajustement proactif des expositions avant que l’incertitude ne se transforme en perte sont essentiels. Grvt a, dans cette affaire, rapidement ajusté ses expositions DeFi après avoir détecté la pression du marché, pour protéger les fonds des utilisateurs.

Au niveau opérationnel, la compromission de la chaîne d’approvisionnement de Drift et la planification préalable de l’attaque contre Kelp montrent que les menaces ne se limitent pas à la couche blockchain. La gestion des clés, les processus internes, la sécurité des dépendances tierces doivent faire partie intégrante du cadre de sécurité du protocole, et non rester dans une zone grise de « bonnes pratiques techniques ».

Au niveau de la coopération sectorielle, la divergence dans l’attribution des attaques montre que le partage d’informations et la standardisation restent faibles. Il faut des mécanismes plus systématiques de partage d’informations entre sociétés de sécurité, équipes de protocoles, et infrastructures, plutôt que des analyses isolées après coup.

Conclusion

Au cours des quatre premiers mois de 2026, les pertes dues aux attaques en DeFi ont frôlé le milliard de dollars. Drift et Kelp ont chacun subi des pertes supérieures à 280 millions, en moins de trois semaines.

Ce n’est pas un « cygne noir » probabiliste, mais un signal clair pour l’industrie : le modèle de menace supposé par le cadre de sécurité actuel ne couvre plus la réalité des attaques modernes.

L’évolution de la gestion de la sécurité en DeFi ne peut pas être l’affaire d’un seul protocole. Elle nécessite que les concepteurs, l’infrastructure, les plateformes de prêt, et la communauté de la sécurité revoient leurs hypothèses de risque, puis trouvent des moyens communs d’améliorer la résilience de l’ensemble de l’écosystème.

Ce dialogue ne fait que commencer.