Point clé à dire d’emblée : ce n’est pas Safe qui est compromis en tant que tel ; c’est le module personnalisé accroché au portefeuille qui a laissé la porte dérobée trop ouverte.
Le 15 septembre vers 04:38 UTC, des équipes de sécurité comme Blockaid et d’autres ont suivi une utilisation abusive d’une autorisation de module sur un Ethereum Safe : l’attaquant, via un keeper multicall rendu public, a redirigé un module de liquidité Uniswap v4 personnalisé vers une hooked pool qu’il contrôlait, puis a décomposé l’aEthrsETH en environ 2 900 jetons $rsETH, soit une valorisation d’environ 7,73 millions de dollars (les médias évoquent aussi environ 7,8 millions). La qualification côté sécurité est un abus d’autorisation du module, et non un compromis du cœur de Safe ou de la clé de l’owner.
Le plus dramatique, c’est le même bloc : l’explorateur MEV Yoink a devancé le reste et a emballé en premier une transaction dans le mempool public, en payant environ 18,93 $ETH au builder (≈ 46 000 $). Il a dérobé quelque 2882 $rsETH. Le hacker a fait le boulot, et l’argent est d’abord tombé dans la poche du robot.
Kelp (le protocole $rsETH) a ensuite mis l’adresse de réception en pause au niveau portefeuille pendant 24 heures, et a déclaré : le contrat Kelp fonctionne normalement, $rsETH reste fully backed, et la frappe/le rachat/l’intégration n’ont pas été stoppés — le risque se situe dans des modules personnalisés côté utilisateur, pas dans le contrat principal du protocole. Est-ce que l’argent revient ou non aux utilisateurs ? Cela dépend des négociations ultérieures entre white hats ; dans les précédents, quelqu’un a gardé environ 10 % de bounty avant de le reverser.
Mon tri : le module multi-signature = une surface de permissions supplémentaire. La « commodité » qui permet de co-signer, c’est la porte d’entrée pour que quelqu’un d’autre puisse dépenser à votre place. Sur la chaîne, dans le mempool public, le front-running est parfois plus rapide que le hacker lui-même.
Ne constitue pas un conseil en investissement.