Vérifier les modules de votre wallet Safe : comment un module a déplacé 7,7 millions de dollars sans signature

Le 15 septembre 2026, un wallet Ethereum a perdu environ 2 882 rsETH sans qu’une seule signature de propriétaire ait été nécessaire. Ce wallet était une multisig Safe, c’est-à-dire précisément l’architecture réputée particulièrement sûre parce que plusieurs clés doivent signer ensemble. Le solde s’est pourtant vidé, et ce par l’intermédiaire d’un module que les propriétaires avaient eux-mêmes activé. Si vous utilisez un wallet à contrat intelligent, la tâche qui découle de cet épisode est limitée et concrète : regardez quels modules sont activés dans votre wallet et retirez tout ce dont vous n’avez plus besoin ou que vous ne savez plus expliquer.

Ce texte explique ce qu’un module a techniquement le droit de faire, comment s’est déroulée l’attaque du 15 septembre et comment mener vous-même la vérification en quelques minutes. Le passage par l’interface ne vous coûte aucun frais. Seul le retrait d’un module constitue une transaction, et celle-ci exige le nombre habituel de signatures.

Le module Safe expliqué : ce qu’un module a le droit de faire dans un wallet à contrat intelligent

Un module Safe est un contrat intelligent distinct auquel le wallet accorde durablement le droit d’exécuter des transactions en son nom, sans que le nombre habituel de signatures de propriétaires soit réuni. Ce n’est pas une faille de conception, c’est la finalité même de cette architecture. Qui veut faire tourner un versement de salaires automatique, une routine de rééquilibrage récurrente ou une stratégie de liquidité ne peut pas faire signer chaque étape par trois personnes. Le wallet délègue donc cette partie à un contrat.

Techniquement, cela passe par la fonction execTransactionFromModule, ou par sa variante avec valeur de retour. Un module activé l’appelle, et le wallet exécute ce que le module lui ordonne. Le seuil de signature n’est pas contourné pour autant : il n’est tout simplement pas prévu sur ce chemin. La documentation de Safe en énonce la conséquence avec une netteté inhabituelle : les modules peuvent exécuter des transactions arbitraires, il convient de n’ajouter que des modules audités et dignes de confiance, et un module malveillant peut prendre intégralement le contrôle d’un wallet. Le tout figure dans la documentation officielle de Safe sur les modules de comptes intelligents.

Deux propriétés rendent les modules attrayants pour les attaquants. D’abord, ils sont durables : une fois activé, un module le reste jusqu’à ce que quelqu’un le désactive expressément. Ensuite, ils sont invisibles au quotidien. Vous ne les voyez ni à l’envoi, ni à la réception, ni dans le solde. Ils n’apparaissent que là où l’on va délibérément regarder.

L’attaque du 15 septembre : comment DELEGATECALL a libéré 2 882 rsETH

La sortie de fonds est tombée dans le bloc 25980525, à 04:38:47 UTC. Un seul wallet Safe était concerné, détenteur d’une position à effet de levier en rsETH, le jeton de restaking liquide de Kelp DAO. Les sociétés de sécurité Blockaid et PeckShield ont signalé l’incident les premières ; leurs chiffres de préjudice divergent légèrement et se situent entre 7,73 et 7,81 millions de dollars. La quantité est plus précise que le montant en dollars : 2 882,37 rsETH.

La faille se logeait dans un module sur mesure que le wallet employait pour une stratégie de liquidité sur Uniswap v4. Ce module proposait un point d’entrée qui transmettait sans contrôle les données fournies par l’appelant, et ce directement à la fonction de wallet execTransactionFromModuleReturnData avec l’indicateur d’opération 1. L’indicateur 1 désigne DELEGATECALL, et c’est là le point décisif.

DELEGATECALL en une phrase

DELEGATECALL exécute du code étranger dans la mémoire et sous l’identité de votre propre contrat, comme si le wallet avait écrit ce code lui-même. Qui peut déclencher cet appel n’agit pas auprès du wallet : il agit en tant que wallet.

Comme le point d’entrée du module n’était assorti d’aucune protection d’accès pour les appelants externes, n’importe quelle adresse pouvait l’atteindre. Et comme le module était déjà activé dans le wallet, celui-ci n’a rien vérifié de plus. La liste des propriétaires et le seuil de signature n’ont plus joué aucun rôle dans cet enchaînement.

Hook Uniswap v4 et multicall de keeper : le chemin de l’attaquant étape par étape

La chaîne comportait plusieurs niveaux et s’est appuyée de bout en bout sur des fonctions conçues comme des commodités. L’attaquant a d’abord appelé une fonction publique de multicall de keeper. Les keepers sont des services qui maintiennent une stratégie en fonctionnement, par exemple en ajustant des positions ; leurs appels sont souvent ouverts à dessein, afin que chacun puisse les déclencher et que la stratégie ne s’arrête jamais.

Par cet appel, il a orienté le module de liquidité du wallet vers un pool Uniswap v4 qu’il contrôlait lui-même. Uniswap v4 autorise ce que l’on appelle des hooks, c’est-à-dire du code propre qui s’exécute automatiquement lors de certains événements d’un pool. Le hook de ce pool appartenait à l’attaquant.

La dernière étape a été le déballage. Le wallet ne détenait pas du rsETH nu, mais de l’aEthrsETH, autrement dit du rsETH dans l’enveloppe rémunérée du marché de prêt Aave. Sous cette forme, il ne se déplace pas facilement. Le hook a déballé l’avoir en rsETH librement transférable, et le solde est alors devenu mobile.

Un bot MEV à la place de l’attaquant : pourquoi « yoink » a récupéré l’argent

L’attaquant a envoyé sa transaction dans le mempool public, c’est-à-dire dans la zone d’attente des transactions non encore confirmées, consultable par tous. Un bot MEV répondant au nom de « yoink » y lisait en parallèle, a reconstitué le même enchaînement et est passé le premier dans le même bloc. Les 2 882,37 rsETH ont atterri sur une adresse du bot, valant environ 7,80 millions de dollars à sa valorisation au moment de l’exécution.

Pour le wallet dépouillé, cela ne change rien. Pour vous, cela change deux choses. D’abord, le cas montre qu’une faille ouverte dans un module ne concerne pas seulement l’attaquant qui la découvre : dès que l’enchaînement est visible publiquement, quiconque est assez rapide peut le reproduire. Ensuite, cela explique pourquoi les perspectives de récupération diffèrent ici de celles d’un vol classique. Kelp DAO a mis l’adresse réceptrice en pause à 06:03 UTC pour 24 heures et a constaté dans le même temps que ses propres contrats étaient intacts et que le rsETH restait intégralement couvert. La faille se trouvait dans un module sur mesure d’un wallet isolé, pas dans le jeton ni dans le protocole.

Ce n’est pas le premier cas : l’exploit SquidRouterModule du 25 mai 2026

Qui tient l’incident de septembre pour un cas isolé sous-estime le schéma. Le 25 mai 2026, une attaque a visé un module circulant sous le nom de SquidRouterModule. Selon les médias qui l’ont rapporté, au moins 86 wallets Safe sur Ethereum et Base étaient concernés ; le préjudice est estimé à 3,2 millions de dollars selon l’analyse, et à près de 4 millions de dollars sur un bon 300 transactions selon un autre relevé. L’opération a duré environ deux heures.

La voie d’attaque était différente et le résultat identique. Au lieu d’une entrée par DELEGATECALL, les attaquants ont utilisé la fonction executeSameChainActions() en se faisant passer pour des délégués habilités. Comme le module disposait déjà de droits étendus dans les wallets concernés, les contrats de wallet ont traité les ordres falsifiés comme authentiques. Le prestataire Squid a déclaré publiquement que le contrat exploité partageait seulement son nom avec sa propre architecture produit, sans aucun lien avec elle, et que ses utilisateurs et intégrateurs n’avaient pas été touchés.

Les deux cas conduisent à la même leçon. Le point faible d’une multisig est aujourd’hui rarement le seuil de signature. Il se situe dans les contrats auxquels le wallet a un jour permis de travailler à côté de ce seuil. Dans le choix de votre solution de conservation, c’est un critère qui n’apparaît dans quasiment aucune fiche produit ; notre comparatif des wallets matériels classe les appareils selon la part de contrôle qui vous reste réellement au moment de signer.

Vérifier les modules Safe : comment voir en cinq minutes ce qui est activé

La vérification en elle-même n’a rien de spectaculaire, et c’est précisément pour cela qu’elle est si souvent remise à plus tard. Il existe deux voies, et elles répondent à la même question.

Par l’interface : paramètres et liste des modules

Ouvrez votre wallet dans l’interface Safe et rendez-vous, dans les paramètres, à la rubrique Modules. Vous y trouverez les adresses de contrat activées pour ce wallet. Dans l’immense majorité des wallets privés, cette liste est vide, et c’est le bon cas de figure. Si quelque chose y figure, reprenez chaque adresse une à une et répondez à trois questions : vous rappelez-vous encore pourquoi vous avez activé ce module ? Utilisez-vous encore aujourd’hui l’application associée ? Et trouvez-vous, pour cette adresse, un prestataire identifiable assorti d’un rapport d’audit ?

Si l’une de ces questions reste sans réponse, le module a sa place sur la liste des retraits. La charge de la preuve pèse ici du côté de la conservation. Un module dont vous ne savez plus nommer la finalité continue malgré tout de fonctionner.

Par le contrat : getModules et isModuleEnabled

Qui veut la réponse indépendamment de toute interface interroge directement le contrat du wallet. La fonction de lecture getModules renvoie les adresses de tous les modules activés, et isModuleEnabled répond par oui ou par non, pour une adresse donnée, quant à son activation. Les deux appels sont de pures lectures : ils ne coûtent aucun frais, n’exigent aucune signature et s’exécutent depuis n’importe quel explorateur de blocs ou depuis un SDK.

La voie du contrat présente un avantage pratique. Elle vous montre l’état de la chaîne et non la présentation d’une application. Si une interface n’affiche pas un module pour une raison quelconque, celui-ci y figure malgré tout.

Retirer un module : pourquoi disableModule exige votre seuil de signature

La désactivation passe par la fonction de wallet disableModule. Contrairement à la consultation, il s’agit d’une véritable transaction. Elle coûte des frais de réseau et exige le nombre habituel de signatures de vos propriétaires. Dans l’interface Safe, vous lancez l’opération depuis la même liste de modules que vous venez de consulter ; les propriétaires confirment ensuite comme pour toute autre transaction.

Une particularité mérite d’être connue : les modules sont stockés dans le contrat sous forme de liste chaînée, et la désactivation requiert donc aussi l’adresse de l’entrée précédente. Les interfaces et les SDK insèrent cette valeur d’eux-mêmes. Qui construit la transaction à la main doit la déterminer, faute de quoi l’appel échoue.

Prévoyez le retrait à un moment où les frais de réseau sont bas et traitez plusieurs modules au cours d’une même session. Cela ne vaut pas pour la simple consultation : elle ne coûte rien et peut avoir lieu immédiatement.

Autorisations de jetons et modules : deux permissions, deux vérifications distinctes

C’est ici que naît régulièrement une confusion qui peut coûter cher. Une autorisation de jetons, approve dans le jargon des contrats, permet à un contrat tiers de prélever une quantité déterminée d’un jeton déterminé sur votre adresse. Un module, à l’inverse, permet à un contrat tiers d’agir dans votre wallet, et ce sur l’ensemble de vos avoirs.

L’écart de portée est considérable, et c’est pourquoi aucune des deux vérifications ne remplace l’autre. Qui a proprement révoqué ses autorisations peut malgré tout avoir un module actif disposant d’un accès complet. La manière de faire le ménage dans les autorisations et le coût d’une révocation au prix du gaz actuel sont décrits dans notre guide sur les autorisations de jetons sur Ethereum. Pour les modules, la vérification de la section précédente s’ajoute.

Ces deux vérifications ne concernent d’ailleurs que les wallets que vous gérez vous-même. Si votre solde se trouve sur une plateforme d’échange, c’est sa conservation qui décide, et la liste de contrôle y est tout autre.

Les enveloppes de restaking comme aEthrsETH : pourquoi les jetons emballés aggravent le dommage

Un aspect annexe du dossier mérite une attention propre. Le wallet concerné détenait son Ethereum sous forme plusieurs fois emballée : d’abord comme jeton de restaking liquide rsETH, puis une seconde fois comme aEthrsETH rémunéré sur le marché de prêt. Chaque emballage est un contrat de plus, qui apporte ses droits, ses règles et, le cas échéant, ses propres failles.

Pour vous, cela signifie surtout une chose : plus l’emballage est profond, plus longue est la chaîne des contrats qu’il faudrait vérifier pour comprendre réellement votre position. Qui construit son rendement par le restaking et le prêt devrait au moins savoir nommer les couches en jeu. Notre panorama des plateformes de staking indique pour chaque prestataire combien de couches de contrats séparent vous et votre ether.

Par souci d’exhaustivité : Kelp DAO a expressément déclaré le 15 septembre que ses propres contrats n’étaient pas concernés et que le rsETH restait couvert. L’emballage n’a pas causé le dommage. Il l’a rendu mobile dès lors que l’attaquant avait accès au wallet.

Obligation de signalement depuis le 11 septembre : ce que le Cyber Resilience Act change pour les fournisseurs de wallets

Pour vous, utilisatrice ou utilisateur en Allemagne, s’ajoute une nouveauté réglementaire qui modifie le traitement de telles failles. Depuis le 11 septembre 2026 s’appliquent les premières obligations de signalement du Cyber Resilience Act européen. Les fabricants de produits comportant des éléments numériques doivent signaler une vulnérabilité activement exploitée dans les 24 heures suivant sa connaissance, sous forme de notification préalable, à l’agence européenne ENISA et à l’équipe nationale compétente de réponse aux urgences informatiques ; la notification détaillée de vulnérabilité suit au plus tard après 72 heures. L’obligation couvre aussi les produits déjà mis sur le marché.

Les logiciels de wallet en relèvent, et nous avons analysé plus en détail les conséquences pour les prestataires dans notre article sur l’obligation de signalement des fabricants de portefeuilles. Concrètement, cela signifie : auprès d’un prestataire établi ou distribuant dans l’Union européenne, vous devriez désormais être informé rapidement d’une faille activement exploitée.

Cette protection a toutefois une limite, et le cas du 15 septembre la montre nettement. Le module défaillant n’était pas le produit d’un fabricant, mais un contrat sur mesure pour un wallet unique. Pour des contrats développés soi-même ou commandés à l’unité, personne ne vous prévient. Là, la vérification reste votre propre affaire.

Vérifier les modules Safe : ce qu’il faut en retenir

1. Consultez dès aujourd’hui votre liste de modules. Ouvrez les paramètres de votre wallet à contrat intelligent et lisez les adresses de contrat activées. Cela ne coûte ni frais ni signature. Si vous réfléchissez de toute façon à votre mode de conservation, comparez en parallèle la solution qui convient à vos avoirs : les appareils sont présentés côte à côte dans notre comparatif des wallets matériels.
2. Retirez ce que vous ne savez plus expliquer. Tout module dont vous ne savez plus nommer la finalité, ou dont vous n’utilisez plus l’application, doit être désactivé par disableModule. Prévoyez la transaction à un moment de frais bas. Si vous préférez conserver vos avoirs quotidiens dans un wallet sobre, sans logique de modules, vous trouverez les candidats dans notre comparatif des wallets logiciels.
3. Comptez les couches de votre position de rendement. Notez, pour chaque position emballée, quels contrats se trouvent entre vous et votre ether, et décidez si le rendement supplémentaire vaut cette chaîne. Les prestataires et leurs couches de contrats figurent dans notre panorama des plateformes de staking.

Le cas du 15 septembre n’est pas un argument contre les wallets à contrat intelligent. C’est un argument en faveur de la lecture de la seule liste que personne ne lit. Les détails de l’enchaînement ont été reconstitués par The Crypto Times le 15 septembre.

(Au 16 septembre 2026. Cet article ne constitue pas un conseil en investissement. Les cours et les grilles tarifaires évoluent ; vérifiez les conditions auprès du prestataire avant tout achat.)