Article original de : @Ehsan1579
Compilé par | Odaily Planet Daily (@OdailyChina) ; Traducteur | Ethan (@ethanzhang_web 3)
Rien qu'en lisant le titre, on pourrait facilement penser qu'il s'agit d'une attaque par exploitation d'une faille.
Le cœur de l'événement est le suivant : Quelqu'un a échangé 50,4 millions de dollars US en USDT et n'a finalement obtenu que 35 900 dollars US en AAVE.
Lorsque j'ai entendu cela pour la première fois, j'ai été stupéfait. J'ai donc examiné l'événement de fond en comble : traçage des transactions, chemin du solveur, appels de contrats, réserves historiques, données de règlement, processus de l'adaptateur, code de l'interface Aave, SDK du flash loan de CoW, et le code de routage qui détermine si une offre est "raisonnable".
Ce n'était pas un piratage. Le protocole central d'Aave n'a pas dysfonctionné. Le règlement CoW n'a pas dysfonctionné. Uniswap n'a pas dysfonctionné. SushiSwap n'a pas dysfonctionné. La transaction était valide, les signatures étaient valides, tous les contrats ont été exécutés strictement selon le code. Pourtant, presque toute la valeur économique a été anéantie, simplement parce qu'elle a été autorisée à emprunter un chemin absurde.
La blockchain publique n'a pas eu de problème, le problème vient du routage.
À mon avis, qualifier cela de simple "erreur de l'utilisateur" est une attitude peu objective et peu rigoureuse. Certes, l'utilisateur a signé l'ordre, mais l'ensemble du système logiciel a permis qu'une opération impliquant près de 50 millions de dollars de rotation de collatéral soit cotée, signée, planifiée en termes de route et finalement exécutée, le tout pointant vers un pool à faible liquidité ne détenant qu'environ 331 AAVE. Cela n'aurait jamais dû être possible, cela aurait dû être catégoriquement rejeté et bloqué par le système avant même que le processus de règlement ne commence.
Traçage des informations clés de la transaction
Le hash de cette transaction anormale est : 0x9fa9feab3c1989a33424728c23e6de07a40a26a98ff7ff5139f3492ce430801f, confirmée sur le mainnet Ethereum le 12 mars 2026 au bloc 24643151, index de transaction 1, consommation de gaz 3780570 unités, exécution réussie. Le portefeuille appartenant à l'ordre commence par 0x98b9, l'adresse de l'expéditeur de la transaction (le solveur) qui a réellement exécuté l'ordre commence par 0x3980, marquée comme tsolver dans les données de compétition CoW.
Il faut d'abord comprendre qu'il ne s'agissait pas d'un simple échange d'USDT contre AAVE au niveau du portefeuille. Le jeton vendu était aEthUSDT, le jeton de dépôt portant intérêt d'USDT sur la plateforme Aave. Le jeton acheté était aEthAAVE, le jeton de dépôt portant intérêt d'AAVE sur la plateforme Aave. Il s'agissait donc d'une rotation de collatéral Aave effectuée via le système de règlement du protocole CoW et son processus d'adaptateur de flash loan.
Avant la transaction, le portefeuille détenait environ 50 432 693,075254 aEthUSDT et 0 aEthAAVE. Après la transaction, il ne lui restait plus que 4,980399 aEthUSDT et il avait reçu 327,241335505966487788 aEthAAVE. En fait, le portefeuille a vendu presque toute sa position.
Les métadonnées indiquent plus clairement que la route était "toxique" avant même l'exécution. L'ordre provenait du processus aave-v3-interface-collateral-swap. L'API de CoW l'affiche comme un ordre de vente signé, et les métadonnées de l'application le marquent comme un échange de collatéral de type marché utilisant un slippage intelligent de 121 points de base. Le montant signé de la vente était de 50 432 688,41618 aEthUSDT. Le montant minimum d'achat signé était de 324,949260918413591035 aEthAAVE. Le règlement effectif a payé 327,241335505966487788 aEthAAVE.
C'est un détail extrêmement important. Cet ordre ne s'attendait pas à obtenir des milliers d'AAVE qui auraient été détruits en cours de route. Dès sa construction, il était centré sur un résultat d'environ trois cents AAVE.
Chaine complète de l'effondrement du routage
Une fois que vous suivez le traçage de la transaction, le processus devient brutalement direct.
Le flux de fonds de haut niveau s'appuie sur le contrat de règlement GPv2Settlement 0x9008 du protocole CoW. D'abord, le contrat HooksTrampoline 0x60bf effectue l'opération d'autorisation aEthUSDT, permettant au relais du coffre-fort CoW d'extraire les actifs de l'utilisateur sans transaction d'autorisation séparée ; ensuite, le contrat GPv2VaultRelayer 0xc92e extrait 50432688,41618 aEthUSDT du portefeuille de l'utilisateur dans le processus de règlement. Jusqu'à cette étape, toutes les opérations sont conformes à la logique normale.
Le contrat de règlement accorde ensuite les droits d'opération sur aEthUSDT à un contrat auxiliaire non open-source commençant par 0xd524, et initie un appel via le sélecteur de fonction 0x494b3137 ; ce contrat auxiliaire transfère ensuite les droits d'exécution à un contrat d'exécution non open-source commençant par 0x699c. À ce stade, la vue complète de la route de transaction anormale est totalement exposée.
Le premier appel effectif pointe vers le contrat du pool de fonds Aave 0x87870, via la fonction withdraw (sélecteur 0x69328dec) pour brûler aEthUSDT et racheter l'USDT natif sous-jacent ; la route saute ensuite vers le pool de trading profond USDT/WETH Uniswap V3 0x4e68, échangeant la totalité des 50432688,41618 USDT contre 17957,810805702142342238 WETH.
Cette phase de la transaction est totalement normale : le taux de change était d'environ 2808,4 USDT pour 1 WETH, conforme aux conditions du marché à ce moment-là, pas de problème de liquidité insuffisante, pas d'écart de calcul, la première étape de la chaîne de transaction ne présente aucune anomalie.
Le problème survient à la deuxième étape. Une fois que vous voyez les réserves de liquidité, le reste de l'histoire devient inévitable.
Après avoir obtenu 17957,810805702142342238 WETH, l'exécuteur transfère la totalité des fonds vers le pool de trading SushiSwap V2 AAVE/WETH à l'adresse 0xd75ea151a61d06868e31f8988d28dfe5e9df57b4.
J'ai vérifié les données historiques de réserve de liquidité de ce pool juste avant la transaction anormale (bloc 24643150), le pool ne détenait que :
331,631982538108027323 AAVE, 17,653276196397688066 WETH
Ce n'est pas une erreur de saisie de données, c'est un fait indéniable.
Cette route de transaction a injecté près de 17958 WETH dans un pool de trading miniature qui ne disposait que de 17,65 WETH en réserve, avec un stock total d'AAVE correspondant de seulement 331,63. Le volume de WETH injecté était environ 1017 fois supérieur à la réserve de WETH du pool.
Ce n'est pas un problème courant de "slippage élevé" ou de "liquidité un peu faible", mais un chemin d'exécution d'ordre au marché extrêmement absurde, équivalent à forcer un pool AMM à produit constant de très petite taille à absorber une transaction énorme, des milliers de fois plus grande que lui-même.
Le pool de trading AMM a exécuté l'opération selon son algorithme établi, épuisant presque entièrement la réserve totale d'AAVE du pool.
La paire de trading SushiSwap a déclenché l'événement central Swap : l'exécuteur a transféré 17957,810805702142342238 WETH et n'a récupéré que 331,305315608938235428 AAVE. Après la transaction, la liquidité restante du pool était d'environ :
0,326666929169791895 AAVE, 17975,464081898540030304 WETH
En clair, environ 99,9 % du stock d'AAVE du pool a été vidé en une seule fois.
Sur la base des réserves avant la transaction, le prix implicite de l'AAVE du pool était d'environ 149,50 $. Le prix d'exécution réel pour l'utilisateur était d'environ 154 114,66 USDT pour 1 AAVE. C'est plus de 1000 fois supérieur au prix spot avant la transaction.
Ensuite, ces AAVE ont été fournis au pool de fonds Aave, en utilisant le sélecteur 0x617ba037, c'est-à-dire supply(address,uint256,address,uint16). Le résultat a été que les nouveaux aEthAAVE frappés ont été renvoyés au contrat de règlement. Le contrat de règlement a finalement transféré 327,241335505966487788 aEthAAVE à l'utilisateur. Environ 4,06398010297174764 aEthAAVE sont restés dans le contrat de règlement en tant que surplus par rapport au montant payé par l'utilisateur.
Ainsi, le règlement n'a pas soudainement déformé un bon résultat d'exécution en un mauvais. Il a simplement finalisé le résultat que la route avait déjà produit.
C'est un point clé, qui mérite d'être dit explicitement : Le résultat catastrophique était déjà "prédéterminé" dans la route avant son exécution.
Dans les données d'appel du contrat auxiliaire intégré à la route, le montant cible côté achat était d'environ 331,272185078031026739, le montant d'achat minimum convenu par la signature de l'utilisateur était de 324,949260918413591035, et le montant de règlement réel était de 327,241335505966487788. Toutes les valeurs clés étaient verrouillées au niveau de quelques centaines d'AAVE avant le règlement.
Cette route est née défectueuse.
Où est la faille ?
La réponse est : Chaque couche du système de vérification vérifiait la mauvaise dimension.
Tous les niveaux ne vérifiaient que si la transaction était exécutable, si la signature était valide, si le montant était non nul, mais presque aucun niveau central ne vérifiait si la route de transaction était économiquement raisonnable, c'est la racine de l'échec du mécanisme.
Défaut de code dans le chemin de cotation de l'adaptateur de l'interface Aave
Le premier point de code anormal évident apparaît dans le processus de cotation de l'adaptateur CoW de l'interface Aave : la fonction destinée à inclure des données d'application spécifiques à l'adaptateur lors de la demande de cotation a été directement désactivée de force.
Source : rates.helpers.ts:93 et adapters.helpers.ts:194
Cela signifie que l'interface Aave, lors de la demande de cotation à CoW, n'a pas joint les métadonnées de flash loan et de hooks qui seraient normalement ajoutées lors de la publication effective de l'ordre. En d'autres termes, ce qui a été coté n'était pas exactement ce qui allait être exécuté. Le commentaire du code dit même que le but de cette fonction d'aide est de rendre la cotation de l'adaptateur plus précise, et pourtant cette fonction a été désactivée de force.
La logique de compétition des offres de CoW est trop faible pour juger de la rationalité (vulnérabilité principale)
Le deuxième et le plus grave problème réside dans la logique de compétition des offres du protocole CoW : dans son code de service public, tant que les frais de Gaz de l'offre sont positifs et que le montant de sortie est non nul, elle est jugée comme une "offre raisonnable".
Source : quote.rs:31
Pour un système de routage traitant des ordres à huit chiffres, c'est une définition "raisonnable" étonnamment faible.
Le système n'intégrait pas d'oracle pour vérifier la sanité des prix, pas de mécanisme d'interception pour des "offres s'écartant de plus de 500 fois du prix spot", pas d'évaluation des risques pour les "routes qui videraient complètement un pool de liquidité", pas d'alerte pour une "inadéquation grave entre la liquidité du dernier saut et la taille de l'ordre" ; il suffisait que le solveur renvoie un schéma de route exécutable et non nul pour qu'il soit accepté par le système, c'est la vulnérabilité centrale de cet incident.
Défaut de la logique de modélisation de la liquidité de type Uniswap V2
Le troisième problème réside dans la façon dont les pools de liquidité de style Uniswap V2 sont modélisés : le code n'utilise que l'algorithme standard du produit constant, ne rejetant que les cas mathématiquement impossibles comme les réserves nulles, les underflows numériques, les overflows de réserve, sans vérification de faisabilité économique.
Source : pool_fetching.rs:118 et pool_fetching.rs:153
Ce code ne juge pas si la taille du pool de liquidité est suffisante pour absorber la transaction correspondante de la route, il vérifie seulement si l'opération d'échange est mathématiquement valide. Par conséquent, même un pool miniature avec seulement 331 AAVE en réserve serait jugé comme un lieu valide pour absorber une demande d'achat de 17957 WETH, simplement parce que l'algorithme du produit constant peut calculer un résultat non nul, ignorant complètement que ce résultat entraînerait une perte dévastatrice d'actifs.
Double échec du SDK de flash loan et du mécanisme de validation des ordres
Ensuite, le SDK de flash loan a directement figé cette offre défaillante dans la charge utile d'exécution de l'ordre et des hooks, sans effectuer aucune interception de risque secondaire.
Puis :
Source : index.js:484 et index.js:591
C'est pourquoi j'ai toujours dit que cette route était "née mauvaise". La couche adaptateur n'a pas "découvert" un nouveau mauvais montant lors de l'exécution. Elle a sérialisé le mauvais montant déjà coté dans les données des hooks et l'adresse d'instance déterminée. Une fois que la mauvaise offre existe, le reste du mécanisme la transmet fidèlement.
Même la logique de validation des ordres de CoW n'a pas vraiment protégé l'utilisateur ici, car elle ne vérifie que si l'ordre dépasse le prix du marché au moment de la cotation, et non si la cotation elle-même est absurde par rapport à la liquidité réelle.
Source : order_validation.rs:694
C'est une vérification de cohérence. Si l'offre elle-même est déjà un non-sens, l'ordre peut toujours passer.
Le mécanisme d'alerte de l'interface utilisateur (UI) est inefficace
L'interface Aave avait bien un avertissement pour les chocs de prix élevés, mais ce n'était pas un disjoncteur dur. Lorsque la perte de valeur dépasse 20 %, cela devient une case à cocher de confirmation.
Une fois que l'utilisateur a coché la case, l'obstacle est levé :
Source : helpers.ts:24 et HighPriceImpactWarning.tsx:35
Par conséquent, même si cette transaction allait vider presque toute la valeur des actifs, le système l'a seulement jugée comme une opération nécessitant une confirmation de l'utilisateur, et non comme une transaction à haut risque que le système doit absolument refuser. Le mécanisme d'alerte a complètement perdu son rôle d'interception des risques.
Sur la base de tous ces échecs de mécanismes, je ne suis absolument pas d'accord avec la conclusion expéditive selon laquelle "c'est juste l'utilisateur qui a été stupide". L'utilisateur a bien signé, mais l'ensemble du système logiciel a eu d'innombrables occasions d'intercepter cette catastrophe, et à chaque niveau, il n'a effectué que des vérifications de base, a jugé "non nul, exécutable, signé" et l'a laissé passer, ce qui a finalement conduit à ce résultat désastreux.
La route n'a pas été altérée
Cette étape est cruciale, elle exclut directement de nombreuses suppositions erronées : le processus correspondant à aave-v3-interface-collateral-swap de l'interface officielle d'Aave, dans le fichier useSwapOrderAmounts.ts à la ligne 139, combine l'offre, les frais de réseau, les frais des partenaires, les frais de flash loan pour calculer le montant d'achat ajusté du slippage ; la ligne 331 le convertit en valeur buyAmountBigInt ; puis dans le fichier CollateralSwapActionsViaCoWAdapters.tsx à la ligne 191, ce montant est signé avec précision.
Ensuite, le contrat adaptateur vérifiera dans le fichier AaveV3BaseAdapter.sol à la ligne 141 que les champs de l'ordre signé correspondent exactement aux valeurs stockées ; le contrat de règlement CoW appliquera strictement les règles de limite convenues par la signature dans le fichier GPv2Settlement.sol à la ligne 337. Par conséquent, le résultat de l'exécution on-chain n'a pas dépassé la portée autorisée par l'ordre signé, et l'utilisateur a effectivement reçu des actifs supérieurs au minimum convenu par la signature.
Cela prouve suffisamment que : le désastre s'est produit avant le processus de règlement, et non pendant celui-ci, le défaut fatal de la route avait déjà scellé le résultat.
Où est passée la valeur perdue ?
La transaction suivante dans le même bloc (hash commençant par 0x45388b0f) a effectué un arbitrage de rattrapage (backrun) sur le pool SushiSwap AAVE/WETH détruit. Après que la transaction anormale ait rempli le pool avec une énorme quantité de WETH et vidé la grande majorité des AAVE, l'arbitragiste a immédiatement revendu des AAVE dans le pool, récoltant la valeur excédentaire générée par le déséquilibre de liquidité.
Cet arbitrage de rattrapage a extrait environ 17929,770158685933 WETH, puis a payé environ 13087,73 ETH au constructeur du bloc et environ 4824,31 ETH à l'adresse d'exécution de l'arbitrage.
Toute la valeur économique perdue par l'utilisateur a finalement été presque instantanément transformée en gains d'arbitrage MEV au sein du même bloc et en gains pour le constructeur de blocs.
De plus, la vérification de l'ordre chronologique au niveau du bloc confirme : personne n'a manipulé malicieusement le pool de trading SushiSwap pour piéger l'utilisateur avant la transaction, cette paire de trading AAVE/WETH a été touchée pour la première fois par cette transaction anormale (index de transaction 1) ; la transaction immédiatement suivante (index de transaction 2) a effectué le premier rattrapage sur la distorsion des prix causée par cette transaction ; l'index de transaction 3 a également touché cette paire de trading lors de la correction du marché. La chronologie confirme clairement : cette transaction anormale a créé une distorsion de prix extrême, et les transactions suivantes ont directement récolté les bénéfices de cette distorsion.
Alors, qui est fautif ?
Si vous demandez si le protocole central d'Aave V3 a planté, la réponse est non. Le pool Aave a exécuté les instructions exactement comme demandé, achevant normalement le processus de rachat d'USDT et de dépôt d'AAVE.
Si vous demandez si le contrat de règlement GPv2Settlement de CoW a planté, la réponse est non. Le règlement a exécuté de force un ordre signé valide et a payé un montant supérieur au minimum signé.
Si vous demandez si les contrats de trading Uniswap V3 ou SushiSwap ont planté, la réponse est également non. Les deux pools de trading ont effectué la tarification des transactions selon leurs propres règles algorithmiques.
Le véritable échec systémique s'est produit à un niveau supérieur, au niveau du routage et du contrôle des risques :
Le principal responsable est le module de routage, de cotation et de solveur du protocole CoW : L'ensemble du système avait des critères de jugement de "route raisonnable" trop faibles, permettant à un ordre énorme de dizaines de millions de dollars d'aboutir finalement à un pool minuscule à faible liquidité, tant que la route était exécutable et non nulle, ignorant complètement l'extrême irrationalité économique.
Le responsable secondaire est l'interface frontale d'Aave : Lors de la demande de cotation de l'adaptateur, elle n'a pas inclus les données d'application associées aux hooks, a directement transmis le mauvais résultat au processus de signature, et s'est uniquement appuyée sur des alertes, sans mécanisme de refus catégorique. Pour ce type de transaction extrêmement importante, ces mesures de contrôle des risques étaient totalement insuffisantes pour prévenir les risques.
Il s'agit d'un échec extrême de la qualité du routage des transactions et des garde-fous de contrôle des risques, transformant directement une opération légale et réglementaire de rotation de collatéral en un événement de perte d'actifs dévastateur.
