Le 18 avril 2026, le protocole de restaking liquide de Kelp DAO a été attaqué : en quelques heures, des pirates ont retiré 116 500 rsETH du pont interchaînes, d’une valeur d’environ 293 millions de dollars au prix de l’époque. Le processus était étrangement efficace : depuis la falsification des messages interchaînes jusqu’à la dispersion des fonds volés sur trois protocoles de prêt (Aave V3, Compound V3 et Euler) pour obtenir des actifs réels, les attaquants sont repartis le même jour avec 236 millions de dollars en WETH. Aave, SparkLend et Fluid ont immédiatement gelé le marché du rsETH.
Il s’agit de la plus grande attaque DeFi de 2026 à ce jour.
Mais une chose distingue cette attaque de la plupart des piratages. Le code des contrats intelligents de Kelp DAO ne contenait aucune vulnérabilité. Le chercheur en sécurité @0xQuit, qui a participé à l’enquête, a écrit sur X : « D’après ce que je sais pour l’instant, c’est la combinaison de deux problèmes : une configuration DVN 1-sur-1, et le fait que le nœud DVN lui-même a été compromis. » LayerZero n’a pas non plus mentionné le code des contrats dans sa déclaration officielle, qualifiant le problème de « vulnérabilité rsETH » et non de « vulnérabilité LayerZero ».
293 millions de dollars, qui ne se trouvaient dans aucune ligne de code. Ils étaient cachés dans un paramètre de configuration mal saisi lors du déploiement.
La logique générale de l’audit de sécurité DeFi est la suivante : trouver les contrats, lire le code, trouver les vulnérabilités. Cette logique fonctionne assez bien pour les vulnérabilités logiques du code ; des outils comme Slither et Mythril sont assez matures pour détecter des modèles connus comme les attaques de réentrance ou les dépassements d’entier. L’audit de code assisté par LLM, promu ces deux dernières années, a également une certaine capacité pour les vulnérabilités de logique métier (comme les chemins d’arbitrage par flash loan).
Mais deux lignes de cette matrice sont en rouge.
Les vulnérabilités de la couche configuration sont une zone d’aveuglement structurelle dans l’audit par outils. Le problème de Kelp DAO ne se trouvait pas dans un fichier .sol, mais dans un paramètre écrit lors du déploiement du protocole — le seuil DVN. Ce paramètre détermine le nombre de nœuds de validation par lesquels un message interchaînes doit être confirmé pour être considéré comme légitime. Il n’entre pas dans le code, ni dans la portée de l’analyse de Slither, ni dans le chemin d’exécution symbolique de Mythril. Selon une étude comparative de Dreamlab Technologies, Slither et Mythril ont détecté respectivement 5/10 et 6/10 des vulnérabilités dans les contrats testés, mais ces résultats reposent sur la prémisse que « la vulnérabilité est dans le code ». Selon une étude de l’IEEE, même au niveau du code, les outils existants ne peuvent détecter que 8 à 20 % des vulnérabilités exploitables.
Du point de vue du paradigme d’audit actuel, il n’existe pas d’outil capable de « détecter si le seuil DVN est raisonnable ». Pour détecter ce type de risque de configuration, il ne faut pas un analyseur de code, mais une liste de contrôle spécifique : « Le nombre de DVN du protocole interchaînes utilisé est-il ≥ N ? », « Y a-t-il une exigence de seuil minimum ? » Ce type de questions n’est actuellement couvert par aucun outil standardisé, et il n’existe même pas de norme industrielle largement reconnue.
Également dans la zone rouge se trouvent la sécurité des clés et des nœuds. La description de @0xQuit mentionne que le nœud DVN a été « compromis », ce qui relève de la sécurité opérationnelle (OpSec), au-delà des limites de détection de tout outil d’analyse statique. Aucun auditeur de première ligne, ni outil d’analyse par IA, n’a la capacité de prédire si la clé privée d’un opérateur de nœud va fuir.
Cette attaque a simultanément déclenché les deux zones rouges de la matrice.
DVN est le mécanisme de validation des messages interchaînes de LayerZero V2, acronyme de Decentralized Verifier Network (Réseau de Vérificateurs Décentralisé). Sa philosophie de conception est de confier la décision de sécurité à la couche applicative : chaque protocole connecté à LayerZero peut choisir lui-même le nombre de nœuds DVN nécessaires pour confirmer simultanément un message interchaînes avant de le laisser passer.
Cette « liberté » crée un spectre.
Kelp DAO a choisi l’extrémité la plus à gauche du spectre, 1-sur-1, ne nécessitant la confirmation que d’un seul nœud DVN. Cela signifie une tolérance aux pannes de zéro : l’attaquant n’a besoin de compromettre qu’un seul nœud pour falsifier n’importe quel message interchaînes. En comparaison, Apechain, qui utilise également LayerZero, a configuré au moins deux DVN obligatoires et n’a pas été touché par cet incident. La formulation de LayerZero dans sa déclaration officielle est : « Toutes les autres applications restent sûres », ce qui sous-entend : la sécurité dépend de la configuration choisie.
La recommandation habituelle de l’industrie est d’au moins 2-sur-3, ce qui signifie que l’attaquant doit compromettre simultanément deux nœuds DVN indépendants pour falsifier un message, portant la tolérance aux pannes à 33 %. Des configurations de haute sécurité comme 5-sur-9 peuvent atteindre une tolérance aux pannes de 55 %.
Le problème est que les observateurs externes et les utilisateurs ne voient pas cette configuration. Deux protocoles tous deux étiquetés « pris en charge par LayerZero » peuvent cacher une tolérance aux pannes de 0 % ou de 55 %. Les deux sont appelés DVN dans la documentation.
L’investisseuse crypto chevronnée Dovey Wan, qui a vécu l’incident Anyswap, a écrit directement sur X : « Le DVN de LayerZero était en fait 1/1 validateur...... Tous les ponts interchaînes devraient immédiatement effectuer un examen de sécurité complet. »
En août 2022, une vulnérabilité a été découverte sur le pont interchaînes Nomad. Quelqu’un a copié la première transaction d’attaque, l’a légèrement modifiée, et a constaté que cela fonctionnait aussi — des centaines d’adresses ont alors commencé à copier, vidant 190 millions de dollars en quelques heures.
L’analyse post-mortem de Nomad indiquait que la vulnérabilité provenait d’« une initialisation de la trusted root à 0x00 lors d’une mise à jour de routine ». C’était une erreur de configuration, survenue lors de la phase de déploiement. La logique de vérification de la preuve Merkle n’avait pas de problème, le code lui-même n’avait pas de problème, le problème était une valeur initiale mal renseignée.
Cet incident, ajouté à celui de Nomad, porte les pertes dues aux vulnérabilités de type configuration/initialisation à environ 482 millions de dollars. Dans l’histoire des vols sur les ponts interchaînes, cette catégorie est désormais comparable aux fuites de clés (Ronin 624 millions de dollars, Harmony 100 millions de dollars, Multichain 126 millions de dollars, totalisant environ 850 millions de dollars).
Mais la conception des produits de l’industrie de l’audit de code n’a jamais ciblé cette catégorie.
L’industrie discute surtout des vulnérabilités logiques du code. Wormhole a été piraté pour 326 millions de dollars à cause d’un contournement de validation de signature, Qubit Finance a été volé de 80 millions de dollars à cause d’un événement de dépôt frauduleux. Ces cas ont des rapports d’analyse de vulnérabilité complets, des numéros CVE analogues, des PoC reproductibles, et sont adaptés à l’entraînement et à l’optimisation des outils d’audit. Les problèmes de couche configuration ne sont pas écrits dans le code et ont du mal à entrer dans ce cycle de production.
Un détail notable est que les deux incidents de type configuration ont été déclenchés de manières radicalement différentes. Nomad a accidentellement saisi une valeur initiale erronée lors d’une mise à jour de routine, c’était une erreur. Le choix 1-sur-1 de Kelp DAO était un choix de configuration actif — le protocole LayerZero n’interdit pas cette option, et Kelp DAO n’a violé aucune règle du protocole. Un choix de configuration « conforme » et une valeur initiale « erronée » ont finalement conduit au même résultat.
La logique d’exécution de cette attaque était simple : un message interchaînes falsifié informait le mainnet Ethereum que « des actifs équivalents avaient été verrouillés sur une autre chaîne », déclenchant la frappe de rsETH sur le mainnet. Les rsETH frappés n’avaient pas de garantie réelle, mais leur enregistrement on-chain était « légal » et pouvait être accepté comme collatéral par les protocoles de prêt.
L’attaquant a ensuite dispersé les 116 500 rsETH sur Aave V3 (Ethereum et Arbitrum), Compound V3 et Euler, empruntant plus de 236 millions de dollars d’actifs réels. Selon de multiples rapports, la mauvaise dette estimée pour Aave V3 seule était d’environ 177 millions de dollars. Les réserves de WETH du module de sécurité Umbrella d’Aave, utilisables pour absorber les mauvaises dettes, s’élevaient à environ 50 millions de dollars, couvrant moins d’un tiers du montant. Le reste serait supporté par les stakers d’aWETH.
Cette facture est finalement retombée sur ceux qui voulaient simplement gagner un peu d’intérêt sur leur WETH.
LayerZero, au moment de la rédaction, enquêtait toujours conjointement avec l’organisation de réponse aux incidents de sécurité SEAL Org, indiquant qu’il publierait un rapport d’analyse post-mortem avec Kelp DAO une fois toutes les informations obtenues. Kelp DAO a déclaré mener des « actions correctives proactives ».
La vulnérabilité de 293 millions de dollars n’était pas dans le code. Les mots « audit validé » ne couvraient pas l’endroit où se trouvait ce paramètre.
