Auteur : Zengineer
Compilation : Deep Tide TechFlow
Introduction de Deep Tide : Le 18 avril, Kelp DAO a été victime d'un vol de 292 millions de dollars, constituant le plus grand incident DeFi de 2026 à ce jour. La vulnérabilité ne se trouvait pas dans le code du contrat, mais dans la configuration du nœud de validation 1-sur-1 du pont inter-chaînes LayerZero – un point de défaillance unique permettant de falsifier les messages inter-chaînes. L'auteur avait déjà signalé ce point il y a 12 jours en scannant Kelp avec son outil open source d'audit IA. Cet article revient sur l'attaque dans son intégralité et réfléchit honnêtement aux trois choses que l'outil n'a pas bien faites à l'époque.
Qu'est-ce que Kelp DAO
Kelp DAO est un protocole de restaking liquide construit au-dessus d'EigenLayer. Le mécanisme est le suivant : les utilisateurs déposent de l'ETH ou des jetons de staking liquide (stETH, ETHx) dans le contrat Kelp, qui délègue ensuite les actifs aux nœuds opérateurs d'EigenLayer pour du restaking – fournissant simultanément de la sécurité à plusieurs AVS (Actively Validated Services, Services à Validation Active). En retour, les utilisateurs reçoivent du rsETH comme reçu. Contrairement au restaking direct sur EigenLayer (où les actifs sont verrouillés), le rsETH est liquide – il peut être échangé, utilisé comme collatéral dans des protocoles de prêt comme Aave, ou transféré entre chaînes.
Pour permettre cette liquidité inter-chaînes, Kelp a déployé le rsETH sur plus de 16 chaînes en utilisant la norme OFT (Omnichain Fungible Token, Jeton Fongible Omnichaîne) de LayerZero. Lorsque vous transférez du rsETH d'Ethereum vers une L2, le DVN (Decentralized Verifier Network, Réseau de Vérificateurs Décentralisé) de LayerZero vérifie la légitimité du message inter-chaînes. Cette architecture de pont est au cœur de l'histoire qui suit.
Kelp a été lancé par Amitej Gajjala et Dheeraj Borra (précédemment co-fondateur de Stader Labs), mis en ligne en décembre 2023, avec un TVL pic de 2,09 milliards de dollars, et une gouvernance utilisant une multisignature 6/8 et un délai de mise à niveau des contrats (timelock) de 10 jours. Le jeton de gouvernance KERNEL régit les trois produits : Kelp, Kernel et Gain.
L'incident de vol
Le 18 avril 2026, un attaquant a extrait 116 500 rsETH du pont inter-chaînes de Kelp DAO, d'une valeur d'environ 292 millions de dollars – le plus grand incident d'attaque DeFi à ce jour en 2026. La cause fondamentale n'était pas une vulnérabilité de contrat intelligent, mais un problème de configuration : un paramètre DVN 1-sur-1 (c'est-à-dire un seul nœud de validation, une seule signature suffit), permettant à l'attaquant de falsifier des messages inter-chaînes avec un seul nœud compromis.
Il y a 12 jours, le 6 avril, mon outil open source d'audit de sécurité avait déjà signalé cette surface d'attaque.
Une précision : ce vol représente des pertes réelles pour des personnes réelles. Les déposants de WETH sur Aave qui n'ont jamais touché au rsETH ont vu leurs fonds gelés ; les LPs de multiples protocoles doivent assumer des créances douteuses qu'ils n'ont jamais contractées. Cet article analyse ce qui s'est passé, ce que notre outil a capté – mais le coût réel supporté par les gens est plus important que n'importe quel tableau de notation.
Le rapport complet est disponible sur GitHub, l'horodatage du commit est vérifiable par tous. Parlons de ce que nous avons attrapé, de ce que nous avons manqué, et de ce que cela signifie pour les outils de sécurité DeFi.
46 minutes, DeFi ébranlé
Le 18 avril à 17:35 UTC, l'attaquant a compromis ce nœud de validation DVN isolé, puis l'a fait "approuver" un message inter-chaînes falsifié. L'Endpoint de LayerZero, voyant que le DVN avait validé, a transmis le message via lzReceive au contrat OFT de Kelp – le contrat a exécuté, frappant 116 500 rsETH sur Ethereum mainnet. Le message prétendait que des actifs de garantie de valeur équivalente étaient verrouillés sur une autre chaîne. Ces actifs n'ont jamais existé.
Suivit un processus classique de blanchiment DeFi :
- Déposer le rsETH volé comme collatéral dans Aave V3, Compound V3, Euler
- Emprunter environ 236 millions de dollars en WETH avec ce collatéral sans garantie réelle
- Consolider environ 74 000 ETH, sortir les fonds via Tornado Cash
46 minutes plus tard, à 18:21, la multisignature d'arrêt d'urgence de Kelp a gelé le contrat. L'attaquant a ensuite tenté deux poursuites (chacune de 40 000 rsETH, ~100 millions de dollars) qui ont toutes reverté – cette suspension a bloqué environ 200 millions de dollars supplémentaires.
Mais l'impact reste sévère. Aave V3 a absorbé environ 177 millions de dollars de créances douteuses. Le jeton AAVE a chuté de 10,27%. L'ETH a chuté de 3%. Le taux d'utilisation du WETH sur Aave est instantanément monté à 100%, les déposants se précipitant pour retirer. Le rsETH sur plus de 20 L2 est soudainement devenu un actif à la valeur douteuse.
6 avril, ce que le rapport a capté
Début avril, peu après le vol de 285 millions de dollars du Drift Protocol le 1er avril, j'ai écrit une compétence Claude Code open source crypto-project-security-skill – un cadre d'évaluation des risques architecturaux assisté par IA, utilisant des données publiques (DeFiLlama, GoPlus, Safe API, vérification on-chain) pour évaluer les protocoles DeFi. Ce n'est pas un scanner de code, ni un outil de vérification formelle. L'incident Drift m'a fait comprendre : ce qui cause les plus grosses pertes n'est pas dans le code des smart contracts – mais dans les vulnérabilités de gouvernance, les négligences de configuration, les angles morts architecturaux, que les scanners de code ne voient jamais. J'ai donc un outil qui évalue spécifiquement ces couches : structure de gouvernance, dépendance aux oracles, mécanismes économiques, architecture inter-chaînes, comparant chaque protocole aux modèles d'attaque historiques (Drift, Euler, Ronin, Harmony, Mango).
Le 6 avril, j'ai exécuté un audit complet sur Kelp DAO. Le rapport complet est public sur GitHub, avec un horodatage de commit immuable.
Le rapport a donné à Kelp un score de triage global de 72/100 (risque moyen). Avec le recul, cette note était trop clémente – ces lacunes d'information non résolues sur les messages inter-chaînes auraient dû faire baisser le score. Mais même avec cette évaluation de risque moyen, le rapport a pointé la surface d'attaque qui a été exploitée.
La capture d'écran ci-dessous est le texte original de la section "Lacunes d'information" du rapport – cette question sur la configuration DVN de Kelp est devenue la cause racine du vol de 292 M$ :
Légende : Chapitre "Lacunes d'information" du rapport du 6 avril, l'opacité de la configuration DVN est directement mentionnée
Détaillons point par point ce que le rapport a marqué et comment cela a été exploité.
Découverte 1 :Opacité de la configuration DVN(Signal d'alerte)
Texte original du rapport : « La configuration LayerZero DVN (ensemble de validateurs par chaîne, exigences de seuil) n'est pas divulguée publiquement »
Ce qui s'est réellement passé : Kelp utilisait une configuration DVN 1-sur-1. Un nœud. Un point unique. L'attaquant a compromis ce seul nœud et a falsifié le message inter-chaînes. Si la configuration avait été 2-sur-3 (minimum recommandé par l'industrie), l'attaquant aurait dû compromettre simultanément plusieurs validateurs indépendants.
Précisons une chose : c'est un problème de Kelp, pas de LayerZero. LayerZero est une infrastructure – il fournit le cadre DVN, chaque protocole choisit sa configuration : combien de nœuds validateurs (1-sur-1, 2-sur-3, 3-sur-5...), quels nœuds utiliser, quels seuils par chaîne. Kelp a choisi 1-sur-1 lors du déploiement du pont OFT. LayerZero supporte pleinement 2-sur-3 ou plus – Kelp ne l'a simplement pas activé.
Une analogie : AWS propose la MFA (Authentification Multi-Facteurs). Si votre compte est piraté parce que vous n'avez jamais activé la MFA, c'est votre problème, pas celui d'AWS. LayerZero met les mécanismes de sécurité à disposition, Kelp ne les a pas utilisés.
Notre rapport n'a pas pu déterminer le seuil DVN spécifique (car Kelp ne l'a jamais divulgué), mais nous avons clairement listé cette opacité comme une lacune d'information non résolue et un élément à risque. Le refus de divulguer est en soi un drapeau rouge.
Découverte 2 :Point de défaillance unique sur 16 chaînes(Impact direct)
Texte original du rapport : « Un point de défaillance unique du DVN LayerZero pourrait affecter simultanément le rsETH sur les 16 chaînes supportées »
Ce qui s'est réellement passé : Le message falsifié a directement touché Ethereum mainnet, l'onde de choc s'est propagée à toutes les chaînes où le rsETH était déployé. LayerZero a préventivement suspendu tous les ponts OFT sortants d'Ethereum. Les détenteurs de rsETH sur plus de 20 L2 ont vu la valeur de leurs jetons devenir douteuse du jour au lendemain.
C'est le risque systémique du déploiement multi-chaînes : le rsETH circule simultanément sur Arbitrum, Optimism, Base, Scroll et d'autres L2, mais la valeur de tous ces jetons provient des actifs sur Ethereum mainnet. Le pont principal compromis, le rsETH sur chaque L2 perd simultanément sa garantie – les détenteurs ne peuvent ni le racheter, ni vérifier si leur jeton a encore de la valeur. L'earnETH de Lido (exposition au rsETH), le pont LayerZero d'Ethena – tous ont été forcés de suspendre. Le rayon d'explosion a dépassé Kelp lui-même.
Découverte 3 :Contrôle de gouvernance inter-chaînes non vérifié(Problème connexe)
Texte original du rapport : « Le contrôle de gouvernance sur la configuration OFT LayerZero de chaque chaîne n'est pas vérifié – en particulier : ces contrôles relèvent-ils de la même multisignature 6/8 et du même timelock de 10 jours, ou sont-ils gérés par des clés admin indépendantes »
Ce qui s'est réellement passé : La configuration DVN n'était clairement pas sous la stricte gouvernance du protocole central. Si les changements de configuration du pont étaient également gérés par la multisignature 6/8 et le timelock de 10 jours, un paramètre DVN 1-sur-1 aurait nécessité l'accord de 6 signataires sur 8 – une telle configuration n'aurait probablement pas persisté sans être remarquée.
Cela expose un angle mort courant de gouvernance : de nombreux protocoles imposent une multisignature stricte et un timelock pour les mises à niveau des contrats centraux, mais pour les modifications opérationnelles – configuration des ponts, paramètres des oracles, gestion des listes blanches – souvent une seule clé admin peut les modifier. La gouvernance centrale de Kelp était leader de l'industrie (multisignature 6/8 + timelock 10 jours), mais ces protections ne s'étendaient pas à sa plus grande surface d'attaque : le pont inter-chaînes.
Découverte 4 :Correspondance avec le modèle d'attaque Ronin/Harmony(Impact direct)
Texte original du rapport : « Les précédents historiques les plus pertinents concernent la sécurité des ponts. Le déploiement de Kelp sur 16 chaînes via LayerZero introduit une complexité opérationnelle similaire à l'architecture multi-chaînes de Ronin »
Ce qui s'est réellement passé : Le chemin d'attaque a presque parfaitement répliqué le scénario Ronin – compromettre le validateur du pont, falsifier un message, vider les actifs. Le module de correspondance des modèles d'attaque de notre outil, qui compare l'architecture du protocole aux catégories d'attaques historiques, a correctement identifié ceci comme le vecteur d'attaque le plus risqué.
Contexte historique : En 2022, le pont Ronin a perdu 625 millions de dollars après que 5 (sur 9) validateurs aient été compromis ; la même année, le pont Horizon d'Harmony a perdu 100 millions de dollars après que 2 (sur 5) validateurs aient été compromis. La situation de Kelp était plus extrême – un seul validateur, abaissant le seuil d'attaque au minimum absolu. L'outil a pu marquer ce risque car il compare automatiquement l'architecture du protocole à ces modèles d'attaque historiques, au lieu de se concentrer uniquement sur le code.
Découverte 5 :Aucun pool d'assurance(A amplifié les pertes)
Texte original du rapport : « Le protocole n'a actuellement pas de pool d'assurance dédié, ni de mécanisme de socialisation des pertes pour absorber les événements de slashing »
Ce qui s'est réellement passé : Sans réserve d'assurance, la perte de 292 millions de dollars a été entièrement absorbée par les protocoles en aval. La réserve de recouvrement d'Aave couvre moins de 30% de ses 177 millions de dollars de créances douteuses. Les LPs n'ayant aucun lien avec les décisions de configuration du pont de Kelp – ont supporté le plus gros du choc.
L'attaquant a déposé le rsETH volé comme collatéral dans Aave V3, Compound V3, Euler, puis a emprunté du vrai WETH. Une fois le rsETH confirmé sans garantie, ces positions sont devenues des créances douteuses « impossible à liquider » – le collatéral est devenu sans valeur, mais le WETH emprunté avait disparu. Le taux d'utilisation du WETH sur Aave a instantanément atteint 100%, les utilisateurs ordinaires ne pouvant même pas retirer leurs fonds. Si vous étiez déposant de WETH sur Aave, même sans jamais avoir touché au rsETH, vos fonds étaient affectés. Le partenariat d'assurance de Kelp avec Nexus Mutual ne couvrait que des produits de vault spécifiques, pas l'exposition au protocole rsETH central.
C'est un échec des responsabilités des deux côtés. Côté Kelp : un protocole gérant 1,3 milliard de dollars de TVL, zéro pool d'assurance, zéro mécanisme d'absorption des pertes. Lorsque le pont a été compromis, aucun tampon n'a pu absorber le choc. Côté Aave : accepter le rsETH comme collatéral, mais sans évaluer pleinement les risques de configuration de son pont inter-chaînes. Les paramètres de risque d'Aave (LTV, seuil de liquidation) étaient conçus pour une volatilité normale des prix, mais pas pour le risque de queue où « la configuration du pont est compromise, rendant le collatéral sans valeur du jour au lendemain ». La réserve de recouvrement couvre à peine 30% des créances douteuses. Essentiellement, c'était un échec de tarification du risque : Aave a traité le rsETH comme un actif à volatilité normale, mais il comportait en réalité un risque de queue binaire d'échec du pont. Les échecs des deux côtés se sont additionnés – Kelp n'avait pas d'assurance pour empêcher l'entrée de mauvais collatéral dans le système, Aave n'a pas fait une modélisation des risques assez fine pour limiter l'exposition dans un tel scénario.
Ce que nous avons fait de travers
Trois choses auraient pu être mieux faites :
Évaluation des risques trop basse. Nous avons évalué le risque du pont inter-chaînes comme « moyen ». Le rapport comportait 5 lacunes d'information non résolues, dont 3 liées à la configuration du pont LayerZero, correspondant en plus aux modèles d'attaque historiques de Ronin/Harmony – cela aurait dû être « élevé » ou « critique ». L'opacité elle-même aurait dû être un signal plus fort.
Nous n'avons pas percé la couche de configuration. Le rapport demandait à plusieurs reprises à Kelp de divulguer le seuil DVN, mais nous n'avons pas pu le vérifier indépendamment. C'est exactement le même angle mort structurel pointé par l'analyse post-mortem de 鉅亨網 : les outils d'audit existants se concentrent sur la logique du code, ils ne capturent pas les risques au niveau de la configuration. Nous avons signalé le problème, mais n'avons pas pu y répondre.
Nous n'avons pas vérifié on-chain. La configuration DVN pouvait en fait être lue directement on-chain via le contrat EndpointV2 de LayerZero. Nous aurions pu interroger le registre ULN302 pour vérifier indépendamment le seuil DVN de Kelp, au lieu de le marquer comme « non divulgué publiquement ». Si nous l'avions fait, nous aurions directement vu la configuration 1-sur-1, sans même besoin que Kelp divulgue. C'est la direction d'amélioration la plus concrète pour l'outil : ajouter une vérification on-chain de la configuration DVN dans les étapes d'évaluation inter-chaînes.
Les découvertes n'étaient pas assez spécifiques, pas assez actionnables. Dire « Configuration DVN non divulguée » est une observation d'un manque de documentation – pas une prédiction d'attaque. Ces risques (centralisation des oracles, dépendance aux ponts, manque d'assurance) sont en fait tout aussi répandus dans la plupart des protocoles DeFi inter-chaînes. L'outil a signalé l'opacité de Kelp, mais il l'a aussi fait pour des douzaines d'autres protocoles non attaqués avec des modèles similaires. Sans taux de faux positifs publié, affirmer « nous avons prédit cela » est exagéré. Une déclaration plus honnête est : nous avons posé certaines des bonnes questions que personne ne posait, et l'une d'elles a touché un point de défaillance critique.
À propos de la « divulgation responsable »
Une question légitime : si nous avions marqué ces risques le 6 avril, pourquoi n'avons-nous pas contacté Kelp avant l'attaque du 18 avril ?
Nous ne l'avons pas fait. La raison : le rapport identifiait une opacité – « Configuration DVN non divulguée », pas une vulnérabilité exploitable spécifique. Nous ne savions pas que la configuration était 1-sur-1, nous savions seulement qu'elle n'était pas publique. Rien d'assez concret pour une divulgation. « Votre configuration de pont n'est pas documentée » est une observation de gouvernance, pas un rapport adapté à un programme de bug bounty.
Avec le recul, nous aurions pu contacter l'équipe Kelp directement, leur demander leur seuil DVN. Cette conversation aurait pu exposer la configuration 1-sur-1 et conduire à une correction. Nous ne l'avons pas fait. C'est une leçon : même si une découverte semble trop floue pour un processus de divulgation formel, envoyer un message privé pour demander des clarifications vaut le coup.
Ce que cela signifie pour la sécurité DeFi
Le vol de Kelp – comme celui de Drift 17 jours plus tôt – n'était pas une vulnérabilité de contrat intelligent. Les scanners de code automatisés comme Slither, Mythril, ou même GoPlus n'auraient rien capté. La vulnérabilité était cachée dans la configuration de déploiement, les lacunes de gouvernance, les décisions architecturales, situées au-dessus de la couche code.
C'est aussi le postulat central de crypto-project-security-skill :
La sécurité d'un protocole ne se limite pas à la sécurité du code. Un protocole peut avoir un Solidity parfait, cinq audits de sociétés leaders, un programme de bug bounty de 250 000 $ – et se faire voler 292 millions de dollars à cause d'un problème de configuration des validateurs de pont.
L'outil est open source sur GitHub – n'importe qui peut examiner la méthodologie, l'exécuter lui-même, ou l'améliorer.
Chronologie
12 jours. Le signal était déjà là. La question est : comment l'écosystème peut-il construire des outils capables de voir ces signaux avant que le prochain pont ne s'effondre.
Ce que vous pouvez faire
Si vous avez des actifs dans un protocole DeFi avec un pont inter-chaînes :
- Exécutez vous-même un audit. L'outil est open source. Ne nous croyez pas sur parole – vérifiez par vous-même.
- Vérifiez la configuration des validateurs du pont. Si un protocole refuse de divulguer son seuil DVN, considérez-le comme un drapeau rouge. Notre rapport l'a fait, et cela s'est avéré correct.
- Ne présumez pas que les audits de code couvrent tout. Kelp avait plus de 5 audits de code par des sociétés et plateformes réputées (Code4rena, SigmaPrime, MixBytes). Les audits de code traditionnels ne sont pas conçus pour capturer des risques au niveau de la configuration comme le paramètre de seuil DVN – c'est un autre type d'analyse, pas une faute de l'auditeur.
- Évaluez la couverture d'assurance. Si un protocole n'a pas de pool d'assurance, et que vous êtes un LP sur une plateforme de prêt acceptant son jeton comme collatéral, vous assurez implicitement pour lui. Les déposants de WETH sur Aave l'ont appris de la manière la plus dure cette fois.
Image plus large : L'Agent IA comme couche de sécurité
Cet article parle d'un outil et d'un vol. Mais l'affirmation sous-jacente est plus large : Les Agents IA peuvent devenir une couche de sécurité indépendante pour les investisseurs DeFi.
Le modèle de sécurité traditionnel de l'industrie crypto est le suivant : le protocole engage un auditeur, l'auditeur examine le code, l'auditeur publie un rapport. Ce modèle a des angles morts – l'incident Kelp le démontre, il se concentre sur l'exactitude du code, mais rate les risques de configuration, de gouvernance, d'architecture.
Claude Code et ce type d'outils de compétences offrent un autre chemin : n'importe qui peut utiliser des données publiques pour exécuter une évaluation des risques assistée par IA sur n'importe quel protocole en quelques minutes. Vous n'avez pas besoin de dépenser 200 000 $ pour un auditeur. Vous n'avez pas besoin de savoir lire le Solidity. Vous demandez à l'agent de comparer l'architecture du protocole aux modèles d'attaque connus, et il vous présente les questions que vous devriez vous poser avant de déposer des fonds.
Cela ne remplace pas un audit professionnel – mais cela abaisse le seuil de la diligence de première couche à un niveau accessible à tous. Un LP envisageant d'injecter des fonds dans un nouveau protocole de restaking peut maintenant exécuter une commande audit defi
Le rapport sur Kelp n'était pas parfait. Il a évalué le risque du pont comme moyen, il aurait dû être critique. Il n'a pas percé la couche de configuration. Mais il a posé les bonnes questions – si l'équipe Kelp ou n'importe quel LP les avait prises au sérieux à l'époque, la perte de 292 millions de dollars aurait pu être évitée.
