Sushi RouteProcessor2 Approval-Bug

Am 9. April 2023 startete SushiSwap sanft einen neuen Router-Vertrag — RouteProcessor2 —, um sein v3-Swap-Interface anzutreiben. Innerhalb von Stunden hatte das HYDN-Security-Team einen kritischen Access-Control-Bug identifiziert. Innerhalb von Minuten nach dieser Offenlegung front-runten MEV-Bots, die den öffentlichen Mempool überwachten, die Whitehat-Rettung und entzogen rund 3,3 Millionen Dollar in WETH von Nutzern, die Token-Approvals an den neuen Router erteilt hatten.

Was geschah

RouteProcessor2 leitete Multi-Hop-Swaps und erforderte von Nutzern, dem Router-Vertrag standardmäßige ERC-20-Token-Approvals zu erteilen — die normale DEX-Aggregator-UX. Innerhalb des Routers rief ein Swap-Ausführungspfad eine permissionless Funktion auf, die versäumte, den Swap-Aufrufer gegen den Swap-Begünstigten zu validieren. Jede Adresse konnte einen Swap initiieren, der das genehmigte Token-Allowance eines Opfers verbrauchte und den Output an den Angreifer umleitete.

HYDNs Whitehat-Plan war, gefährdete Mittel an eine bekannt-sichere Adresse abzuziehen, von wo sie zurückgegeben werden konnten. Der Plan war solide, aber im öffentlichen Mempool ausgeführt: Als der Whitehat die erste Rettungstransaktion einreichte, replizierten MEV-Bots, die den Mempool beobachteten, den Exploit gegen jeden verbleibenden anfälligen Approval und verschwanden mit dem Großteil des gefährdeten WETH — rund 1.800 WETH (~3,3 Mio. $) — innerhalb von Sekunden nach Sichtbarwerden des Bugs.

Nachwirkungen

• HYDN führte mit Autorisierung von Sushi-Core-Mitwirkenden Cross-Chain-Rettungsverträge aus, die so viel verbleibendes gefährdetes Kapital wie möglich an sichere Adressen abzogen, und deployte Front-Running-Watcher-Verträge, um weitere Bot-Exploitation zu blockieren.
• Die meisten geretteten Mittel wurden an betroffene Nutzer zurückgegeben; die ~3,3 Mio. $, die an MEV-Bots verloren gingen, wurden teilweise durch eine Mischung aus Verhandlung, öffentlicher Adressverfolgung und Börsenkooperation zurückgewonnen.
• Sushi deaktivierte RouteProcessor2 und lieferte einen gepatchten Router aus.
• Der Vorfall fand vor dem Hintergrund einer aktiven SEC-Vorladung gegen SushiSwap statt — der rechtliche und PR-Druck des Timings war erheblich.

Warum es zählt

Sushis Vorfall ist das kanonische Beispiel für das Public-Mempool-Problem für Whitehat-Operationen: Jede für MEV-Bots sichtbare Rettungstransaktion wird zu einer freien Vorlage für Gegner mit schnellerer Infrastruktur. Best Practice hat sich seitdem zu privater RPC-Einreichung (Flashbots Protect, MEV-Share) für jede Whitehat-Operation verschoben, und zur Integration von Rescue-Coordination-Tooling in das Protokolldesign (z. B. Pause + Permit-basierte erzwungene Wiederherstellung) statt sie post-incident zu improvisieren.