Sushi RouteProcessor2 Approval Bug

On April 9, 2023, SushiSwap soft-launched a new router contract — RouteProcessor2 — to power its v3 swap interface. Within hours, the HYDN security team had identified a critical access-control bug. Within minutes of that disclosure, MEV bots monitoring the public mempool front-ran the white-hat rescue and drained approximately $3.3 million in WETH from users who had granted token approvals to the new router.

What happened

RouteProcessor2 routed multi-hop swaps and required users to grant standard ERC-20 token approvals to the router contract — the normal DEX-aggregator UX. Inside the router, a swap-execution path called a permissionless function that failed to validate the swap's caller against the swap's beneficiary. Any address could initiate a swap that consumed a victim's approved token allowance and redirected the output to the attacker.

HYDN's white-hat plan was to drain at-risk funds to a known-safe address from where they could be returned. The plan was sound but executed in the public mempool: when the white-hat submitted the first rescue transaction, MEV bots observing the mempool replayed the exploit against every remaining vulnerable approval and walked with most of the at-risk WETH — roughly 1,800 WETH (~$3.3M) — within seconds of the bug becoming visible.

Aftermath

• HYDN, with Sushi core contributors' authorisation, executed cross-chain rescue contracts that drained as much remaining at-risk capital as possible to safe addresses, and deployed front-running watcher contracts to block further bot exploitation.
• Most of the rescued funds were returned to affected users; the ~$3.3M lost to MEV bots was partially recovered through a mix of negotiation, public address tracking and exchange cooperation.
• Sushi disabled RouteProcessor2 and shipped a patched router.
• The incident occurred against the backdrop of an active SEC subpoena against SushiSwap — the legal and PR pressure of the timing was substantial.

Why it matters

Sushi's incident is the canonical example of the public-mempool problem for white-hat operations: any rescue transaction visible to MEV bots becomes a free template for adversaries with faster infrastructure. Best practice since has shifted toward private RPC submission (Flashbots Protect, MEV-Share) for any white-hat operation, and toward integrating rescue-coordination tooling into protocol design (e.g. pause + permit-based forced recovery) rather than improvising it post-incident.