Comment des attaquants ont siphonné $3.2M des portefeuilles Safe sur Ethereum et Base

Une vulnérabilité liée à un module tiers de portefeuille Safe a conduit au vol d'environ $3.2M sur Ethereum et Base après que des attaquants ont exploité des permissions d'exécution déléguée pour vider des dizaines de comptes intelligents en l'espace d'environ deux heures.

La société de sécurité blockchain Blockaid a indiqué que l'exploitation ciblait un contrat identifié comme SquidRouterModule, affectant au moins 86 portefeuilles Gnosis Safe, avant que les actifs volés ne soient convertis en Dai via des pools Uniswap V3 contrôlés par les attaquants.

Les données partagées par la société montrent que l'attaquant a ensuite consolidé le produit dans un portefeuille contenant environ 3,07 millions de DAI.

Les enregistrements on-chain liés par Blockaid ont identifié l'adresse de l'exploitant comme 0x9bdc730183821b6bb2b51be30b77c964fa645b91. 

Les données Etherscan citées par Lookonchain montrent que l'adresse avait été financée via Tornado Cash et avait enregistré 52 transactions le 25 mai.

La même enquête a également retracé un exemple de transaction de vidage exécutée à 06:25 UTC, où les actifs volés, notamment USDC, ENA et USDT, ont été acheminés via des pools de liquidité Uniswap V3 avant conversion.

Comment l'exploitation a-t-elle été exécutée ?

Les premières conclusions de Blockaid suggèrent que l'exploitation provenait d'un défaut à l'intérieur de la fonction executeSameChainActions() du module tiers, et non de l'infrastructure cœur de Safe. 

Selon la société, l'attaquant a déployé des contrats d'exploitation basés sur Foundry qui ont abusé du chemin d'exécution DelegateBundler du module pour usurper l'identité de délégués autorisés liés aux portefeuilles victimes.

Une fois les contrôles de vérification contournés, l'attaquant pouvait déclencher des swaps arbitraires directement depuis les Safes affectés sans nécessiter les approbations multisignatures habituelles requises par le système de portefeuille. 

Blockaid a indiqué que l'exploitation permettait à l'attaquant d'échanger des actifs légitimes contre un jeton sans valeur créé par l'attaquant identifié comme «u», avant que la liquidité ne soit retirée et que le produit ne soit converti en DAI.

Usurpation de délégué suspectée dans l'exploitation du module

Une analyse technique complémentaire partagée par Cos, fondateur de SlowMist, a suggéré que le problème n'était pas lié à des clés privées compromises. 

Dans un post traduit sur X, Cos a déclaré que les portefeuilles victimes échantillonnés étaient principalement configurés comme des Safes à signature unique appartenant à différents utilisateurs, tandis que la véritable faiblesse semblait provenir de modules de portefeuille vulnérables attachés à ces comptes.

Selon Cos, les attaquants ont pu falsifier des messages et contourner les contrôles de vérification des modules, permettant des opérations non autorisées de remboursement et de transfert depuis les portefeuilles Safe ciblés. 

Le chercheur a également désigné le même portefeuille de consolidation identifié par Blockaid, où les fonds volés auraient été réglés.

Portefeuille de l'attaquant contenant des DAI. Source : Etherscan.

L'exploitation reposait essentiellement sur le fonctionnement des modules Safe à l'intérieur des portefeuilles smart-contract. 

Contrairement aux transactions Safe standard qui exigent plusieurs approbations des propriétaires, les modules peuvent exécuter des actions directement dès que les utilisateurs leur accordent des permissions de confiance. 

Le défaut à l'intérieur du SquidRouterModule semble provenir d'une validation d'identité incorrecte, qui aurait permis à des charges utiles malveillantes de se faire passer pour des délégués approuvés.

Parce que le module possédait déjà de larges permissions d'exécution à l'intérieur des portefeuilles connectés, les requêtes falsifiées étaient apparemment traitées comme des instructions légitimes par les contrats Safe eux-mêmes.

Portefeuilles affectés non liés à Safe

Le PDG de Safe Labs, Rahul Rumalla, a déclaré plus tard que les comptes compromis «ne semblent pas être exploités sur le produit officiel Safe Wallet», ajoutant que les enquêteurs ne savent toujours pas où les portefeuilles ont été initialement créés et gérés.

Rumalla a indiqué que les portefeuilles affectés avaient probablement été déployés via des intégrations externes plutôt que par l'interface officielle de Safe.

Rumalla a également précisé que Safe Shield, le système d'alerte intégré de la société alimenté par Blockaid, avait déjà identifié le module comme malveillant avant l'incident.

Selon lui, le système de protection alerte les utilisateurs lorsque des modules ou des gardes non vérifiés demandent des permissions dangereuses.

Squid nie toute implication

De son côté, Squid a nié que son infrastructure de routage ou ses contrats centraux aient été compromis. 

Dans un communiqué publié sur X, l'équipe a déclaré que le contrat exploité partageait simplement le nom SquidRouterModule et n'avait aucun lien avec l'architecture du routeur de production de Squid.

Le protocole a ajouté que tous les utilisateurs et intégrateurs de Squid restaient indemnes, décrivant l'incident comme une exploitation d'un module de portefeuille smart tiers sans relation avec les contrats ou services officiels de Squid.

L'attaque s'ajoute à une liste croissante d'incidents de sécurité DeFi signalés en 2026. 

Comme rapporté précédemment par Invezz, la semaine dernière, Echo Protocol a subi une exploitation sur Monad après que des attaquants ont minté environ $76.7 million en eBTC non autorisés via ce que des chercheurs ont ensuite lié à une compromission d'une clé admin. 

Les enquêteurs dans ce dossier ont également indiqué que la blockchain elle-même n'avait pas été compromise, tandis que des contrôles opérationnels faibles entourant les permissions déléguées et l'autorité de mint ont permis à l'exploitation de s'étendre.