114 ETH Disparus : Le Module Safe, Pas Le Protocole Aave

On croit souvent qu’un coffre à plusieurs signatures dort tranquille dès lors que le protocole de prêt, lui, n’a pas bougé. Le 2 octobre 2026, cette idée a pris un coup. Environ 114,09 ETH ont quitté deux portefeuilles multisignatures, alors que les marchés d’Aave v3 n’ont enregistré aucune perte de leur côté. La société de sécurité SlowMist a décrit une exploitation de FlashLoopAdapter, un module personnalisé branché sur des coffres Safe pour piloter des positions à effet de levier. Le vol n’a pas percé le cœur d’Aave. Il a traversé une couche d’intégration que les propriétaires avaient eux-mêmes autorisée.

Le chiffre frappe moins par sa taille que par sa mécanique. Plus de 1 300 WETH empruntés ont d’abord été remboursés, le temps d’une transaction, pour libérer un collatéral composé surtout de weETH. Une fois le prêt instantané soldé et les frais réglés, il restait un bénéfice net d’environ 114 ETH. Autrement dit, la valeur qui aurait dû revenir aux détenteurs des deux coffres. Ce n’est pas un trou dans le protocole de prêt. C’est un trou dans la manière dont un module tiers parle au coffre, et dans la confiance que l’on place dans cette conversation.

Ce que l’on sait vraiment de cette disparition

SlowMist a signalé l’exploitation d’un module Safe conçu pour ouvrir ou fermer, en une seule transaction, des positions dites de looping sur Aave v3. L’attaquant a combiné deux faiblesses. D’un côté, un contrôle d’accès que l’on pouvait tromper. De l’autre, une fonction d’échange trop permissive. Les deux coffres visés avaient déjà activé FlashLoopAdapter. Le module disposait donc du droit d’appeler execTransactionFromModule, cette fonction qui permet à un module approuvé d’agir sans repasser par le seuil habituel de signatures.

Ni les contrats centraux d’Aave v3 ni ceux de Safe ne portaient la vulnérabilité exploitée. La perte vient d’un adaptateur externe. SlowMist n’a pas indiqué quelle équipe avait développé ou déployé ce module. Cette zone d’ombre compte. Quand on ne sait pas qui a écrit le code, on ne sait pas non plus qui doit corriger, qui doit prévenir, et qui assume le suivi des coffres encore branchés sur la même logique.

Une première lecture du code pouvait laisser croire que les fonctions d’ouverture et de fermeture étaient nues, sans garde-fou. Ce n’était pas le cas. Un contrôle existait. Il vérifiait que l’appelant était un portefeuille Safe ayant activé le module. Le problème tenait à la source de cette réponse. Le contrat interrogeait l’appelant lui-même. Quand la preuve dépend de celui qui a intérêt à mentir, la preuve ne prouve plus grand-chose.

Un contrôle d’accès qui se regardait dans un miroir

L’attaquant a déployé un faux contrat capable de se présenter comme un Safe. À chaque question du module, ce contrat répondait que FlashLoopAdapter était bien autorisé. Ce premier contournement ne suffisait pas, à lui seul, à vider les portefeuilles ciblés. Il ouvrait toutefois la porte d’entrée. Le module acceptait de parler à quelqu’un qui n’était pas le coffre légitime, parce que ce quelqu’un savait réciter la bonne phrase.

En sécurité logicielle, on appelle parfois cela une vérification réflexive. Le programme demande à l’extérieur une information que l’extérieur a tout intérêt à inventer. Un coffre multisignature sérieux ne se contente pas d’une déclaration. Il s’appuie sur un registre, sur une adresse connue, sur un état que l’appelant ne peut pas réécrire à sa guise. Ici, la déclaration tenait lieu de registre.

Un module qui demande à son interlocuteur s’il a le droit d’entrer ne filtre personne. Il enregistre une réponse.

Ce genre de faille n’a rien d’exotique. On la retrouve dès qu’un contrat délègue la vérité à un autre contrat sans ancrer cette vérité dans un stockage qu’il contrôle. Le faux Safe n’avait pas besoin d’imiter toute la complexité d’un portefeuille à plusieurs propriétaires. Il lui suffisait d’imiter la fonction interrogée. Le reste du théâtre pouvait rester vide.

La fonction d’échange, second verrou ouvert

La seconde faiblesse se trouvait dans la fonction interne d’échange. Elle laissait l’utilisateur fournir librement l’adresse du routeur et les données d’appel associées. L’attaquant pouvait donc orienter le module vers un contrat de son choix et lui faire exécuter des instructions arbitraires. Ce n’est plus un échange. C’est une télécommande.

Dans une intégration saine, le routeur est fixé, ou choisi dans une liste blanche. Les données passées au routeur sont contraintes. On limite les tokens, les montants, le destinataire des fonds, parfois même le glissement de prix. Ici, l’appelant choisissait la destination et le contenu de l’appel. Combiné au droit d’agir au nom du coffre, ce champ libre devenait un passage vers n’importe quelle action que le module était autorisé à signer.

Les deux failles se complétaient. Le faux contrat franchissait le contrôle d’accès. Le routeur libre transformait cette entrée en exécution arbitraire. Sans la seconde, la première restait une porte entrebâillée. Sans la première, la seconde n’aurait pas dû être accessible depuis l’extérieur dans les conditions décrites. Ensemble, elles ont suffi.

Pourquoi le multisignature n’a pas arrêté le mouvement

Un coffre Safe protège les mouvements tant que chaque action repasse par le seuil de signatures. Dès qu’un module autorisé peut appeler execTransactionFromModule, cette protection change de nature. Le module devient un signataire permanent, sans date de péremption. Il n’a pas besoin de réunir les propriétaires à chaque fois. Il a déjà été admis.

FlashLoopAdapter était légitimement activé sur les deux coffres victimes. L’attaquant n’a pas eu à convaincre les signataires au moment du vol. Il a utilisé un droit déjà accordé, en se faisant passer pour un contexte autorisé, puis en détournant l’échange. Les permissions de module n’expirent pas toutes seules. Elles restent là, y compris quand la stratégie qui les justifiait n’est plus suivie, y compris quand le code du module n’a plus été relu depuis des mois.

C’est le point que SlowMist a souligné. Un portefeuille multisignature ne protège plus chaque mouvement dès lors qu’un module approuvé peut agir sans repasser par le seuil. La recommandation qui en découle est simple, et pourtant rarement tenue. Vérifier régulièrement les modules actifs. Désactiver ceux qui ne servent plus. Traiter une autorisation de module comme une clé, pas comme un réglage cosmétique.

Le looping, cette stratégie que le module devait servir

Le looping consiste à déposer un actif en garantie, à emprunter, souvent du WETH, puis à redéposer ce qui a été emprunté ou ce qui a été obtenu après conversion, afin d’amplifier l’exposition. On cherche un écart entre le rendement du collatéral et le coût de l’emprunt. On cherche aussi, parfois, des récompenses de protocole. Plus la boucle est serrée, plus le gain potentiel grossit, et plus la marge de sécurité se réduit.

Faire cela à la main demande plusieurs transactions, plusieurs signatures, plusieurs fenêtres pendant lesquelles le prix peut bouger. Un adaptateur comme FlashLoopAdapter promettait de condenser l’ouverture ou la fermeture en un seul geste. C’est pratique. C’est aussi un concentré de droits. Le module doit pouvoir déposer, emprunter, échanger, rembourser, retirer. Chaque verbe est une autorisation. Si l’un de ces verbes peut être détourné, toute la chaîne suit.

Sur Aave v3, ce type de position s’appuie sur les règles ordinaires du marché. Facteur de collatéral, seuil de liquidation, taux d’emprunt variable ou stable selon les pools, plafonds d’offre et d’emprunt. Rien de tout cela n’a été cassé dans l’incident. Le protocole a fait ce qu’on lui demandait. Il a accepté un remboursement de dette. Il a libéré le collatéral. Il a agi en caissier, pas en victime.

Le rôle du prêt instantané dans la sortie des fonds

Pour récupérer le collatéral, surtout du weETH, il fallait d’abord solder les emprunts. L’attaquant a utilisé un flash loan, un prêt obtenu et remboursé dans la même transaction. Plus de 1 300 WETH de dette ont été remboursés. Le collatéral s’est débloqué. Le prêt instantané a été rendu, frais compris. Le reliquat, environ 114,09 ETH, correspondait à la valeur restante des positions.

Le prêt instantané n’est pas la faille. C’est l’outil qui a rendu l’opération autonome en capital. Sans lui, il aurait fallu avancer plus de 1 300 WETH. Avec lui, le coût d’entrée se limite aux frais et au gaz, à condition que la transaction se referme. Si une étape échoue, tout s’annule. C’est pour cela que ces attaques se présentent souvent comme un bloc unique, propre, presque comptable.

On peut lire la séquence ainsi. Entrer par le faux Safe. Prendre la main sur l’échange. Emprunter en flash la somme nécessaire. Rembourser la dette Aave des coffres. Retirer le collatéral. Rendre le flash loan. Garder l’écart. Chaque étape est légitime isolément. L’illégitimité tient au droit d’enchaîner ces étapes au nom de coffres qui n’avaient pas signé ce jour-là.

Aave v3 est resté en dehors du trou

Il faut le répéter, parce que les titres glissent vite. Les marchés d’Aave v3 n’ont pas subi de perte protocolaire. Les prêteurs du pool n’ont pas été ponctionnés par une faille du cœur. La dette remboursée était une dette réelle, adossée à un collatéral réel. Le protocole a libéré ce collatéral parce que la dette avait été payée. C’est son métier.

Confondre une perte d’utilisateur et une perte de protocole change la réponse. Si Aave avait été compromis, il faudrait geler des marchés, patcher des contrats, parfois coordonner une gouvernance d’urgence. Ici, le correctif ne se situe pas dans le code d’Aave. Il se situe chez ceux qui installent des modules, chez ceux qui les auditent, et chez ceux qui laissent des autorisations dormir.

Cela n’absout pas l’écosystème. Aave est devenu une brique sur laquelle d’autres construisent des stratégies automatisées. Plus la brique est solide, plus les couches du dessus se multiplient. Chaque couche ajoute une surface. Le protocole peut être intact et l’utilisateur ruiné. Les deux phrases sont vraies en même temps.

Safe, le coffre, et la confiance déléguée

Safe, longtemps connu sous le nom de Gnosis Safe, est devenu l’armature standard des trésoreries et des coffres partagés. Son modèle de modules est puissant. Un module approuvé peut exécuter des transactions selon une logique programmée. On s’en sert pour des automatisations, des limites de dépense, des stratégies de rendement, des récupérations. La puissance est le risque.

Les contrats centraux de Safe n’ont pas présenté la vulnérabilité exploitée. Le coffre a obéi à un module qu’il avait le droit d’obéir. C’est exactement le comportement attendu. La faille vivait dans l’adaptateur, pas dans le standard. Pour l’utilisateur, la distinction est froide. Les fonds sont partis. Le standard a tenu. Les deux constats coexistent.

Une habitude dangereuse consiste à activer un module pour une campagne, une saison de récompenses, une fenêtre de taux, puis à l’oublier. Le module reste. Le marché change. Le code, lui, conserve ses droits. SlowMist recommande une revue régulière. Cette revue devrait être datée, notée, et liée à une décision explicite de maintien ou de retrait.

weETH, collatéral liquide et effet de levier

Le collatéral mentionné était principalement du weETH, une représentation liquide d’ether mis en staking. Ce type d’actif est prisé dans les boucles. Il porte un rendement de staking, il peut servir de garantie, et il se prête à des allers-retours avec l’ether ou le WETH. L’écart entre rendement et coût d’emprunt fait vivre la stratégie. Il fait aussi vivre l’illusion que le levier est un détail technique.

Dans l’incident, le weETH n’est pas le coupable. Il est la matière que l’on voulait récupérer une fois la dette effacée. Sa liquidité et son acceptation comme collatéral ont rendu la position possible. Ils ont aussi rendu la sortie possible. Un actif moins accepté, moins liquide, moins bouclable, n’aurait peut-être pas attiré le même module. Il n’aurait peut-être pas non plus concentré autant de valeur dans deux coffres automatisés.

Les dérivés de staking liquide ajoutent une couche de contrat entre l’ether et le coffre. Cette couche n’a pas été le vecteur décrit par SlowMist. Elle rappelle toutefois que une position de looping n’est jamais un simple dépôt. C’est un empilement. Staking, jeton liquide, marché de prêt, module d’automatisation, routeur d’échange. Chaque étage peut tenir. L’étage du milieu peut céder.

Ce que SlowMist a montré, et ce qu’il n’a pas dit

Le signalement détaille l’enchaînement. Contrôle d’accès falsifiable. Fonction d’échange ouverte. Module déjà actif. Exécution via le droit de module. Remboursement massif par prêt instantané. Sortie nette d’environ 114,09 ETH. C’est un récit technique utile, parce qu’il sépare le protocole intact de l’intégration cassée.

Ce qui manque, publiquement, c’est le nom de l’équipe derrière l’adaptateur. L’absence n’est pas un détail de forme. Sans nom, les autres utilisateurs du même code ne savent pas s’ils sont concernés. Sans nom, on ne sait pas si un correctif existe, si les coffres restants ont été prévenus, si le module a été retiré des interfaces. La sécurité après incident dépend autant de la diffusion que de l’analyse.

Il manque aussi, dans ce que l’on peut affirmer sans inventer, l’identité de l’attaquant, le devenir exact des fonds après la transaction, et le niveau d’audit préalable du module. Ces trous ne changent pas le mécanisme. Ils limitent les leçons nominatives. On peut apprendre la forme de la faille. On ne peut pas, à ce stade, apprendre le parcours organisationnel qui a mené à son déploiement.

Une transaction, deux coffres, une même logique

Que deux coffres aient été touchés suggère une configuration partagée. Même module, mêmes droits, même surface. Quand un adaptateur est copié d’une trésorerie à l’autre, la faille se copie avec lui. Le multisignature protège contre un signataire isolé. Il ne protège pas contre un modèle répété sans relecture.

On imagine souvent l’attaque comme un coup unique contre une cible unique. Ici, la cible est un patron d’intégration. Quiconque avait activé le même module, avec la même fonction d’échange libre et le même contrôle réflexif, se trouvait dans le périmètre. Deux coffres ont perdu des fonds. Le nombre de coffres encore exposés au moment du signalement n’a pas été chiffré dans le récit public.

C’est une raison de plus pour traiter l’alerte comme une consigne de ménage, pas comme une anecdote. Désactiver le module si on le reconnaît. Vérifier les autres modules qui acceptent un routeur libre. Relire les fonctions qui demandent à l’appelant de prouver qui il est.

Le faux contrat, une imitation minimale

Imiter un Safe entier serait lourd. Imiter la réponse attendue est léger. Le module ne demandait pas une preuve cryptographique indépendante de l’identité du coffre. Il demandait une confirmation. Le faux contrat confirmait. Cette économie de moyens est typique des exploits propres. On ne casse pas la cryptographie. On casse l’hypothèse.

L’hypothèse était celle-ci. Si quelqu’un répond comme un Safe ayant activé le module, alors c’est un Safe ayant activé le module. L’hypothèse est fausse dès que la réponse est produite par le questionné. Un registre externe, une adresse figée, un événement d’activation vérifié sur un contrat connu, auraient changé la donne. Le code a préféré la commodité d’une question directe.

Cette commodité se vend bien dans les intégrations rapides. On veut que n’importe quel coffre puisse brancher le module sans liste blanche centrale. On veut de la composabilité. La composabilité sans ancrage devient une invitation. Le faux contrat n’a fait qu’accepter l’invitation.

Routeur libre, données libres, conséquence lourde

Laisser l’utilisateur choisir le routeur peut sembler flexible. Un jour on passe par un agrégateur, le lendemain par un autre, selon la liquidité. La flexibilité a un prix si elle n’est pas bornée. Une adresse quelconque plus des données quelconques, c’est un appel arbitraire. Dans un module qui peut déjà mouvoir les fonds du coffre, l’appel arbitraire est une clé universelle.

Les intégrations prudentes figent le routeur, ou n’acceptent que des sélecteurs connus. Elles vérifient que les tokens sortants correspondent à l’intention. Elles imposent un destinataire égal au coffre. Elles plafonnent le montant. Aucune de ces bornes n’est décrite comme présente dans la fonction interne d’échange de FlashLoopAdapter. L’attaquant a donc pu viser son propre contrat et dicter les instructions.

On peut corriger ce motif sans renoncer aux stratégies de looping. Il suffit de séparer l’intention et l’exécution. L’intention dit quel actif entre, quel actif sort, quel montant maximal part. L’exécution ne peut pas sortir de ce cadre. Le routeur devient un prestataire, pas un souverain.

Ce que cette affaire dit des couches d’intégration

La finance décentralisée s’est construite par empilement. Un protocole de prêt. Un coffre. Un module. Un routeur. Un jeton de staking liquide. Chaque brique publie une interface. Chaque brique fait confiance à la brique d’à côté pour respecter le sens de cette interface. Quand la confiance est mal placée, l’empilement transmet le choc vers le haut, vers les fonds, pas vers le protocole du bas.

Les utilisateurs avancés aiment ces couches parce qu’elles économisent des signatures et des allers-retours. Les attaquants les aiment pour la même raison. Une seule transaction bien construite remplace une semaine de social engineering. Il n’y a pas eu, dans le récit disponible, de hameçonnage des signataires au moment du vol. Il y a eu une autorisation ancienne, réutilisée.

C’est plus discret qu’une faille de protocole, et parfois plus rentable à l’échelle d’une cible. 114 ETH ne font pas la une des plus grands exploits de l’histoire. Ils suffisent à ruiner une stratégie, une trésorerie de taille moyenne, une expérimentation que l’on croyait encadrée par le multisignature.

Comparer sans mélanger les dossiers

D’autres alertes récentes ont touché des validateurs, des interfaces, des ponts, des modules. Les rapprocher aide à voir un motif. Les mélanger aide à se tromper de responsable. Ici, le motif est l’autorisation déléguée. Ailleurs, ce peut être une clé compromise, un oracle, une erreur de mise à jour. Le bon réflexe est de nommer la couche, puis seulement la marque.

Aave a déjà traversé des débats sur sa gouvernance, ses marchés, ses paramètres de risque. Aucun de ces débats n’est le sujet du 2 octobre. Le sujet est un adaptateur tiers. Le garder distinct protège la lecture. Cela évite de demander un correctif là où il n’y a pas de bug, et d’oublier le correctif là où il y en a un.

Safe, de son côté, n’a pas à réécrire son modèle de modules pour cet incident. Il a à être compris. Un module est une délégation. Une délégation se révoque. Tant que cette phrase n’est pas un rituel, les coffres les mieux signés resteront poreux par le côté.

Une check-list concrète pour les détenteurs de coffres

La leçon opérationnelle tient en quelques gestes, à refaire sans attendre une alerte. Lister les modules actifs. Pour chacun, noter qui l’a proposé, quand il a été activé, ce qu’il peut faire, et s’il est encore utilisé. Si la réponse à l’une de ces questions est floue, le module est déjà un risque.

• Désactiver tout module de stratégie dont on ne relit plus le code.
• Refuser les fonctions qui acceptent un routeur et des données libres.
• Exiger un contrôle d’accès ancré dans un registre, pas dans la réponse de l’appelant.
• Limiter les montants qu’un module peut mouvoir, quand le standard le permet.
• Séparer le coffre de trésorerie et le coffre d’expérimentation.
• Prévoir une révocation rapide, avec les signataires déjà alignés.

Aucune de ces lignes ne remplace un audit. Elles réduisent le temps pendant lequel une erreur reste armée. Le coût d’une révocation est une transaction. Le coût d’un oubli, dans ce dossier, se mesure en ether.

Ce que les équipes qui déploient des modules devraient graver

Publier le code ne suffit pas. Il faut dire quels coffres sont compatibles, quels droits sont demandés, quels routeurs sont autorisés, et comment révoquer. Il faut un canal d’alerte. Il faut un propriétaire identifiable. L’anonymat du déploiement, dans ce signalement, laisse les utilisateurs sans interlocuteur.

Un module de looping devrait traiter l’échange comme une opération bornée. Adresse de routeur fixe ou liste blanche. Sélecteur limité. Destinataire égal au coffre. Montant plafonné par l’intention. Contrôle d’accès lu depuis le contrat Safe connu, pas depuis l’appelant. Ces contraintes sont ennuyeuses. Elles sont le prix de la délégation.

Les audits, quand ils existent, devraient chercher précisément ces deux motifs. La vérification réflexive. L’appel arbitraire. Ce sont des classiques. Les rater n’est pas une fatalité de la décentralisation. C’est une relecture incomplète.

Le chiffre de 114 ETH, et ce qu’il mesure vraiment

Le bénéfice net annoncé, environ 114,09 ETH, n’est pas le volume brassé. Le volume brassé comprend le remboursement de plus de 1 300 WETH. Le net est ce qui reste après restitution du prêt instantané et paiement des frais. C’est la part qui aurait dû revenir aux propriétaires. La présenter comme un petit incident parce que le net est inférieur au brut serait une erreur de lecture.

Pour les coffres concernés, 114 ETH peuvent représenter la marge entière d’une stratégie, parfois le capital. Pour le marché, c’est un signal de surface. Les stratégies automatisées sur Aave concentrent des droits étendus dans peu de contrats. Un contrat mal borné suffit. Le protocole peut encaisser le choc sans sourciller. Les coffres, non.

Il faut aussi distinguer perte comptable et perte récupérable. Rien, dans le récit public, n’indique un gel, un remboursement ou une négociation. Tant qu’un tel élément n’est pas établi, la somme doit être lue comme sortie. L’espoir d’un retour ne fait pas une information.

Pourquoi le titre ne doit pas dire qu’Aave a été piraté

La tentation médiatique est forte. Aave est un nom connu. FlashLoopAdapter ne l’est pas. Accrocher le nom connu au verbe voler fait cliquer. Cela fait aussi mal diagnostiquer. Les prêteurs peuvent retirer par peur. Les marchés peuvent se tendre. La gouvernance peut être sommée d’agir sur un code qui n’a pas failli.

Le titre juste est plus long, et plus utile. Deux coffres ont perdu des fonds à cause d’un module tiers branché sur Safe, utilisé pour des boucles sur Aave. Aave n’a pas été compromis. Safe n’a pas été compromis dans son cœur. Le module l’a été, par conception fragile. Cette phrase tient en quelques lignes. Elle évite une panique mal placée et une indifférence mal placée.

Les lecteurs qui détiennent des positions sur Aave sans module externe ne sont pas dans le périmètre décrit. Les lecteurs qui ont activé des adaptateurs de looping le sont potentiellement, jusqu’à preuve du contraire. Le tri se fait par les autorisations, pas par le logo du protocole de prêt.

La composabilité, promesses et facture

On vante la composabilité comme la capacité d’assembler des protocoles comme des pièces. L’image est jolie tant que chaque pièce refuse les assemblages dangereux. Un module qui accepte n’importe quel routeur n’est pas une pièce. C’est une prise universelle branchée sur le coffre.

La facture arrive rarement le jour de l’installation. Elle arrive quand quelqu’un lit le code avec une intention adverse, ou quand un oubli devient une opportunité. Entre les deux, la stratégie peut même avoir gagné de l’argent. Le gain passé ne valide pas le contrôle d’accès. Il endort la relecture.

Une composabilité adulte documente ses hypothèses. Elle dit quels contrats elle interroge. Elle dit quelles adresses elle appelle. Elle échoue fermé quand une hypothèse casse. FlashLoopAdapter, tel que décrit, échouait ouvert. L’appelant douteux était cru. Le routeur inconnu était appelé.

Le temps d’une transaction, la fenêtre entière

Les exploits de ce type se jouent dans un bloc. Il n’y a pas de négociation, pas de délai de réflexion, pas de seconde signature. C’est l’inverse du rythme humain d’un multisignature, où l’on attend les confirmations. Le module a précisément été créé pour supprimer cette attente. L’attaquant a utilisé la suppression.

Cela ne condamne pas l’automatisation. Cela impose un filet. Pause d’urgence. Plafond journalier. Destinataire figé. Alerte lors d’un appel vers une adresse inédite. Ces filets existent dans certaines conceptions de modules. Ils n’apparaissent pas dans la description de l’adaptateur exploité.

Après coup, la transaction reste lisible sur la chaîne. C’est un avantage de ces systèmes. On peut reconstituer le remboursement, le retrait, le remboursement du flash loan. La lisibilité n’est pas une protection. C’est une archive. L’archive confirme. Elle ne rend pas les fonds.

Ce que les prêteurs d’Aave peuvent retenir

Si vous déposez sur Aave sans coffre modularisé, cet incident ne décrit pas une perte de votre dépôt. Le pool a reçu un remboursement de dette. Il n’a pas été drainé par une faille du marché. Votre risque reste celui du protocole, des paramètres, de l’oracle, de la liquidité. Pas celui de FlashLoopAdapter, sauf si vous avez vous-même branché ce module.

Si vous prêtez indirectement via une stratégie qui boucle, la question change. Qui tient le module. Quels droits il a. Si le coffre qui porte votre position a activé un adaptateur à routeur libre. La réponse ne se trouve pas dans le taux affiché. Elle se trouve dans les autorisations.

Les interfaces grand public masquent souvent cette couche. On voit un rendement. On ne voit pas le module. Demander la liste des modules devrait être aussi banal que demander l’adresse du contrat. Tant que ce n’est pas le cas, le rendement affiché est incomplet.

Une lecture pour les trésoreries

Les organisations qui gardent des fonds sur Safe ajoutent des modules pour aller plus vite que leurs signataires. La vitesse est un choix. Elle devrait être chiffrée. Quel montant maximal le module peut-il sortir en une transaction. Quelle stratégie justifie encore ce droit. Qui relit le code après une mise à jour.

Une trésorerie peut très bien utiliser Aave sans jamais activer de module de looping. Le dépôt et l’emprunt repassent alors par les signatures. C’est plus lent. C’est aussi plus proche de la promesse du multisignature. Le jour où l’on ajoute un module, on change de produit. Il faut le dire dans la procédure interne, pas seulement dans le fil de discussion technique.

L’incident du 2 octobre est un cas d’école pour ces procédures. Deux coffres. Un module. Une imitation. Un appel libre. Une sortie nette. On peut le ranger dans un classeur. On peut aussi s’en servir pour retirer, cette semaine, les autorisations dont plus personne ne se souvient.

Le staking liquide dans la boucle, sans en faire le coupable

weETH et ses cousins servent souvent de collatéral parce qu’ils portent un rendement tout en restant mobilisables. La boucle amplifie ce rendement et amplifie le risque de liquidation. Dans cette affaire, la liquidation n’est pas le scénario décrit. Le scénario est un retrait volontaire, exécuté par un module détourné, après remboursement de la dette.

Il reste utile de rappeler que le collatéral liquide n’est pas de l’ether dormant. Son prix, sa décote, son contrat, ses files d’attente de retrait, tout cela pèse sur une position levée. Ici, ces facteurs ont été contournés par la mécanique de l’attaque. L’attaquant n’a pas attendu une décote. Il a effacé la dette et pris l’actif.

Les détenteurs de positions weETH sur Aave qui n’utilisent pas ce module ne doivent pas lire l’alerte comme une faille du jeton. Ils doivent la lire comme un rappel. La couche la plus proche des fonds n’est pas toujours le protocole le plus célèbre.

Ce qui resterait à éclaircir

Plusieurs questions restent ouvertes, et il vaut mieux les laisser ouvertes que les combler par invention. Qui a écrit FlashLoopAdapter. Combien de coffres l’avaient activé. Les autres ont-ils révoqué. Les fonds ont-ils été mêlés, pontés, ou laissés visibles. Un audit public existait-il. Aucune de ces réponses n’est nécessaire pour comprendre le mécanisme. Toutes sont nécessaires pour clore le dossier.

SlowMist a fait la part utile. Séparer Aave, Safe et le module. Décrire les deux faiblesses. Donner l’ordre de grandeur du net et du remboursement. Le reste appartient aux équipes concernées, si elles se manifestent, et aux utilisateurs qui peuvent encore couper le droit.

En attendant, la prudence consiste à considérer tout module de looping non relu comme suspect, pas à considérer Aave comme percé. Le tri est plus exigeant qu’un titre. Il est aussi plus juste.

Une chronologie simplifiée de l’opération

On peut résumer l’enchaînement sans prétendre reconstituer chaque appel interne. Un contrat imitant la réponse d’un Safe se présente. Le module accepte. L’échange est dirigé vers une adresse contrôlée par l’attaquant, avec des données choisies. Le droit de module, déjà accordé sur les vrais coffres, sert à exécuter. Un flash loan avance plus de 1 300 WETH. La dette est remboursée. Le collatéral sort. Le flash loan rentre. Environ 114,09 ETH restent.

Cette chronologie explique pourquoi le contrôle d’accès seul ne suffisait pas, et pourquoi l’échange seul n’aurait pas dû être atteignable dans ces conditions. Les deux maillons ont cédé ensemble. C’est souvent ainsi que les exploits tiennent. Un maillon faible attire le regard. Le second le transforme en vol.

Pour un lecteur non développeur, l’image utile est celle d’un employé à qui l’on a donné un badge permanent, et d’une procédure qui demande au visiteur s’il est l’employé. Le visiteur dit oui. Le badge ouvre. Le coffre-fort du bâtiment, lui, n’a pas été forcé. Il a été utilisé avec un badge que quelqu’un avait délivré plus tôt.

Garder la mesure, garder la leçon

114 ETH ne redessinent pas le marché de l’ether. Ils redessinent, pour deux coffres, le sens du mot protection. Un multisignature sans revue des modules est une protection partielle. Un protocole de prêt intact ne garantit pas l’intégrité des stratégies construites dessus. Un module pratique peut être le maillon le plus faible, précisément parce qu’il concentre les droits que l’on voulait automatiser.

La phrase à retenir est courte. La faille ne venait pas d’Aave. Elle venait d’un adaptateur que des coffres Safe avaient autorisé, et dont le contrôle d’accès se laissait convaincre par un imitateur, pendant que sa fonction d’échange acceptait n’importe quelle destination. Le reste est une conséquence. Remboursement, retrait, prêt instantané rendu, solde net envolé.

Ceux qui n’ont rien branché de tel peuvent continuer à distinguer le protocole et la surcouche. Ceux qui ont branché un module proche devraient ouvrir la liste des autorisations avant d’ouvrir une autre position. La chaîne n’oubliera pas le module à leur place.

Pourquoi ce type d’alerte reviendra

Tant que le rendement du collatéral dépassera, même de peu, le coût de l’emprunt, des équipes construiront des boucles. Tant que les boucles demanderont plusieurs étapes, des modules promettront de les condenser. Tant que ces modules demanderont des droits larges, des imitateurs testeront les contrôles. Le motif est structurel. Il ne dépend pas d’une marque.

On peut réduire la répétition sans interdire la stratégie. Ancrer l’identité. Borner les appels. Révoquer par défaut après une date. Séparer les coffres. Nommer les auteurs. Publier les audits. Aucune de ces mesures n’est spectaculaire. Toutes attaquent le point exact où FlashLoopAdapter a cédé.

L’actualité du 2 octobre 2026 sert de rappel daté. Elle ne sera pas la dernière si la délégation reste plus facile que la révocation. Les 114 ETH sont déjà un chiffre. Le prochain chiffre dépendra du nombre de badges permanents encore accrochés à des coffres que l’on croit fermés.

Le coffre a tenu. Le badge, non. C’est souvent dans cet ordre que l’argent part.

Relire ses modules n’a rien d’héroïque. C’est une tâche de fin de semaine, fastidieuse, facile à reporter. L’exploitation, elle, ne se reporte pas. Elle prend le droit déjà là, répond à la question qu’on lui pose, et désigne le routeur qu’on lui laisse choisir. Entre ces deux rythmes, celui de la revue et celui de la transaction, l’écart s’est mesuré en ether. Il peut se mesurer, la prochaine fois, en une révocation faite à temps.