1/4
Aperçu de l’exploitation
Le 15 septembre 2026, une faille d’autorisation grave au sein d’un exécuteur de stratégie a entraîné le vidage du portefeuille #Safe d’une personne fortunée. Cet incident a conduit à une perte approximative de 7,8 M$.
Comprendre la cause première
La vulnérabilité a été isolée à un exécuteur de stratégie non vérifié situé à l’adresse du contrat 0x4f0055926c839D1d960a82CBF84E2eE933958ebC. Il est important de souligner que ce défaut n’a pas été trouvé dans le protocole Safe core, et qu’il ne provenait ni d’Aave, ni de rsETH.
Dans des conditions de fonctionnement normales, le système impose que la cible soit un Safe approuvé, inscrit sur la liste blanche, et que le msg.sender soit un Module spécifiquement activé par ce Safe. Toutefois, le système a permis à tout appelant externe de contourner ces deux contrôles de sécurité essentiels simplement en définissant la cible comme address(this), ce qui renvoie à l’exécuteur lui-même.
Une fois ces vérifications contournées, l’auteur de la mauvaise action a exécuté un DELEGATECALL via un Module Safe déjà activé. Cela a permis à l’attaquant de traiter une logique arbitraire directement dans le contexte du Safe de la victime.
La séquence de l’attaque
Lors de l’exécution de l’exploit, l’attaquant a transféré environ 2 900 aEthrsETH dans un pool de liquidité Uniswap v4, en appariant les actifs avec un token PAT qui ne possède absolument aucune valeur. Par conséquent, le Safe compromis a été vidé de ses véritables actifs, laissant la victime sans rien d’autre que des NFT LP sans valeur.
Fait intéressant, la transaction d’attaque initiale ne s’est pas déroulée exactement comme prévu par le pirate. Un bot MEV appelé Yoink a réussi à devancer l’exploit, à intercepter la transaction et à s’enfuir avec l’intégralité de la pile de rsETH.
Aperçu de l’exploitation
Le 15 septembre 2026, une faille d’autorisation grave au sein d’un exécuteur de stratégie a entraîné le vidage du portefeuille #Safe d’une personne fortunée. Cet incident a conduit à une perte approximative de 7,8 M$.
Comprendre la cause première
La vulnérabilité a été isolée à un exécuteur de stratégie non vérifié situé à l’adresse du contrat 0x4f0055926c839D1d960a82CBF84E2eE933958ebC. Il est important de souligner que ce défaut n’a pas été trouvé dans le protocole Safe core, et qu’il ne provenait ni d’Aave, ni de rsETH.
Dans des conditions de fonctionnement normales, le système impose que la cible soit un Safe approuvé, inscrit sur la liste blanche, et que le msg.sender soit un Module spécifiquement activé par ce Safe. Toutefois, le système a permis à tout appelant externe de contourner ces deux contrôles de sécurité essentiels simplement en définissant la cible comme address(this), ce qui renvoie à l’exécuteur lui-même.
Une fois ces vérifications contournées, l’auteur de la mauvaise action a exécuté un DELEGATECALL via un Module Safe déjà activé. Cela a permis à l’attaquant de traiter une logique arbitraire directement dans le contexte du Safe de la victime.
La séquence de l’attaque
Lors de l’exécution de l’exploit, l’attaquant a transféré environ 2 900 aEthrsETH dans un pool de liquidité Uniswap v4, en appariant les actifs avec un token PAT qui ne possède absolument aucune valeur. Par conséquent, le Safe compromis a été vidé de ses véritables actifs, laissant la victime sans rien d’autre que des NFT LP sans valeur.
Fait intéressant, la transaction d’attaque initiale ne s’est pas déroulée exactement comme prévu par le pirate. Un bot MEV appelé Yoink a réussi à devancer l’exploit, à intercepter la transaction et à s’enfuir avec l’intégralité de la pile de rsETH.
