LayerZero publie un rapport d'enquête : Analyse des causes directes et du processus du piratage de KelpDAO

Source : LayerZero ; Traduction : GoldFinanceClaw

Déclaration sur l’incident de KelpDAO

Le 18 avril 2026, KelpDAO a été victime d’une attaque, avec une perte d’environ 290 millions de dollars. Les premières indications suggèrent que cette attaque provient d’une organisation de hackers de niveau étatique très sophistiquée, très probablement le groupe Lazarus de Corée du Nord (plus précisément la branche TraderTraitor). Cet incident est limité à la configuration rsETH de KelpDAO, sa cause directe étant l’utilisation d’une seule DVN (réseau de validation décentralisé). Aucun autre actif ou application cross-chain ne présente de risque de contagion.

Cette attaque hautement sophistiquée visait l’infrastructure RPC (appel de procédure distante) en aval utilisée par le DVN de LayerZero Labs. Actuellement, tous les nœuds RPC affectés ont été abandonnés et remplacés, et le DVN de LayerZero Labs est à nouveau opérationnel.

Nous partageons ces détails dans le but d’aider la communauté à mieux comprendre et à se prémunir contre cette nouvelle vecteur d’attaque de niveau étatique.

Contexte : Architecture de sécurité modulaire de LayerZero

Le protocole LayerZero repose sur une architecture modulaire, configurable par application, en matière de sécurité. Les réseaux de validation décentralisés (DVNs) sont des entités indépendantes responsables de la vérification de l’intégrité des messages cross-chain. Il est crucial de noter que le protocole ne force pas une configuration de sécurité unique. Au contraire, il autorise chaque application et émetteur d’actifs à définir leur propre posture de sécurité, y compris les DVN qu’ils dépendent, la manière de les combiner et les seuils de redondance.

La meilleure pratique recommandée — et également explicitement recommandée par LayerZero à tous les intégrateurs — consiste à configurer un ensemble de plusieurs DVN avec diversité et redondance. Cela signifie qu’aucun DVN unique ne doit représenter un point de confiance ou de défaillance unique.

Portée et contagion : uniquement rsETH

Nous avons effectué un examen complet des activités intégrées sur le protocole LayerZero. Nous pouvons confirmer avec certitude qu’il n’existe aucun risque de contagion pour d’autres actifs ou applications. L’incident est entièrement isolé à la configuration rsETH de KelpDAO, causée par la configuration d’un seul DVN.

L’application affectée est le rsETH émis par KelpDAO. Au moment de l’incident, sa configuration OApp dépendait d’un seul DVN « 1/1 », utilisant uniquement LayerZero Labs comme seul validateur — une configuration qui viole directement le modèle de redondance multi-DVN que LayerZero recommande toujours à ses partenaires. La configuration en point unique de défaillance signifie qu’il n’y a pas de validateur indépendant pour détecter et rejeter les messages falsifiés. LayerZero et d’autres organismes externes avaient déjà communiqué à KelpDAO les meilleures pratiques pour la diversification des DVN, mais malgré ces recommandations, KelpDAO a choisi d’utiliser une configuration 1/1.

Une configuration renforcée raisonnable aurait nécessité un consensus entre plusieurs DVN indépendants, de sorte qu’en cas de compromission d’un seul DVN, l’attaque échouerait.

Déroulement de l’incident

Le 18 avril 2026, le DVN de LayerZero Labs est devenu la cible d’une attaque hautement sophistiquée. Les attaquants ont compromis l’infrastructure RPC en aval en la « empoisonnant » ou en la falsifiant, ce qui leur a permis de compromettre le quorum RPC utilisé pour valider les transactions du DVN. Cela n’a pas été réalisé par une faille du protocole, du DVN lui-même ou par une faille dans la gestion des clés.

Au contraire, les attaquants ont obtenu la liste RPC utilisée par notre DVN, en ont compromis deux nœuds indépendants, puis ont remplacé le fichier binaire exécutant le nœud op-geth. En respectant notre principe de « moindre privilège », ils n’ont pas pu compromettre le véritable instance du DVN. Cependant, ils ont utilisé cette faille comme tremplin pour mener une attaque d’usurpation RPC :

• Un nœud malveillant utilise une charge utile personnalisée pour falsifier des messages auprès du DVN.

• Ce nœud ment au DVN, mais rapporte des informations authentiques à toute autre adresse IP (y compris nos services de scan et notre infrastructure de surveillance interne). Cette conception soigneusement élaborée vise à éviter que la surveillance de sécurité ne détecte une anomalie.

• Après l’attaque, le nœud malveillant se détruit lui-même, désactive le RPC et supprime les fichiers binaires malveillants ainsi que les journaux associés.

De plus, les attaquants ont lancé une attaque DDoS sur les RPC non compromis, provoquant un basculement (failover) vers un nœud RPC empoisonné. En conséquence, l’instance DVN opérée par LayerZero Labs a confirmé que des transactions qui n’ont jamais eu lieu ont été enregistrées.

Situation de sécurité de LayerZero Labs

Nous opérons avec des endpoints complets de détection et de réponse (EDR), un contrôle d’accès strict, un environnement entièrement isolé et des journaux système complets. Nos nœuds RPC, qu’ils soient internes ou externes, sont sous surveillance. Nous sommes actuellement en phase finale d’audit SOC2.

Voie à suivre

1. Rétablissement du DVN : le DVN de LayerZero Labs a été remis en service. Les applications utilisant une configuration multi-DVN peuvent reprendre leurs opérations en toute confiance.

2. Migration forcée : nous contactons toutes les applications utilisant une configuration 1/1 pour leur demander de migrer vers une configuration multi-DVN redondante. Le DVN de LayerZero Labs ne signera ni ne certifiera plus de messages pour toute application utilisant une configuration 1/1.

3. Coopération avec les autorités : nous collaborons avec plusieurs agences de la loi à l’échelle mondiale et soutenons nos partenaires industriels et Seal911 dans le suivi des fonds.

Résumé

Il est important de préciser : le protocole LayerZero lui-même a parfaitement fonctionné tout au long de l’incident. Aucune vulnérabilité du protocole n’a été détectée. Si le système avait été monolithique ou partagé une seule sécurité, le risque de contagion aurait pu affecter toutes les applications. La caractéristique unique de l’architecture de LayerZero est sa sécurité modulaire, qui a joué son rôle dans ce cas précis — l’attaque a été entièrement isolée à une seule application, sans risque de propagation dans le système.

Nous continuerons à œuvrer pour la sécurité et l’intégrité de l’écosystème LayerZero.