JaredFromSubway—l’un des bots MEV les plus reconnaissables d’Ethereum—a été pris dans une exploitation inhabituelle qui a vidé environ 7,5 millions de dollars en WETH, USDC et USDT. La société de sécurité blockchain Blockaid a détaillé l’incident dans un rapport de sécurité couvert par WuBlockchain, le présentant comme une attaque novatrice contre la logique de prise de décision du bot, et non comme une vulnérabilité classique de contrat intelligent. Cette perte redéfinit la manière dont l’infrastructure de trading automatisée sur Ethereum devra se défendre.
L'attaquant a déployé des contrats qui ont trompé les systèmes automatisés de JaredFromSubway pour obtenir des approbations de jetons. Une fois ces autorisations en place, l'exploitant a transféré les avoirs en WETH, USDC et USDT du bot. Il n'y a pas eu d'attaque de phishing ni de faille dans les contrats intelligents déployés. Blockaid a précisé que l'incident a exploité « le mécanisme automatique de détection d'opportunités MEV et d'approbation du bot », une catégorie de risque qui a reçu bien moins d'attention que les audits de code.
Cette distinction est très importante. La logique propre au bot — la partie qui évalue les transactions en attente et décide s'il faut effectuer un frontrun, un backrun ou un sandwich sur un trade — a pris une série de décisions qui ont offert à l'attaquant une prise. Étant donné que les autorisations ont été accordées dans le cadre du flux de travail normal du bot, les mécanismes de sécurité standards utilisés par les wallets et les protocoles contre les utilisateurs humains ne s'appliquaient tout simplement pas. JaredFromSubway fonctionnait avec succès depuis des années sur Ethereum, où le MEV est devenu un métier spécialisé et fortement concurrentiel. Le réseau reste la chaîne dominante pour la DeFi, comme le confirment les données récentes sur l'activité des développeurs sur les principales blockchains, ce qui signifie que des bots comme celui-ci gèrent quotidiennement d'énormes volumes de valeur.
Une exploitation logique, pas une exploitation de code
Les mécanismes de la supercherie sont simples. L'attaquant a créé des séquences de transactions qui semblaient être des opportunités MEV rentables pour les capteurs du bot. Lorsque le bot a agi, il était programmé pour accorder des autorisations aux jetons avec lesquels il devait interagir — un schéma normal qui réduit les coûts de gaz au fil des exécutions répétées. Mais cette fois, les autorisations ont été accordées à des contrôles contrôlés par l'attaquant, qui ont ensuite retiré les actifs. Le vol s'est déroulé silencieusement à travers plusieurs opérations, et non lors d'un seul prêt flash ou d'une attaque de réentrée.
Ce qui rend ce cas différent, c’est l’absence de tout ce qui ressemble à un bug. Le code du bot a fonctionné exactement comme prévu. Il n’a tout simplement pas pu distinguer une interaction DeFi réelle d’une fausse conçue pour exploiter son comportement d’autorisation. Pour les opérateurs de bots, c’est un problème bien plus difficile à résoudre qu’un simple correctif de code. Il nécessite de repenser la manière dont les systèmes automatisés simulent les transactions, évaluent le risque de contrepartie et gèrent les autorisations de jetons en temps réel.
Où en sont les bots MEV après la perte
JaredFromSubway est une figure connue du MEV d'Ethereum depuis des années, donc une perte de 7,5 millions de dollars n'est pas une menace existentielle pour ses opérateurs. Mais cela révèle une cible de taille pour chaque bot qui exécute des stratégies automatisées sans simulation approfondie des contrats avec lesquels il interagit. Les bots rivaux pourraient désormais faire l'objet d'attaques de copie. Le marché MEV est déjà impitoyable : les bots rivalisent sur la vitesse, l'inclusion des bundles et les relations avec les constructeurs. Si les opérateurs doivent également se préoccuper de la manipulation logique au niveau de l'autorisation, le coût de fonctionnement d'un bot sécurisé augmente fortement.
L'incident met également en lumière un manque dans la chaîne d'approvisionnement MEV d'Ethereum. Les constructeurs de blocs et les relais voient des bundles de transactions, mais valident rarement si l'intention d'une séquence de bot peut être manipulée en amont. À moins que la communauté ne développe un middleware qui signale les schémas d'autorisation suspects avant leur exécution, les bots restent largement livrés à eux-mêmes. Et comme la feuille de route de développement d'Ethereum se concentre fortement sur les listes d'inclusion et la résistance à la censure, les outils protégeant les bots contre les exploitations logiques n'ont pas été une priorité.
Ce qui reste peu clair
Blockaid n'a pas publié de diagrammes complets sur chaîne de la séquence d'attaque, donc la séquence exacte des transactions et la manière dont les vérifications d'autorisation du bot ont été contournées sont encore en cours d'étude. Il est également inconnu si l'attaquant ciblait spécifiquement JaredFromSubway ou s'il avait simplement tendu un piège qui a capturé tout bot analysant le mempool. Si cette méthode peut être généralisée, elle pourrait devenir une exploitation reproductible contre une catégorie entière de bots MEV sur Ethereum et même sur les réseaux de couche 2 où des architectures de bots similaires existent.
Pour les traders et les utilisateurs DeFi, l'exposition directe est minimale. Les actifs appartenaient à l'opérateur du bot, et non aux utilisateurs finaux. Mais lorsqu'un grand bot perd soudainement sa liquidité, il peut se retirer du marché, élargissant les écarts et réduisant la qualité d'exécution sur certaines paires. Cet effet peut être temporaire, mais il montre à quel point la liquidité DeFi d'Ethereum dépend de quelques acteurs automatisés qui ont des défenses minces contre une menace très spécifique.