Le cœur de l’attaque contre Kelp réside dans le fait que l’attaquant a falsifié un message cross-chain, permettant au pont LayerZero OFT de libérer directement sur la chaîne principale 116 500 rsETH authentiques (sans destruction correspondante sur la chaîne source), puis d’insérer ces rsETH « vides » comme garantie dans des protocoles tels qu’Aave, afin d’emprunter environ 236 millions de dollars américains en WETH/ETH réels. La vulnérabilité centrale ne se trouve pas dans Aave, mais dans la configuration du pont cross-chain LayerZero de Kelp DAO. Kelp utilise pour ses rsETH le standard OFT (Omnichain Fungible Token) de LayerZero V2 : Sur la chaîne principale Ethereum, le contrat OFTAdapter verrouille les rsETH comme réserve finale pour les rsETH wrapped sur plusieurs L2 (comme un coffre-fort bancaire). Sur les L2, le contrat OFT standard suit un mécanisme 1:1 lors du cross-chain : « debit (destruction/abonnement) → message → credit (mintage/libération) ». Dans un scénario normal, le processus serait le suivant : Un utilisateur L2 brûle des rsETH → LayerZero envoie un message → l’OFTAdapter sur la chaîne principale reçoit le message et libère les rsETH correspondants. L’attaquant n’a fait qu’une seule chose : Il a appelé directement sur la chaîne principale Ethereum la fonction lzReceive du contrat EndpointV2 de LayerZero (hash de transaction publique : 0x1ae232da…), en y intégrant un paquet de message cross-chain falsifié (origin packet), prétendant qu’il provenait d’une chaîne source légitime. Après validation par EndpointV2, le message a été transmis à l’OFTAdapter des rsETH de Kelp. Celui-ci, en recevant le message, a libéré directement 116 500 rsETH depuis la réserve principale vers l’adresse de l’attaquant. Ainsi, aucune trace de burn/debit n’existe sur la chaîne source, mais une libération/credit a été effectuée sur la chaîne principale. La conservation de la quantité omnichain a été rompue, le coffre-fort principal a été vidé, et tous les rsETH sur les L2 sont devenus simultanément « du papier sans valeur ». Une seule transaction a permis de mener à bien l’attaque. Les deux attaques supplémentaires ultérieures (chacune de 40 000 rsETH) n’ont pas réussi, car Kelp a suspendu d’urgence ses opérations. La question est donc la suivante : Pourquoi le pont LayerZero a-t-il « accepté » ce message falsifié ? Ce n’est pas une faille du protocole LayerZero lui-même, mais une configuration de sécurité trop faible au niveau de l’application (OApp) de Kelp. LayerZero V2 permet aux développeurs de configurer librement l’intensité de la vérification en utilisant un DVN (Distributed Validator Network) pour valider les messages. Kelp n’a configuré qu’un DVN 1-of-1 (nécessitant uniquement une signature d’un seul validateur), ce qui correspond au niveau de sécurité le plus faible possible. Déjà en janvier 2025, un avertissement avait été émis sur le forum de gouvernance d’Aave : Kelp devait étendre son DVN à un système multi-signature (au moins 2-of-2 ou plus). Quinze mois plus tard, aucune modification n’avait été apportée ; Kelp avait conservé cette configuration « vitesse avant tout » et extrêmement faible. Ce point unique est devenu le point d’attaque central : un seul DVN a été compromis, une signature a été falsifiée, ou un packet valide a été directement construit. Dès qu’EndpointV2 reçoit un message « validé », il appelle directement la fonction lzReceive du contrat cible. L’OFTAdapter fait entièrement confiance au packet transmis par Endpoint et n’effectue aucune vérification secondaire supplémentaire. Si Kelp avait privilégié un équilibre entre vitesse et sécurité plutôt que la vitesse seule, cette attaque n’aurait probablement pas réussi. Autrement dit, Kelp a entièrement misé la légitimité des messages cross-chain sur un seul DVN. Enfin, les rsETH ont pu rapidement être empruntés en ETH réel parce qu’ils figuraient sur la liste blanche des garanties acceptées par Aave et d’autres protocoles. L’attaquant a déposé ses rsETH falsifiés dans Aave et en a emprunté des WETH réels dans les 46 minutes précédant la suspension de Kelp. Lorsque Kelp a gelé son pont et ses jetons, les créances impayées étaient déjà présentes dans Aave (qui a gelé le marché des rsETH et activé son module de sécurité Umbrella pour y faire face). En résumé, Le cœur de la falsification réside dans la configuration « unique DVN » combinée à l’appel direct de lzReceive avec un packet falsifié. Le risque d’un point unique de validation, couplé à la composable nature du DeFi, a engendré cette attaque à grande échelle. La validation unique est fragile. La vitesse est importante, mais la sécurité l’est davantage.