Bug d'approbation Sushi RouteProcessor2

Le 9 avril 2023, SushiSwap a lancé en douceur un nouveau contrat routeur — RouteProcessor2 — pour alimenter son interface de swap v3. En quelques heures, l'équipe de sécurité HYDN avait identifié un bug critique de contrôle d'accès. Quelques minutes après cette divulgation, des bots MEV surveillant le mempool public ont devancé le sauvetage white-hat et drainé environ 3,3 millions de dollars en WETH d'utilisateurs ayant accordé des approbations de jetons au nouveau routeur.

Ce qui s'est passé

RouteProcessor2 acheminait des swaps multi-hop et exigeait des utilisateurs qu'ils accordent des approbations de jetons ERC-20 standard au contrat routeur — l'UX normale d'un agrégateur DEX. À l'intérieur du routeur, un chemin d'exécution de swap appelait une fonction sans permission qui ne validait pas l'appelant du swap contre le bénéficiaire du swap. Toute adresse pouvait initier un swap consommant l'allocation de jeton approuvée d'une victime et redirigeant la sortie vers l'attaquant.

Le plan white-hat de HYDN était de drainer les fonds à risque vers une adresse connue sûre depuis laquelle ils pouvaient être restitués. Le plan était solide mais exécuté dans le mempool public : lorsque le white-hat a soumis la première transaction de sauvetage, des bots MEV observant le mempool ont rejoué l'exploit contre chaque approbation vulnérable restante et sont partis avec la majeure partie du WETH à risque — environ 1 800 WETH (~3,3 M$) — quelques secondes après que le bug est devenu visible.

Conséquences

• HYDN, avec autorisation des contributeurs core de Sushi, a exécuté des contrats de sauvetage cross-chain qui ont drainé autant de capital restant à risque que possible vers des adresses sûres, et déployé des contrats watcher de front-running pour bloquer toute exploitation supplémentaire par les bots.
• La plupart des fonds sauvés ont été restitués aux utilisateurs affectés ; les ~3,3 M$ perdus aux bots MEV ont été partiellement récupérés via un mélange de négociation, traçage public d'adresses et coopération d'exchanges.
• Sushi a désactivé RouteProcessor2 et livré un routeur corrigé.
• L'incident s'est produit sur fond d'une citation à comparaître active de la SEC contre SushiSwap — la pression juridique et de relations publiques du timing était substantielle.

Pourquoi c'est important

L'incident Sushi est l'exemple canonique du problème du mempool public pour les opérations white-hat : toute transaction de sauvetage visible aux bots MEV devient un modèle gratuit pour des adversaires avec une infrastructure plus rapide. La meilleure pratique depuis a glissé vers la soumission RPC privée (Flashbots Protect, MEV-Share) pour toute opération white-hat, et vers l'intégration d'outillage de coordination de sauvetage dans la conception du protocole (par ex. pause + récupération forcée par permit) plutôt que de l'improviser après l'incident.