Un outil d'IA open source que personne ne regarde a alerté il y a 12 jours sur la faille de 292 millions de dollars de Kelp DAO

Auteur : Zengineer

Traduction : Deep潮 TechFlow

Deep潮 Introduction : Le 18 avril, Kelp DAO a été victime d’un vol de 292 millions de dollars, la plus grande attaque DeFi à ce jour en 2026. La faille ne se trouve pas dans le code du contrat intelligent, mais dans la configuration du nœud de validation LayerZero cross-chain 1-of-1 — une seule défaillance peut permettre de falsifier un message cross-chain. Il y a 12 jours, lors du scan de Kelp avec mon outil d’audit open source basé sur l’IA, j’avais déjà identifié ce point de risque. Cet article revient sur le processus de l’attaque et réfléchit honnêtement aux trois erreurs que notre outil n’a pas faites à l’époque.

Qu’est-ce que Kelp DAO

Kelp DAO est un protocole de staking liquide construit sur EigenLayer. Le mécanisme est le suivant : l’utilisateur dépose des ETH ou des tokens de staking liquide (stETH, ETHx) dans le contrat Kelp, qui délègue ensuite ces actifs à un nœud opérateur d’EigenLayer pour le staking redéployé — tout en fournissant la sécurité à plusieurs AVS (Actively Validated Services, services de validation actifs). En retour, l’utilisateur reçoit rsETH comme preuve. Contrairement au staking direct sur EigenLayer (où les actifs sont verrouillés), rsETH est liquide — il peut être échangé, utilisé comme collatéral dans des protocoles de prêt comme Aave, ou transféré cross-chain.

Pour réaliser cette liquidité cross-chain, Kelp utilise la norme OFT (Omnichain Fungible Token, jeton fongible omnichaîne) de LayerZero, déployée sur plus de 16 chaînes. Lorsque vous transférez rsETH d’Ethereum vers une couche L2, le DVN (Decentralized Verifier Network, réseau de vérification décentralisé) de LayerZero vérifie la légitimité du message cross-chain. Cette architecture de pont est au cœur de l’histoire suivante.

Kelp a été lancé par Amitej Gajjala et Dheeraj Borra (ancien co-fondateur de Stader Labs), en décembre 2023, avec un TVL culminant à 2,09 milliards de dollars. La gouvernance est assurée par un multi-signature 6/8 avec un verrouillage de 10 jours pour les mises à jour du contrat. Le token de gouvernance KERNEL contrôle les trois lignes de produits : Kelp, Kernel, Gain.

L’incident de vol

Le 18 avril 2026, un attaquant a extrait 116 500 rsETH du pont cross-chain de Kelp DAO, équivalent à environ 292 millions de dollars — la plus grande attaque DeFi en 2026. La cause principale n’est pas une faille dans le code du contrat, mais un problème de configuration : une configuration DVN 1-of-1 (un seul nœud de validation, avec une seule signature) permettant à un attaquant, en compromettant un seul nœud, de falsifier un message cross-chain.

Il y a 12 jours, le 6 avril, mon outil d’audit open source basé sur l’IA avait déjà identifié cette surface de risque.

Pour clarifier : ce vol est le résultat d’une action humaine réelle, avec de vraies pertes. Des déposants sur Aave WETH n’ayant jamais touché à rsETH ont vu leurs fonds gelés ; plusieurs LP dans différents protocoles ont dû supporter des pertes qu’ils n’avaient pas signées. Cet article analyse ce qui s’est passé, ce que notre outil a détecté — mais le coût réel pour les victimes dépasse tout score de risque.

Le rapport complet est disponible sur GitHub, avec un timestamp immuable. Nous allons voir ce que nous avons détecté, ce que nous avons manqué, et ce que cette affaire signifie pour les outils de sécurité DeFi.

46 minutes, tremblement dans la DeFi

À 17h35 UTC, le 18 avril, l’attaquant a compromis le nœud DVN isolé, puis lui a fait « approuver » un message falsifié. L’endpoint LayerZero a vu que le DVN avait validé, et a transmis le message via lzReceive au contrat OFT de Kelp — qui a alors, sur le réseau principal Ethereum, frappé 116 500 rsETH. Le message prétendait que d’autres chaînes avaient verrouillé des actifs équivalents en garantie. Or, ces actifs n’ont jamais existé.

Voici la suite du processus classique de blanchiment DeFi :

• Utiliser les rsETH volés comme collatéral dans Aave V3, Compound V3, Euler
• Emprunter environ 236 millions de dollars en WETH avec ces collatéraux sans véritable garantie
• Concentrer environ 74 000 ETH, puis retirer via Tornado Cash

Après 46 minutes, à 18h21, Kelp a activé une suspension d’urgence multi-signature pour geler le contrat. L’attaquant a ensuite lancé deux nouvelles attaques (chacune de 40 000 rsETH, soit environ 100 millions de dollars), qui ont toutes été annulées — cette suspension a empêché la perte d’environ 200 millions de dollars.

Mais l’impact est massif : environ 177 millions de dollars de pertes ont été absorbés par Aave V3. Le token AAVE a chuté de 10,27 %. ETH a baissé de 3 %. L’utilisation de WETH sur Aave a atteint 100 %, les déposants ont commencé à retirer en masse. Sur plus de 20 L2, tous les rsETH sont devenus des actifs à valeur douteuse du jour au lendemain.

Ce que le rapport du 6 avril a révélé

Au début avril, peu après le vol de 285 millions de dollars par Drift le 1er avril, j’ai créé un cadre d’évaluation des risques basé sur l’IA, appelé crypto-project-security-skill — utilisant des données publiques (DeFiLlama, GoPlus, Safe API, vérifications on-chain) pour analyser la sécurité des protocoles DeFi. Ce n’est pas un scanner de code ni un outil de vérification formelle. L’incident Drift m’a montré que la cause principale des pertes importantes ne réside pas dans le code du contrat, mais dans des vulnérabilités de gouvernance, des erreurs de configuration, des failles d’architecture — des aspects que les scanners ne peuvent pas voir. J’ai donc développé un outil spécifique pour évaluer ces couches : gouvernance, dépendance aux oracles, mécanismes économiques, architecture cross-chain, en comparant chaque protocole aux attaques historiques (Drift, Euler, Ronin, Harmony, Mango).

Le 6 avril, j’ai effectué un audit complet de Kelp DAO. Le rapport complet est publié sur GitHub, avec un timestamp immuable.

La note globale donnée à Kelp est de 72/100 (risque modéré). En rétrospective, cette note était trop généreuse — notamment parce que les lacunes dans la communication cross-chain auraient dû faire baisser la note. Même avec une évaluation modérée, le rapport a mis en évidence la vulnérabilité exploitée.

Voici une capture d’écran de la section « lacunes d’information » du rapport — concernant la configuration DVN de Kelp, qui a finalement été la cause du vol de 292 millions de dollars :

Légende : La section « lacunes d’information » du rapport du 6 avril mentionne explicitement la configuration opaque du DVN

Voici une analyse point par point de ce que le rapport a identifié, et comment cela a été exploité.

Découverte 1 : Configuration DVN opaque (signal d’alerte)

Texte du rapport : « La configuration du DVN LayerZero (ensemble des validateurs par chaîne, seuils requis) n’est pas divulguée »

Ce qui s’est réellement passé : Kelp a utilisé une configuration DVN 1-of-1. Un seul nœud. Un point unique de défaillance. Si un attaquant parvient à compromettre ce nœud, il peut falsifier un message cross-chain. Si la configuration était 2-of-3 (recommandation minimale de l’industrie), il faudrait compromettre plusieurs validateurs indépendants.

Pour clarifier : ce problème vient de Kelp, pas de LayerZero. LayerZero fournit l’infrastructure — chaque protocole choisit sa configuration : combien de validateurs (1-of-1, 2-of-3, 3-of-5…), qui sont ces validateurs, quels seuils par chaîne. Lors du déploiement de l’bridge OFT, Kelp a choisi 1-of-1. LayerZero supporte totalement 2-of-3 ou plus — c’est Kelp qui n’a pas activé cette option.

Exemple : AWS propose MFA (authentification multi-facteurs). Si votre compte est piraté parce que vous n’avez pas activé MFA, c’est votre problème, pas celui d’AWS. LayerZero fournit la sécurité, Kelp ne l’a pas utilisée.

Notre rapport n’a pas pu confirmer le seuil exact du DVN (Kelp ne l’a jamais divulgué), mais nous avons clairement listé cette opacité comme une lacune d’information et un risque non résolu. Le fait de ne pas divulguer est en soi un signal d’alerte.

Découverte 2 : Risque de défaillance d’un seul point sur 16 chaînes (impact direct)

Texte du rapport : « La défaillance d’un seul point du DVN LayerZero pourrait affecter simultanément 16 chaînes supportées pour rsETH »

Ce qui s’est réellement passé : un message falsifié a été directement accepté par le réseau principal Ethereum, ce qui a provoqué une réaction en chaîne sur toutes les chaînes déployant rsETH. LayerZero a préventivement suspendu tous les ponts OFT sortant d’Ethereum. Les détenteurs de rsETH sur plus de 20 L2 ont vu leur actif perdre toute garantie en une nuit.

C’est un risque systémique multi-chaînes : rsETH circule sur Arbitrum, Optimism, Base, Scroll, etc., mais leur valeur repose toutes sur l’actif d’Ethereum. Si le pont principal est compromis, tous ces rsETH perdent leur garantie simultanément — les détenteurs ne peuvent ni racheter ni vérifier la valeur de leur token. Les protocoles comme Lido (earnETH) ou Ethena (LayerZero bridge) ont dû suspendre leurs activités. La portée de l’impact dépasse largement Kelp.

Découverte 3 : Contrôle de gouvernance cross-chain non vérifié (questionnement)

Texte du rapport : « La gouvernance du contrôle du paramètre du DVN LayerZero sur chaque chaîne n’est pas vérifiée — notamment : ces contrôles appartiennent-ils au même multi-signature 6/8 avec verrouillage de 10 jours, ou à des clés de gestion indépendantes ? »

Ce qui s’est réellement passé : la configuration du DVN n’est pas sous la gouvernance stricte du protocole principal. Si la modification de la configuration du pont est aussi sous contrôle multi-signature 6/8 avec verrouillage de 10 jours, alors une configuration 1-of-1 nécessite 6 signatures sur 8 — ce qui est peu probable qu’elle reste sans gestion.

Cela révèle une faille courante en gouvernance : beaucoup de protocoles ont une gouvernance rigoureuse pour la mise à jour du contrat principal, mais pour la gestion opérationnelle — configuration du pont, paramètres oracle, gestion des whitelist — souvent seul une clé admin peut intervenir. La gouvernance de Kelp est parmi les plus avancées (multi-signature 6/8 + verrouillage 10 jours), mais ces protections ne s’étendent pas à la plus grande vulnérabilité : le pont cross-chain.

Découverte 4 : Mode d’attaque similaire à Ronin/Harmony (impact direct)

Texte du rapport : « La menace la plus proche dans l’histoire concerne la sécurité des ponts. La déploiement LayerZero de Kelp sur 16 chaînes, avec sa complexité opérationnelle, ressemble à celle de Ronin. »

Ce qui s’est réellement passé : l’attaque a presque parfaitement reproduit le scénario Ronin — compromis des validateurs du pont, falsification de messages, extraction d’actifs. Notre module de détection d’attaques a identifié ce vecteur comme étant à haut risque, en comparant la structure du protocole aux attaques historiques.

Contexte historique : en 2022, le pont Ronin a perdu 625 millions de dollars après que 5 validateurs (sur 9) aient été compromis ; la même année, le pont Horizon de Harmony a perdu 100 millions après la compromission de 2 validateurs (sur 5). La situation de Kelp est encore plus critique — avec un seul validateur, le seuil d’attaque est au minimum. Notre outil a pu repérer ce risque car il compare automatiquement la structure du protocole à ces attaques passées, pas seulement le code.

Découverte 5 : Absence de pool d’assurance (amplification des pertes)

Texte du rapport : « Le protocole ne dispose pas de pool d’assurance dédié, ni de mécanisme de partage social des pertes pour absorber les pénalités. »

Ce qui s’est réellement passé : faute d’assurance, la perte de 292 millions de dollars a été entièrement supportée par les protocoles en aval. La réserve de récupération d’Aave couvre moins de 30 % de la perte de 177 millions de dollars. Les LP qui n’ont pas signé d’accord avec Kelp ont supporté la majorité du choc.

L’attaquant a utilisé les rsETH volés comme collatéral dans Aave V3, Compound V3, Euler, puis a emprunté du WETH réel. Si rsETH n’est plus garanti, ces positions deviennent des « mauvaises dettes non liquidables » — le collatéral devient sans valeur, mais le WETH emprunté est perdu. Le taux d’utilisation de WETH sur Aave a atteint 100 %, rendant impossible tout retrait pour les déposants. Même si vous n’avez jamais touché à rsETH, votre dépôt WETH sur Aave est affecté. Les assurances de Kelp et Nexus Mutual ne couvrent que certains produits, pas l’exposition principale à rsETH.

C’est une double défaillance : d’un côté, Kelp, qui gère 1,3 milliard de dollars TVL, n’a pas d’assurance ni de mécanisme de gestion des pertes ; de l’autre, Aave accepte rsETH comme collatéral sans évaluer le risque de configuration du pont. Les paramètres de risque (LTV, seuils de liquidation) sont conçus pour des fluctuations normales, pas pour un scénario où le pont est compromis du jour au lendemain. La réserve de récupération ne couvre pas 30 % des pertes — une erreur de tarification du risque. En somme, la gestion du risque a échoué : Aave traite rsETH comme un actif normal, alors qu’il comporte un risque tail lié à la faille du pont. La combinaison de ces deux défaillances a permis le vol : absence d’assurance côté Kelp, modélisation insuffisante côté Aave.

Nos erreurs

Trois choses auraient dû être mieux faites :

1. Évaluation du risque sous-estimée. Nous avons classé le risque du pont cross-chain comme « modéré ». Or, dans le rapport, 3 des 5 lacunes d’information non résolues concernent la configuration du LayerZero, et correspondent aux attaques historiques Ronin/Harmony — cela aurait dû faire passer la note à « élevé » ou « critique ». L’opacité elle-même doit être un signal fort.

2. Nous n’avons pas pu pénétrer la couche de configuration. Le rapport demandait à Kelp de divulguer le seuil DVN, mais nous ne pouvions pas le vérifier indépendamment. C’est le même problème que l’analyse post-mortem de 鉅亨網 : les outils d’audit classiques se concentrent sur la logique du code, pas sur la configuration. Nous avons identifié le problème, mais pas la solution.

3. Nous n’avons pas vérifié on-chain. La configuration du DVN peut être lue directement via le contrat LayerZero EndpointV2. Nous aurions pu consulter le registre ULN302 pour vérifier le seuil DVN de Kelp, au lieu de le supposer « non divulgué ». Si nous avions fait cette vérification, nous aurions vu la configuration 1-of-1 sans même que Kelp la divulgue. La meilleure amélioration pour nos outils serait d’intégrer la vérification on-chain de la configuration DVN dans l’évaluation cross-chain.

Nos analyses manquaient de précision et d’action concrète. Dire « la configuration DVN n’est pas divulguée » est une observation documentaire, pas une prédiction d’attaque. Ces risques (centralisation des oracles, dépendance au pont, absence d’assurance) sont courants dans beaucoup de protocoles cross-chain. Notre outil a repéré l’opacité de Kelp, mais il a aussi repéré des patterns similaires dans d’autres protocoles non attaqués. Sans taux de faux positifs, affirmer « nous avions prévu » serait exagéré. La vérité, c’est que nous avons posé des bonnes questions, dont une a touché un point critique.

Sur la « divulgation responsable »

Une question légitime : si nous avions identifié ces risques dès le 6 avril, pourquoi n’avons-nous pas alerté Kelp avant l’attaque du 18 avril ?

Nous n’avons pas alerté. La raison : notre rapport pointait une opacité — « configuration DVN non divulguée » — pas une vulnérabilité exploitable précise. Nous ne savions pas si la configuration était 1-of-1 ou autre chose. Il n’y avait rien à divulguer concrètement. « L’absence de documentation sur la configuration du pont » est une observation de gouvernance, pas un bug à corriger.

Rétrospectivement, nous aurions pu contacter directement l’équipe Kelp pour leur demander leur seuil DVN. Cette discussion aurait pu révéler la configuration 1-of-1 et encourager une correction. Nous ne l’avons pas fait. C’est une leçon : même si une découverte semble trop vague pour une divulgation officielle, un message privé vaut la peine.

Ce que cette affaire signifie pour la sécurité DeFi

Kelp, comme Drift 17 jours plus tôt, n’est pas victime d’un bug dans le contrat. Des outils automatiques comme Slither, Mythril, ou GoPlus ne peuvent pas détecter cette faille. La vulnérabilité réside dans la configuration déployée, la gouvernance, l’architecture — au-dessus du code.

C’est aussi la philosophie de crypto-project-security-skill :

La sécurité d’un protocole ne se limite pas au code. Même avec un code Solidity parfait, cinq audits de top-tier, et une prime de 250 000 dollars, il peut être volé si la configuration du pont est mal gérée.

Notre outil est open source sur GitHub — tout le monde peut examiner la méthodologie, l’exécuter, ou l’améliorer.

Chronologie

12 jours. Le signal était là depuis le début. La question : comment faire en sorte que l’écosystème construise des outils capables de repérer ces signaux avant qu’un pont ne tombe ?

Ce que vous pouvez faire

Si vous détenez des actifs dans un protocole DeFi avec un pont cross-chain :

• Faites votre propre audit. L’outil est open source. Vérifiez par vous-même.
• Vérifiez la configuration du pont. Si un protocole ne veut pas divulguer son seuil DVN, cela doit alerter. Notre rapport le montre, et c’est un bon indicateur.
• Ne pensez pas que l’audit de code suffit. Kelp a subi plus de 5 audits par des acteurs reconnus (Code4rena, SigmaPrime, MixBytes). La vérification de la configuration du DVN n’est pas dans leur scope habituel — c’est une autre catégorie d’analyse.
• Évaluez la couverture d’assurance. Si un protocole n’a pas de pool d’assurance, et que vous utilisez ses tokens comme collatéral, vous êtes implicitement en train de l’assurer. La perte de Kelp aurait pu être évitée si une assurance suffisante avait été en place.

Une vision plus large : l’agent IA comme couche de sécurité

Cet article parle d’un outil et d’un vol. Mais la vraie idée, c’est que l’agent IA peut devenir une couche de sécurité indépendante pour les investisseurs DeFi.

Le modèle traditionnel : protocoles embauchent des auditeurs, qui vérifient le code, puis publient un rapport. Ce modèle a ses limites — l’incident Kelp le montre : il se concentre sur la correction du code, mais ignore la gouvernance, la configuration, l’architecture.

Claude Code et d’autres outils de ce type proposent une autre voie : tout le monde peut utiliser des données publiques pour faire une évaluation de risque IA en quelques minutes. Pas besoin de dépenser 200 000 dollars en audit. Pas besoin de savoir lire Solidity. L’agent compare la structure du protocole aux attaques connues, et vous pose les bonnes questions à poser avant d’investir.

Cela ne remplacera pas l’audit professionnel — mais cela réduit la barrière pour la diligence raisonnable initiale. Un LP qui envisage d’investir dans un nouveau protocole de staking liquide peut lancer une évaluation structurée, couvrant gouvernance, oracles, ponts, mécanismes économiques. Pour les investisseurs particuliers et intermédiaires, c’est une vraie révolution pour leur auto-protection.

Le rapport de Kelp n’est pas parfait. Il a classé le risque de pont comme « modéré », alors qu’il aurait dû être « critique ». Il n’a pas pénétré la couche de configuration. Mais il a posé les bonnes questions — si l’équipe Kelp ou tout autre LP avait pris ces questions au sérieux, la perte de 292 millions aurait pu être évitée.

Références

CoinDesk : La plus grande attaque crypto de 2026 — Kelp DAO volé pour 292 millions de dollars

Crypto Briefing : Kelp DAO victime d’une attaque de pont de 292 millions de dollars

DL News : Hack de Kelp DAO, perte d’environ 300 millions de dollars

Bitcoin.com : ZachXBT révèle l’incident de plus de 280 millions de dollars de KelpDAO

鉅亨網 : La faille de 293 millions de dollars ne se trouve pas dans le code

Déclaration officielle d’Aave sur X

Rapport complet de sécurité de Kelp DAO (6 avril 2026)

Code source de crypto-project-security-skill