Faille FlashLoopAdapter : 305 000 Dollars Sortis Des Safes

Et si le coffre le plus soigné de votre setup DeFi n’était pas celui qui avait cédé, mais la petite pièce qu’on lui avait vissée dessus pour aller plus vite ? Le 1er octobre 2026, à 15 h 08 min 57 s UTC, deux wallets Safe sur Ethereum ont vu une stratégie de levier se défaire en quelques transactions. Le montant retenu par l’attaquant tourne autour de 114,09 ETH, soit environ 305 000 dollars au moment du signalement. Le protocole de prêt sous-jacent n’a pas flanché. C’est un module maison, le FlashLoopAdapter, qui a laissé passer une fausse identité.

L’histoire a tout d’un cas d’école, et c’est précisément pour cela qu’elle mérite mieux qu’un chiffre jeté en une. Deux coffres, un même propriétaire unique, une dette Aave remboursée avec de l’argent emprunté le temps d’un bloc, puis un collatéral en weETH retiré vers une adresse contrôlée par l’attaquant. Rien de spectaculaire au sens des grands braquages à neuf chiffres. Tout de révélateur, en revanche, sur la manière dont une permission trop large, posée sur un contrat auxiliaire, peut transformer une automatisation utile en levier d’extraction.

Ce qui s’est réellement passé, au-delà du montant

Le FlashLoopAdapter n’est pas un contrat du cœur d’Aave v3. C’est un adaptateur externe, pensé comme module Safe, pour ouvrir et fermer des positions à effet de levier. Les Safes qui l’avaient activé pouvaient s’en servir pour gérer des boucles : déposer un collatéral, emprunter, racheter ou réempiler l’actif, et recommencer. Pratique pour qui veut amplifier une exposition à un actif de staking liquide sans signer chaque étape à la main. Fragile, dès lors que la porte d’entrée du module ne vérifie pas vraiment qui frappe.

Selon l’alerte technique diffusée par SlowMist, les fonctions open() et close() se contentaient d’interroger ISafe(msg.sender).isModuleEnabled(address(this)). En clair : le contrat demandait à l’appelant s’il était un Safe ayant bien activé ce module, et il croyait la réponse. Un attaquant n’avait donc pas besoin de compromettre une clé. Il lui suffisait de déployer un faux Safe programmé pour répondre true à cette question. L’authentification devenait une politesse.

Une fois le faux Safe accepté, une seconde faiblesse prenait le relais. La fonction interne _swap() effectuait un appel brut vers un swapRouter, avec un swapCalldata fourni par l’appelant. Les deux paramètres étaient donc contrôlables. Au lieu d’un routeur d’échange ordinaire, l’attaquant a désigné l’un des Safes victimes comme « routeur ». Le calldata, lui, invoquait execTransactionFromModule, la fonction qui permet à un module déjà activé d’exécuter une transaction au nom du coffre. Le FlashLoopAdapter étant déjà habilité chez les victimes, l’appel a été accepté.

Le tour est presque élégant, et c’est ce qui le rend désagréable. On ne force pas une serrure Aave. On se fait passer pour un coffre autorisé, on se sert du module comme d’un messager, et on lui demande de parler au vrai coffre avec la voix d’un module de confiance. Le contrôle d’accès ne protégeait pas une identité. Il protégeait une réponse.

Pourquoi le protocole de prêt n’est pas le coupable désigné

Stani Kulechov, fondateur et dirigeant d’Aave, a été net : le contrat touché est un adaptateur tiers construit au-dessus d’Aave, avec un effet nul sur Aave v3. Defimon Alerts, qui a détecté l’attaque, a dit la même chose dans un autre vocabulaire. Le réseau est Ethereum. Le type de faille est un problème de contrôle d’accès. Le module ouvre et ferme des boucles Aave v3 pour les Safes qui l’ont activé. Les fonctions font confiance à tout expéditeur capable de répondre correctement à un test spoofable.

Ce n’est pas un contrat Aave v3, c’est un adaptateur externe tiers construit au-dessus d’Aave, effet nul sur Aave v3.

La distinction n’est pas un détail de communication. Elle change le périmètre du risque. Un utilisateur qui n’a jamais activé ce module n’est pas exposé par ce chemin-là. Un utilisateur qui l’a activé, en revanche, a donné à un contrat auxiliaire le droit d’agir sur son coffre sans repasser par le flux habituel des propriétaires. C’est le compromis classique des modules : moins de signatures, plus de surface.

On a déjà vu ce schéma. En mai, un module tiers relié à des coffres Safe a servi de voie d’extraction sur Ethereum et Base, pour un montant estimé entre 3 et 3,2 millions de dollars, répartis sur 86 wallets. Le routeur principal du service concerné et les fonds qui n’étaient pas passés par ce module étaient restés hors de portée. Quelques jours plus tard, des utilisateurs d’un service de paiement adossé à l’écosystème Safe avaient été invités à retirer leurs fonds après une faille touchant un module de délai. Le cofondateur Martin Köppelmann avait alors indiqué que la faiblesse pouvait permettre d’initier des transactions depuis les coffres équipés du module affecté.

Le film de l’extraction, transaction après transaction

L’attaque ne consistait pas à vider un solde oisif. Les actifs intéressants étaient engagés dans une position levier. Pour les sortir, il fallait d’abord éteindre la dette. L’attaquant a donc pris un prêt flash de WETH sur Morpho, cette liquidité empruntée le temps d’une transaction et remboursée avant la fin du même enchaînement. Avec ces fonds, il a remboursé environ 1 335 WETH de dette Aave appartenant au premier Safe, identifié comme 0xcfedf95a3653a128dfc2e4288758a1a1850d169f.

Le remboursement a libéré le collatéral attaché à la position. Par le chemin d’exécution compromis, le Safe a ensuite retiré environ 1 306 weETH vers une adresse contrôlée par l’attaquant. Un second coffre, 0xe3b23e47df7cd85876ac6cb05bdb9d7cd5b28520, a perdu 6,4 weETH par le même module vulnérable. Les deux Safes partageaient le même propriétaire unique. Ce détail ne prouve rien sur l’identité de la victime, mais il resserre l’incident : ce n’est pas une campagne de masse contre des milliers de coffres, c’est une stratégie précise contre une configuration partagée.

Une partie du weETH retiré a été échangée en WETH pour solder le prêt flash et les autres jambes de la transaction. Au bout du compte, l’attaquant conservait environ 114,1 ETH. SlowMist a chiffré la perte autour de 114,09 ETH et a noté qu’environ 1 300 WETH de dette avaient été remboursés pour déverrouiller le gage. Le retrait massif de collatéral n’est donc pas le produit net. Une grande part du capital qui a circulé servait à désendetter et à déboucler, avant que le reliquat puisse être gardé.

Étape	Ce que fait l’attaquant	Effet sur les coffres
1. Usurpation	Déploie un faux Safe qui répond toujours vrai au test du module	Les fonctions open et close s’ouvrent
2. Détournement d’appel	Fixe le routeur sur le Safe victime et le calldata sur execTransactionFromModule	Le module déjà activé exécute au nom du coffre
3. Prêt flash	Emprunte du WETH sur Morpho	Liquidité temporaire, sans capital initial durable
4. Remboursement	Rembourse environ 1 335 WETH de dette Aave	Le collatéral weETH devient retirable
5. Sortie	Retire environ 1 306 weETH, plus 6,4 weETH sur le second coffre	Les actifs quittent les Safes
6. Solde	Convertit une partie du butin et rembourse le flash loan	Environ 114 ETH restent à l’attaquant

SlowMist a identifié l’adresse de l’attaquant comme 0x42c2633438609881c8fBAb82414eb9A0c45F9353, et le contrat vulnérable comme 0x16bb8b912da187870c23ec6756bb3fad061283d8. Ces identifiants servent aux enquêteurs on-chain et aux équipes qui veulent vérifier si leur coffre a interagi avec le module. Ils ne remplacent pas une lecture du code. Une adresse, sans le contrôle d’accès qui l’entoure, ne dit pas si le risque est encore ouvert ailleurs.

Le callback qui n’a pas freiné la manœuvre

Defimon Alerts a ajouté un point souvent escamoté dans les récits trop linéaires. Les contrôles exécutés pendant le callback n’ont pas stoppé la transaction, parce que le contrat de l’attaquant jouait aussi le rôle de fournisseur de liquidité flash. Autrement dit, la pièce qui devait vérifier un comportement extérieur était tenue par la même main que celle qui fournissait les fonds. Quand l’arbitre et le joueur sont le même contrat, le carton rouge a peu de chances de sortir.

C’est un rappel utile pour quiconque lit un rapport d’audit en diagonale. Un callback n’est pas une garantie. C’est un moment où le contrat rend la main à un appelant, en espérant que cet appelant respecte un contrat moral que la blockchain, elle, ne fait pas respecter. Si l’appelant peut être choisi, ou s’il peut se substituer au fournisseur de liquidité attendu, le filet se retrouve du mauvais côté du terrain.

Le prêt flash n’est pas, en soi, l’arme du crime. C’est l’accélérateur. Sans capital préalable durable, l’attaquant a pu rembourser une dette de plus de mille WETH, libérer le gage, le déplacer, convertir ce qu’il fallait, puis rendre l’emprunt. Le profit naît de l’écart entre le collatéral libéré et la dette éteinte, une fois les frais et le routage absorbés. Ici, cet écart a laissé environ 114 ETH. Suffisant pour justifier l’opération. Trop modeste pour faire la une des méga-hacks. Assez précis pour montrer que la faille était exploitable de bout en bout.

Ce que fait vraiment une boucle de levier sur Aave

Pour comprendre pourquoi un module comme celui-ci existe, il faut revenir à la mécanique, sans romantisme. Un déposant place un actif, souvent un dérivé de staking liquide comme le weETH, en collatéral. Il emprunte un actif corrélé ou stable, souvent du WETH ou une stablecoin, puis réinvestit une partie de l’emprunt dans le même collatéral. La position grossit. Le rendement espéré du collatéral, ou l’exposition au prix, est amplifié. Le coût, c’est le taux d’emprunt et le risque de liquidation si le ratio de santé se dégrade.

Faire cela à la main demande plusieurs transactions, plusieurs signatures, et une fenêtre pendant laquelle le marché peut bouger. Un module Safe promet de compresser l’ouverture et la fermeture. Le coffre reste le propriétaire des fonds. Le module n’est qu’un exécutant habilité. Sur le papier, c’est propre. Dans la pratique, l’exécutant devient un employé qui a les clés de l’armoire. S’il obéit au premier inconnu qui se présente avec un badge imprimé maison, l’armoire n’est plus un coffre. C’est un comptoir.

Le weETH, ici, n’est pas un détail cosmétique. C’est un collatéral de staking liquide, adossé à de l’ether mis en validation, porteur d’un rendement et d’une décote ou d’une prime selon le marché. Le WETH, de son côté, est l’ether enveloppé, l’unité d’emprunt et de remboursement la plus liquide du réseau. La boucle joue sur cet appariement. L’attaquant n’a pas eu besoin d’inventer un actif. Il a utilisé la position déjà construite par la victime, en la démontant dans l’ordre qui lui était favorable : dette d’abord, gage ensuite.

Pourquoi le test isModuleEnabled ne suffit pas

Le point de rupture tient en une confiance mal placée. Demander à msg.sender s’il est un Safe légitime, c’est demander à un inconnu s’il est policier. Un vrai Safe implémente l’interface et répond selon son état interne. Un faux contrat peut implémenter la même fonction et répondre ce qu’il veut. L’interface n’est pas une preuve d’identité. C’est un costume.

Une vérification robuste aurait pu s’appuyer sur une liste explicite de coffres autorisés, enregistrée par un administrateur ou par les coffres eux-mêmes via une procédure qui ne dépend pas de la parole de l’appelant. Elle aurait pu exiger que l’appel vienne d’une transaction déjà validée par les propriétaires, ou d’un registre dont le module garde lui-même la trace. Elle aurait surtout dû interdire qu’un paramètre libre, routeur ou calldata, puisse rebondir vers execTransactionFromModule sur un Safe ayant activé le module.

Ce second étage est aussi important que le premier. Même avec une authentification bancale, un routeur figé et un calldata contraint auraient limité la casse. Ici, les deux étages étaient ouverts. L’usurpation donnait le droit d’entrer. Le calldata arbitraire donnait le droit de parler au coffre avec la voix du module. C’est la combinaison qui transforme une négligence en extraction.

Un précédent tout proche, déjà sur le même terrain

Le mois de septembre avait déjà montré qu’une permission accrochée à un module Safe peut suffire. Une affaire portant sur environ 2 900 rsETH avait été reliée à des contrôles d’autorisation faibles dans un contrat exécuteur branché sur un module activé. Un bot de MEV avait alors devancé la tentative, empoché les actifs, et laissé la transaction d’origine revenir en arrière. Le schéma n’est pas identique. Le résultat, lui, se ressemble : le module est la porte, le coffre est la pièce, et le premier arrivé repart avec ce qui peut être déplacé dans le même bloc.

Ces épisodes ne disent pas que Safe est cassé. Ils disent que Safe fait exactement ce qu’on lui demande. Un module activé peut exécuter. C’est une fonctionnalité, pas un bug du coffre. Le bug commence quand le module délègue cette puissance à n’importe quel appelant capable de mimer une interface. La sécurité d’un multisig ne se mesure pas seulement au nombre de signatures exigées pour une transaction manuelle. Elle se mesure aussi à la liste des contrats qui peuvent s’en passer.

Beaucoup d’équipes activent un module pour une stratégie, puis l’oublient. Le coffre continue de vivre. Le module aussi. Une mise à jour du routeur, un paramètre laissé libre, une fonction de swap trop généreuse, et l’oubli devient une surface. L’incident d’octobre ne invente pas ce risque. Il le rend lisible, avec des adresses, un montant et une séquence que n’importe quel analyste peut rejouer.

Ce que les chiffres ne disent pas tout de suite

305 000 dollars, c’est le résidu. 1 306 weETH, c’est le mouvement. La différence compte pour qui veut juger la gravité. Un titre qui annonce un drainage de plusieurs millions de collatéral exagère le butin et sous-estime la mécanique. Un titre qui ne parle que de 114 ETH minimise le fait qu’une position entière a été débouclée sans l’accord du propriétaire. Les deux lectures sont vraies, à des étages différents. Le préjudice net est le reliquat. L’atteinte au contrôle est le débouclage entier.

Il faut aussi garder une marge sur la valorisation. L’ether bouge. Le weETH n’est pas strictement égal à un ether au moment du swap, à cause du taux de conversion et du prix de marché. Les équipes de sécurité ont convergé autour de 114 ETH et de 305 000 dollars. Ce n’est pas une expertise judiciaire. C’est un ordre de grandeur solide, suffisant pour classer l’affaire parmi les incidents ciblés, pas parmi les effondrements de protocole.

Le propriétaire unique partagé par les deux coffres suggère une gestion concentrée. Cela peut être un opérateur individuel, une petite structure, ou un coffre de stratégie séparé d’un treasury plus large. Rien, dans les alertes publiques, ne nomme la victime. Rien n’indique non plus que d’autres Safes aient été touchés par cette même transaction. La prudence reste de mise : un module vulnérable activé ailleurs pourrait encore exposer des fonds, tant que les équipes n’ont pas désactivé le module ou migré les positions.

Comment lire une alerte sans se tromper de cible

Le réflexe, devant un titre qui associe Aave et une perte, est de croire que le marché du prêt lui-même a une brèche. Ici, les deux sources techniques et le fondateur du protocole disent le contraire. Aave v3 n’a pas été identifié comme le composant vulnérable. Les pools, les taux, les liquidations automatiques et les contrats principaux ne sont pas le chemin emprunté. Le chemin, c’est un adaptateur qui utilisait Aave pour gérer des positions détenues via des Safes.

Cette nuance protège autant qu’elle inquiète. Elle protège, parce qu’elle évite une panique hors sujet sur un protocole qui n’a pas été percé. Elle inquiète, parce qu’elle rappelle que l’écosystème réel d’un utilisateur n’est pas le protocole seul. C’est le protocole, plus le coffre, plus le module, plus le routeur, plus le calldata, plus le fournisseur de liquidité flash. La chaîne de confiance est aussi solide que son maillon le plus bavard.

On peut comparer cela à un immeuble dont la porte palière est saine, mais dont un prestataire a installé une boîte à clés « intelligente » dans le hall. Le cambrioleur ne force pas la porte. Il parle à la boîte. Les habitants qui n’ont pas souscrit au service ne sont pas concernés. Ceux qui ont laissé la boîte agir en leur nom le sont, même si le syndic jure que la structure du bâtiment n’a pas bougé. Les deux phrases peuvent être vraies en même temps.

Ce que devrait vérifier un détenteur de Safe dès maintenant

Pas besoin d’être auditeur pour faire le tri. La première question est simple : quels modules sont activés sur le coffre ? Un module oublié, déployé pour une stratégie de l’an dernier, a les mêmes droits qu’un module surveillé chaque semaine. La deuxième question porte sur le périmètre : le module peut-il appeler n’importe quelle adresse, ou seulement une liste fermée ? La troisième concerne les paramètres : un utilisateur, ou un attaquant, peut-il fournir le destinataire et le contenu de l’appel ?

Si la réponse à la troisième question est oui, le module n’est plus un assistant. C’est un interprète. Et un interprète qui exécute du bytecode fourni par l’appelant, au nom d’un coffre, mérite le même niveau de méfiance qu’une clé privée partagée. Désactiver un module inutilisé est souvent plus utile que de raffiner une stratégie. Une position levier peut se gérer avec des transactions signées, plus lentes, moins élégantes, et beaucoup plus difficiles à détourner par un faux Safe.

Les équipes qui ont construit ce type d’adaptateur ont, de leur côté, une liste courte. Figer les routeurs. Interdire les appels vers les coffres qui ont activé le module. Ne jamais croire msg.sender sur son propre statut. Enregistrer les Safes autorisés dans le contrat lui-même. Tester le scénario du faux Safe dans la suite de tests, pas seulement le scénario de l’utilisateur honnête. Un test qui ne tente pas de mentir ne prouve pas qu’on sait reconnaître un menteur.

Le rôle des prêts flash dans ce genre d’affaire

Morpho a fourni la liquidité temporaire. Cela n’en fait pas un complice. Un prêt flash est un outil neutre : il prête, il exige le remboursement dans la même transaction, il annule tout si le remboursement manque. L’attaquant s’en est servi comme d’un pont roulant. Sans cette grue, il aurait fallu avancer plus de mille WETH pour libérer le collatéral, ce qui change l’économie de l’attaque et le profil de celui qui peut la tenter.

C’est aussi pour cela que les incidents de ce type semblent surgis de nulle part. Il n’y a pas d’accumulation visible de capital sur l’adresse attaquante dans les jours précédents. Le capital arrive, travaille, repart, et laisse un solde. Les outils de surveillance qui ne regardent que les gros dépôts entrants ratent la séquence. Ceux qui surveillent les appels vers des modules Safe, les remboursements massifs de dette suivis d’un retrait de collatéral, et les changements de routeur dans le même bloc, voient la chose au moment où elle se produit. Defimon Alerts l’a vue à 15 h 08 UTC. C’est déjà après l’exécution. Sur Ethereum, après veut souvent dire trop tard pour les fonds.

La vitesse n’est pas un argument contre les prêts flash. C’est un argument pour des contrôles qui ne dépendent pas de la bonne volonté de l’appelant. Une transaction atomique est une bénédiction pour l’utilisateur honnête, qui ne veut pas rester à découvert entre deux blocs. C’est la même bénédiction pour l’attaquant, qui ne veut pas rester à découvert non plus. Le protocole de liquidité fait son métier. Le module, lui, n’a pas fait le sien.

Une affaire de permissions, pas de magie cryptographique

Rien, dans cette séquence, ne casse une signature, ne devine une seed, ni n’exploite une collision de hash. C’est presque décevant pour qui imagine encore les hacks comme des prouesses mathématiques. L’affaire est administrative. Une fonction répond oui. Une autre transmet un appel. Une troisième, côté Safe, obéit parce que le module est sur la liste. Le reste est de la plomberie DeFi ordinaire : emprunter, rembourser, retirer, échanger.

Cette banalité est la vraie leçon. Les grandes surfaces d’attaque de 2026 ne sont plus seulement les pools mal pricés ou les oracles manipulés. Ce sont les couches d’automatisation que les équipes posent entre le coffre et le protocole pour rendre une stratégie « one click ». Chaque clic économisé est une vérification déplacée. Si cette vérification est déléguée à l’appelant, elle n’existe plus.

Les intégrateurs qui branchent des modules sur des treasuries devraient traiter cette couche comme du code de production critique, pas comme un utilitaire. Un adaptateur de boucle touche à la dette et au collatéral. Il a donc, par construction, le pouvoir de vider la stratégie. Le soumettre au même niveau d’audit qu’un contrat de prêt n’est pas un luxe. C’est le minimum dès lors qu’il peut appeler execTransactionFromModule.

Ce que l’incident change pour les stratégies de looping

Le looping ne disparaît pas avec cette affaire. Le rendement sur collatéral de staking liquide, moins le coût d’emprunt, reste une stratégie lisible pour qui accepte le risque de liquidation et le risque de décote. Ce qui devrait disparaître, ou au moins se raréfier, c’est le module fourre-tout qui accepte un routeur et un calldata arbitraires. Une stratégie de boucle a un nombre fini d’opérations légitimes : déposer, emprunter, retirer, rembourser, échanger sur un routeur connu. Ce nombre fini peut être codé en dur.

Les utilisateurs, eux, peuvent séparer les coffres. Un Safe de stratégie, avec un module, ne devrait pas cohabiter avec la trésorerie longue. Si le module est compromis, la perte se limite à la position, pas à l’ensemble des actifs. Dans l’affaire d’octobre, les deux coffres touchés semblaient déjà dédiés. La perte est restée dans ce périmètre. Ce n’est pas un heureux hasard. C’est le bénéfice d’une segmentation que trop de treasuries négligent encore, par confort de gestion.

Il reste un point plus délicat. Désactiver le module après coup ne ramène pas les 114 ETH. Cela empêche une seconde passe. Pour les équipes qui reconnaissent leur adaptateur dans la description, la séquence responsable est publique : confirmer le contrat, demander aux utilisateurs de retirer l’habilitation, publier l’analyse, et ne pas se cacher derrière le protocole de prêt. Aave a déjà tracé la frontière. L’adaptateur doit assumer la sienne.

Les adresses, pour qui veut vérifier plutôt que croire

Trois identifiants structurent le dossier public. Le contrat FlashLoopAdapter pointé par SlowMist : 0x16bb8b912da187870c23ec6756bb3fad061283d8. L’adresse associée à l’attaquant : 0x42c2633438609881c8fBAb82414eb9A0c45F9353. Le premier Safe, celui dont la dette a été remboursée : 0xcfedf95a3653a128dfc2e4288758a1a1850d169f. Le second, amputé de 6,4 weETH : 0xe3b23e47df7cd85876ac6cb05bdb9d7cd5b28520. Ces chaînes ne sont pas des trophées. Ce sont des points d’entrée pour lire les traces internes, les appels de module et le remboursement du flash loan.

Une lecture utile ne s’arrête pas au solde final. Elle regarde l’ordre. Le faux appelant. Le test d’habilitation. Le passage par la fonction de swap. Le rebond vers le Safe. Le remboursement de la dette. Le retrait du weETH. La conversion partielle. Le remboursement Morpho. Quand cet ordre est cohérent d’un bout à l’autre, l’hypothèse d’une erreur d’utilisateur s’effondre. Ce n’est pas une signature maladroite. C’est une séquence construite.

SlowMist a classé l’incident comme une vulnérabilité de smart contract. Le classement est juste, à condition de préciser le contrat. Pas le pool. Pas le jeton. Pas le coffre en tant que standard. L’adaptateur. Cette précision évite deux erreurs symétriques : absoudre tout le monde sous prétexte que le cœur du protocole tient, ou accuser le protocole de prêt pour une pièce qu’il n’a pas écrite.

Pourquoi 114 ETH suffisent à justifier l’ingénierie

À l’échelle des exploits qui font vaciller un protocole, 305 000 dollars semblent presque modestes. À l’échelle d’une transaction bien préparée, c’est une récompense nette très élevée pour quelques heures de lecture de code. L’attaquant n’a pas eu à corrompre un oracle, ni à déplacer un marché entier. Il a eu à comprendre une condition, à écrire un faux Safe, à composer un calldata, et à emprunter le temps d’un bloc. Le rendement de l’effort est disproportionné. C’est exactement le profil des failles de contrôle d’accès : peu de théâtre, beaucoup de marge.

Ce profil attire aussi les suiveurs. Une fois la méthode publique, d’autres modules au même schéma deviennent des cibles. Le précédent de septembre sur un exécuteur branché à un module, l’affaire de mai sur un module de routage, l’alerte autour d’un module de délai : la famille est identifiable. Quiconque maintient un contrat qui appelle isModuleEnabled sur msg.sender et qui transmet ensuite un appel libre devrait relire son dépôt avant le prochain bloc chargé.

Il n’y a pas, à ce stade, d’élément public montrant une campagne élargie au-delà des deux coffres. L’absence de preuve n’est pas une preuve d’absence. Un module reste dangereux tant qu’il est activé et tant que le code vulnérable peut encore être appelé. La fenêtre de copie est le vrai risque secondaire de ce genre d’alerte. Publier la cause protège. Publier la cause sans que les utilisateurs désactivent le module prolonge l’exposition.

Le bon réflexe de lecture pour la suite

Garder trois phrases, et laisser le reste au bruit. Première phrase : le montant net retenu avoisine 114 ETH, pas les 1 306 weETH déplacés. Deuxième phrase : Aave v3 n’est pas le contrat faillé. Troisième phrase : un module Safe qui croit son appelant sur parole peut faire exécuter un coffre qui l’a habilité. Avec ces trois phrases, on peut lire les threads, les tableaux de bord et les rumeurs sans confondre la victime, l’outil et le protocole.

Le reste est une affaire de conception. Les boucles de levier continueront d’exister, parce qu’elles répondent à une demande réelle. Les modules continueront d’exister, parce que signer cinq transactions pour une stratégie que l’on ajuste souvent est un mauvais produit. La frontière saine se situe entre l’automatisation bornée et l’automatisation qui accepte n’importe quel ordre. Le FlashLoopAdapter, dans la version exploitée, avait franchi cette frontière. Deux coffres l’ont payé. Le protocole sur lequel ils s’appuyaient, non.

Pour le propriétaire des Safes, la journée du 1er octobre se résume à une stratégie débouclée par un tiers, un collatéral parti, une dette éteinte avec l’argent de l’attaquant, et un solde qui ne reviendra pas par un simple appel de fonction. Pour les autres détenteurs de modules, elle se résume à une question plus étroite, et plus utile : si un contrat que je n’ai pas écrit peut répondre à ma place, ai-je encore un coffre, ou seulement l’illusion d’en avoir un ?