Les sociétés de sécurité blockchain Blockaid, PeckShield et BlockSec ont confirmé qu'une exploit a drainé environ 7,8 millions de dollars en rsETH — environ 2 900 tokens — depuis un portefeuille Gnosis Safe sur Ethereum. Safe est un portefeuille à contrat intelligent largement utilisé pour sécuriser d'importants avoirs on-chain, et rsETH est le token de restaking liquide émis par KelpDAO, une représentation échangeable d'actifs restakés. Selon les rapports des sociétés, l'incident a commencé à 04h38 UTC le 15 septembre avec une transaction qui a déplacé l'essentiel des fonds, suivie de plusieurs transactions plus modestes au cours de l'heure suivante, totalisant environ 160 000 $ supplémentaires.

Une vérification d'autorisation défectueuse a permis une exécution arbitraire

La cause racine était une vérification d'autorisation défectueuse dans le contrat exécuteur, identifié par les analystes à l'adresse 0x4f0055926c839D1d960a82CBF84E2eE933958ebC. Le Safe ciblé, appartenant à un grand détenteur de rsETH à effet de levier, reposait sur un module exécuteur de stratégie en liste blanche qui exposait un point d'entrée « recipe ». Ce point d'entrée transmettait des calldata entièrement fournies par l'appelant à la fonction execTransactionFromModuleReturnData du Safe en utilisant operation=1 (DELEGATECALL) — une opération qui permet au code appelé de s'exécuter dans le contexte du propre appelant — sans restreindre l'appelant externe. Définir le paramètre de contrat fourni sur l'adresse du propre exécuteur suffisait à passer la validation, ce qui signifiait que quiconque pouvait atteindre le point d'entrée pouvait exécuter du code arbitraire à l'intérieur du, obtenant ainsi le contrôle total de ses actifs.

L'attaquant a utilisé un multicall de keeper public pour acheminer le module Uni V4 LP Safe autorisé vers un pool Uniswap V4 avec hook créé par l'attaquant, en exécutant via Permit2 et le PositionManager. Dans le cadre de la préparation, l'attaquant avait déployé un token sans valeur baptisé « Permissionless Attacker Token » (PAT) et fourni environ 2 900 aEthrsETH en liquidité contre celui-ci. Un hook personnalisé dans le pool a ensuite déballé l'aEthrsETH en rsETH et l'a soutiré du Safe, qui s'est retrouvé avec un LP NFT sans valeur.

Blockaid exploit detection system detected an exploit on an unidentified user's Safe on Ethereum. ~$7.73M confirmed rsETH loss so far. An attacker used a public keeper multicall to drive a custom Uni V4 LP Safe module into an attacker-created hooked pool; the hook unwrapped…

— Blockaid (@blockaid_) September 15, 2026

Un bot MEV front-run l'attaque ; KelpDAO impose une pause temporaire

Fait notable, la transaction d'attaque initiale n'a jamais atteint son bénéficiaire prévu. L'attaquant a lancé l'exploit directement dans le mempool public, où il a été front-run par un bot MEV nommé « yoink », qui a capturé la totalité des ~2 882 rsETH — d'une valeur d'environ 7,8 millions de dollars — et les a acheminés vers l'adresse 0xC70f00CD7E461686b04B0E912E309becA8b80ea0. En réalité, un bot de valeur extractible maximale — un programme qui capture de la valeur en exploitant l'ordre des transactions dans un bloc — plutôt que l'attaquant, est reparti avec les fonds dérobés.

En réponse, KelpDAO a annoncé avoir détecté une activité suspecte sur l'adresse de réception et l'a placée sous une pause préventive de 24 heures, pendant laquelle le rsETH ne peut entrer ni sortir. L'équipe a déclaré travailler avec des experts en sécurité sur l'enquête et a souligné que la mesure ne s'applique qu'au niveau du portefeuille : les contrats Kelp restent sûrs, le rsETH reste entièrement adossé, et toutes les opérations de mint, de retrait et d'intégration se poursuivent normalement, sans aucune action requise des utilisateurs.

We've detected potential suspicious activity on an the address (0xc70f00cd7e461686b04b0e912e309becA8b80ea0) that received rsETH a few hours ago. Out of an abundance of caution, we've placed that address under a temporary 24-hour pause. During this window, rsETH cannot move in…

— Kelp (@KelpDAO) September 15, 2026

Un abus au niveau du module, et non une vulnérabilité du cœur de Safe

Les analystes en sécurité ont souligné qu'il s'agissait d'un abus d'autorisation de module propre à un seul Safe, et non d'une vulnérabilité des contrats fondamentaux de Safe ou des clés des propriétaires. Comme les modules Safe s'exécutent avec l'autorité du propre portefeuille, une faille dans une extension de confiance, même en liste blanche, peut exposer l'intégralité d'un solde sans aucune compromission des contrôles du propri. L'incident met néanmoins en lumière un risque persistant pour les utilisateurs de portefeuilles à contrat intelligent : le cœur de Safe n'a jamais subi d'exploit direct au niveau du protocole, mais les utilisateurs ont repeatedly perdu des fonds à cause d'infrastructures compromises et d'extensions tierces vulnérables, notamment plus de 2 millions de dollars dérobés dans des attaques d'empoisonnement d'adresse touchant 21 utilisateurs de Safe en 2023.

Source : Metaverse Post