LayerZero publie son rapport sur l'incident rsETH : Reconstruction de l'infrastructure affectée et rehaussement du niveau de sécurité inter-chaînes
LayerZero publie son rapport sur l'incident rsETH : Reconstruction de l'infrastructure affectée et rehaussement du niveau de sécurité inter-chaînes
L'interopérabilité inter-chaînes est devenue une composante essentielle de la DeFi en 2025-2026 : les jetons de restaking liquide, les marchés de prêt multi-chaînes et les standards d'émission omnichain supposent que les actifs peuvent circuler en toute sécurité entre les réseaux. Mais l'incident rsETH nous rappelle que la sécurité des ponts ne concerne pas seulement les contrats intelligents — elle touche également à la vérification hors chaîne, à l'intégrité de l'infrastructure et aux choix de configuration.
Suite à l'exploitation du pont rsETH de KelpDAO (18 avril 2026), LayerZero a publié une déclaration détaillée sur l'incident et une mise à jour expliquant comment un message inter-chaînes forgé a finalement été accepté dans une configuration à vérificateur unique, ainsi que les changements opérationnels et politiques qu'il met en œuvre. Vous pouvez consulter les communiqués originaux ici : Déclaration sur l'incident KelpDAO et Mise à jour LayerZero.
Ce qui s'est passé (et ce qui ne s'est pas passé)
L'impact : le pont rsETH vidé via un message forgé
Le 18 avril 2026, un attaquant a réussi à faire libérer environ 116 500 rsETH (soit environ 292 millions de dollars à l'époque) via la route du pont rsETH de KelpDAO basée sur LayerZero, en faisant vérifier et exécuter un message inter-chaînes forgé sur Ethereum. LayerZero a souligné que cet incident était limité à la configuration rsETH de KelpDAO et que le protocole LayerZero lui-même n'a pas été exploité. Voir le résumé de LayerZero dans la déclaration sur l'incident.
Attribution : "TraderTraitor", lié à la RPDC
LayerZero a déclaré avoir une confiance préliminaire dans le fait que l'attaquant était un acteur étatique très sophistiqué, attribuant l'incident au Groupe Lazarus de la RPDC, plus spécifiquement au cluster TraderTraitor référencé par les autorités américaines. Pour plus d'informations sur les tactiques de "TraderTraitor" (ingénierie sociale, livraison de logiciels malveillants et ciblage des organisations crypto), consultez l'avis conjoint américain : Avis CISA sur TraderTraitor (AA22-108A).
Ce qui n'a pas été compromis (selon LayerZero)
La déclaration de LayerZero sur l'incident note explicitement que l'attaque n'était pas le résultat d'un bug du protocole LayerZero, et précise que les clés de signature DVN n'ont pas été volées directement. L'attaquant a plutôt ciblé les dépendances de données (RPC) du DVN et les hypothèses de disponibilité environnantes. Les détails sont disponibles dans la déclaration sur l'incident.
Le mode de défaillance principal : le "vérificateur unique" rencontre l'empoisonnement RPC + le basculement forcé
L'explication de LayerZero se concentre sur une catégorie d'attaques croissante : l'empoisonnement RPC (fournir à un vérificateur un état de chaîne manipulé) combiné au déni de service / déni de service distribué (DoS / DDoS) (forcer le système à s'appuyer sur des sources empoisonnées).
1) Les nœuds RPC en aval ont été compromis et ont menti sélectivement
Selon LayerZero, l'attaquant a obtenu l'accès à la liste des nœuds RPC utilisés par le DVN de LayerZero Labs, en a compromis un sous-ensemble et a modifié le comportement des nœuds de manière à ce que le DVN reçoive un état de chaîne falsifié — pendant que de nombreux systèmes de surveillance continuaient de recevoir des réponses "normales". LayerZero décrit cette tromperie sélective dans sa déclaration sur l'incident.
Si vous souhaitez un aperçu pratique des raisons pour lesquelles les points d'accès RPC constituent une surface d'attaque à fort effet de levier pour les systèmes cryptographiques, l'aperçu de Chainstack est une référence utile : Attaques par empoisonnement RPC dans la crypto. Pour une définition générale du RPC dans les systèmes distribués, consultez l'aperçu d'IBM : Appel de procédure à distance (RPC).
2) La disponibilité des RPC externes a été attaquée pour déclencher la dépendance à l'égard des nœuds compromis
LayerZero rapporte que des activités de DDoS contre des points d'accès RPC externes sains ont poussé le comportement de secours du DVN vers les points d'accès empoisonnés, permettant la vérification d'un message lié à des transactions qui ne se sont jamais produites comme annoncé. Cette "pression sur la disponibilité" est une leçon cruciale pour quiconque construit des systèmes de vérification hors chaîne : la redondance ne consiste pas seulement à avoir plus de points d'accès ; elle consiste à survivre à des pannes ciblées sans se fier aux mauvais.
3) La configuration DVN 1 sur 1 de KelpDAO a transformé la compromission en perte
Le détail de configuration le plus important : la route rsETH de KelpDAO utilisait une configuration DVN 1 sur 1, LayerZero Labs agissant en tant que seul vérificateur. LayerZero soutient que cela a créé un point de défaillance unique — aucun vérificateur indépendant n'existait pour rejeter le message forgé. Ceci est discuté directement dans la déclaration sur l'incident.
Une analyse approfondie par un tiers qui capture l'angle "pourquoi cela importait pour le risque DeFi" est la note de recherche de Galaxy : Analyse de l'exploit KelpDAO / LayerZero.
Pourquoi cet incident est important au-delà d'un seul pont
La réalité 2025-2026 : les "exploits d'infrastructure" s'intensifient plus rapidement que les exploits de contrats
Les conversations sur la sécurité de la DeFi accordent toujours trop d'importance aux audits et aux bugs on-chain. Pourtant, bon nombre des incidents les plus importants ressemblent désormais à des intrusions d'entreprise : compromission de points d'accès, falsification de la chaîne d'approvisionnement, détournement de sessions, attaques par disponibilité — suivis d'une extraction on-chain.
Dans le cas du rsETH, les contrats on-chain ont fonctionné comme prévu ; les entrées du processus de vérification ont été empoisonnées.
La composabilité de la DeFi a transformé un vidage de pont en un choc de liquidité
Une préoccupation majeure en aval était la manière dont les garanties sans support ou compromises se propagent dans les marchés de prêt. L'analyse post-incident a mis en évidence la rapidité avec laquelle les chocs de confiance peuvent vider la liquidité, même lorsque le code principal du protocole de prêt fonctionne comme prévu. Le rapport de Glassnode offre une perspective sur la structure du marché : Anatomie d'un blocage de liquidité.
La réponse de LayerZero : changements de politique, durcissement de la configuration et évolution des DVN
Les publications de LayerZero décrivent trois orientations pratiques :
1) "Fini le 1 sur 1" pour le DVN de LayerZero Labs
LayerZero déclare qu'il ne signera/attestera pas de messages pour les applications utilisant une configuration DVN 1 sur 1, et qu'il contacte les projets qui fonctionnent encore avec des configurations à vérificateur unique. Ceci est précisé dans la déclaration sur l'incident et renforcé dans la Mise à jour LayerZero.
2) Rehausser le niveau de base par défaut, mais inciter les équipes à fixer les configurations
Dans sa mise à jour du 8 mai, LayerZero recommande aux développeurs :
- Fixer les configurations (ne pas s'appuyer sur des valeurs par défaut modifiables)
- Utiliser des confirmations de blocs plus élevées adaptées à la chaîne
- Adopter la redondance multi-DVN (au moins 2, idéalement 3 à 5)
Ces recommandations sont listées dans la Mise à jour LayerZero. Pour les développeurs, LayerZero renvoie également à une checklist d'intégration dans sa documentation : Checklist d'intégration LayerZero.
3) Reconstruction et remplacement des composants RPC affectés
LayerZero a déclaré que les nœuds RPC affectés ont été dépréciés et remplacés, et que les opérations DVN ont repris avec des modifications concernant le quorum RPC et les hypothèses de redondance (détails dans la déclaration sur l'incident et la mise à jour).
Bien que l'architecture de sécurité interne de chaque équipe diffère, cette orientation s'aligne sur une réflexion plus large de type "zero trust" : minimiser les privilèges permanents, segmenter les systèmes de production et traiter les réseaux internes comme hostiles par défaut — surtout lorsque votre système sert de vérificateur pour des actifs externes.
Points à retenir pour les développeurs : une checklist 2026 pour la sécurité des ponts inter-chaînes
Si vous développez ou intégrez un actif omnichain (wrappers de type OFT, ponts canoniques, dérivés de restaking), l'incident rsETH suggère un ordre de priorité clair :
-
Éliminer la vérification unilatérale
- Exiger N vérificateurs indépendants sur M (pas "deux marques sur la même pile").
- L'indépendance doit inclure : l'organisation exploitante, l'hébergement, les sources RPC, la surveillance et la réponse aux incidents.
-
Durcir la confiance RPC et la logique de basculement
- Traitez les points d'accès RPC comme des entrées non fiables.
- Assurez-vous que le basculement ne réduit pas silencieusement la sécurité (par exemple, "si les points d'accès échouent, faites confiance à moins de points d'accès" est dangereux).
- Développez un comportement en "mode dégradé" : arrêtez la vérification plutôt que d'accepter des preuves moins solides sous pression.
-
Concevoir pour une disponibilité hostile
- Supposez que les attaques DDoS ciblées font partie de la chaîne d'attaque.
- Modélisez ce qui se passe lorsque seul le sous-ensemble contrôlé par l'attaquant reste accessible.
-
Rendre la posture de sécurité observable
- Publiez vos hypothèses de vérification dans un tableau de bord ou une documentation :
- Ensemble DVN, seuils, confirmations, clés de pause, procédures d'urgence
- Les utilisateurs et les équipes de gestion des risques doivent voir le risque de configuration avant un incident.
- Publiez vos hypothèses de vérification dans un tableau de bord ou une documentation :
Points à retenir pour les utilisateurs : comment réduire l'exposition au risque inter-chaînes
Même si vous n'écrivez jamais une ligne de code, vous pouvez réduire matériellement les risques :
- Traitez les actifs pontés comme une classe de risque distincte des actifs "natifs".
- Lorsque le rendement semble similaire entre les chaînes, privilégiez les plateformes où les garanties dépendent de moins d'hypothèses hors chaîne.
- Conservez uniquement les soldes opérationnels sur les L2 / représentations pontées ; stockez les avoirs à long terme dans un stockage à froid.
L'auto-conservation est importante : pourquoi un portefeuille matériel reste un contrôle essentiel
Les incidents comme celui du rsETH concernent la vérification et l'infrastructure, mais de nombreuses pertes importantes commencent encore par des appareils compromis, le vol d'identifiants et l'ingénierie sociale. Un portefeuille matériel réduit le rayon d'action en gardant les clés privées isolées de la navigation quotidienne et des logiciels malveillants sur poste de travail.
Si vous êtes sérieux au sujet de l'auto-conservation à long terme, l'utilisation d'un portefeuille matériel comme OneKey contribue à garantir que la signature des transactions reste en dehors de votre environnement connecté à Internet — une couche importante lorsque l'écosystème plus large est confronté à des modèles de menaces de plus en plus professionnels et liés à des États.
Pensée finale : "la configuration, c'est la sécurité"
L'exploit du rsETH sera probablement moins retenu comme "un piratage de pont" que comme une leçon systémique : la sécurité des protocoles est désormais modulaire, et le module le plus faible (souvent la configuration + l'infrastructure) définit le risque réel.
Alors que la messagerie inter-chaînes devient le système par défaut de la DeFi et des actifs tokenisés, la base de référence de l'industrie doit passer du "code audité" aux hypothèses auditées — y compris la diversité des DVN, l'intégrité des RPC et la sécurité du basculement.
