TLDR :
- Une configuration DVN unique sur le pont Kelp rsETH a créé un point de défaillance unique que les attaquants ont exploité.
- L'attaquant a emprunté 82 650 WETH et 821 wstETH en utilisant 89 567 rsETH volés sur huit positions Aave V3.
- DeFi United a coordonné plus de 300 millions de dollars d'engagements de récupération de la part du Lido, Ethena, Mantle et d'autres contributeurs.
- L'adaptateur LayerZero OFT d'Aave a été entièrement rechargé sur cinq tranches, rétablissant l'intégralité du support rsETH de 116 131.
L'incident rsETH du 18 avril 2026 a révélé une vulnérabilité critique dans l'infrastructure de pont tierce connectée aux marchés d'Aave.
Un faux message inter-chaînes sur le pont Kelp rsETH LayerZero V2 a libéré 116 500 rsETH sur Ethereum sans aucune gravure correspondante sur Unichain.
L’attaquant a ensuite utilisé ces jetons comme garantie sur les positions Aave V3. Un effort de redressement coordonné a par la suite rétabli un soutien total et ramené tous les marchés touchés à la normale.
La vulnérabilité du pont qui a déclenché l'exploit
Le pont Kelp rsETH LayerZero V2 d'Unichain à Ethereum s'appuyait sur un seul vérificateur pour signer tous les messages inter-chaînes entrants.
Cette configuration, connue sous le nom de réseau de vérification décentralisé unique, a créé un point de défaillance unique. Lorsque ce vérificateur a été ciblé par une attaque d’empoisonnement RPC, l’attaquant a entièrement manipulé sa vision de l’état de la chaîne source.
À 17h35 UTC le 18 avril, le point de terminaison Ethereum a accepté le nonce entrant 308 et a libéré 116 500 rsETH à partir du RSETH_OFTAdapter.
Au même moment, le point de terminaison source d'Unichain affichait toujours uniquement le numéro 307 sortant. Aucune brûlure n'avait eu lieu sur la chaîne source, mais le côté Ethereum a traité le message comme légitime.
La cause profonde n’était pas une faille dans les contrats intelligents d’Aave. Au lieu de cela, c'était la dépendance du pont à l'égard d'un seul vérificateur et la susceptibilité de ce vérificateur aux manipulations externes. Cette dépendance était entièrement en dehors du protocole Aave.
Comment l'attaquant s'est déplacé sur les marchés d'Aave
Une fois les 116 500 rsETH libérés, l’attaquant a agi rapidement. Les jetons volés ont été dispersés sur sept adresses de destinataires quelques minutes après l'exploit. À partir de là, 89 567 rsETH ont été déployés sur huit positions Aave V3 sur Ethereum Core et Arbitrum.
Contre cette garantie, l’attaquant a emprunté 82 650 WETH et 821 wstETH. Les facteurs de santé dans les huit positions sont restés entre 1,01 et 1,03, juste au-dessus des seuils de liquidation. Ce positionnement a permis à l'attaquant de détenir les actifs empruntés tout en évitant une liquidation automatique.
L'exposition d'Aave provenait du fait que rsETH était répertorié comme garantie sur ses marchés selon des conditions standard de surdimensionnement. Cette liste a créé une dépendance directe sur le chemin de vérification du pont, une infrastructure qu'Aave ne contrôle pas.
Les mesures de confinement immédiates qui ont suivi
Le Aave Protocol Guardian a répondu en quelques heures. Le 18 avril à 19h00 UTC, rsETH et wrsETH étaient gelés dans Aave V3 et LTV était réglé sur zéro.
Sur Aave V4, le Kelp Spoke a été entièrement gelé dans les réserves WETH et rsETH, et l'emprunt WETH sur le Spoke a été immédiatement désactivé.
Entre 18h00 et 19h00 UTC, Kelp a mis en pause 43 373 rsETH connectés à l'exploit. Cette action a empêché tout mouvement supplémentaire de ces jetons spécifiques et limité les dégâts supplémentaires pendant la fenêtre de réponse précoce.
Au cours des deux jours suivants, des protections supplémentaires ont été appliquées sur les marchés concernés. WETH a été gelé sur Ethereum Core, Ethereum Prime, Arbitrum, Base, Mantle et Linea le 20 avril.
Le Conseil de sécurité de l'Arbitrum a ensuite gelé 30 766 ETH liés à l'attaquant le 21 avril. Le 23 avril, les réserves de rsETH ont été entièrement suspendues sur plusieurs déploiements, préservant ainsi la capacité de liquider les positions des attaquants et de récupérer les actifs des utilisateurs concernés.