Sushi router exploit drains about 1,800 WETH from approved wallet

A vulnerability in Sushi’s RouteProcessor2 contract was exploited on April 9, 2023, allowing transactions replayed by automated Ethereum actors to drain approximately 1,800 wrapped ether from one wallet that had approved the router to spend its tokens.

The incident mattered because RouteProcessor2 did not hold the affected user’s funds in conventional custody. Instead, the loss traveled through an ERC-20 allowance—a standing authorization permitting the contract to transfer tokens from the wallet. That distinction exposed a broader decentralized-finance risk: removing a vulnerable interface does not cancel permissions already recorded on-chain.

Contemporaneous reporting attributed an estimate exceeding $3.3 million to blockchain-security firm PeckShield. That figure described the approximate market value of about 1,800 WETH, not verified dollars received or retained by one attacker.

The on-chain record

One transaction identified in subsequent technical analyses was confirmed at 02:35:23 UTC on April 9. Etherscan records a transfer of 100 WETH from the affected wallet through the exploit path and gives a historical Ether reference price of $1,859.71 for the transaction. Applying that reference to the later-reported total of approximately 1,800 WETH produces about $3.35 million, consistent with the contemporaneous rounded estimate.

That calculation has important limits. The 1,800-WETH total is approximate, the Etherscan reference is a transaction-day price rather than a sale price, and WETH represents ether on Ethereum rather than U.S. dollars. It does not measure execution costs, subsequent recoveries, later transfers or realized proceeds.

Sushi’s later postmortem said a security researcher attempted to rescue 100 WETH after identifying the problem. The transaction entered Ethereum’s public mempool, where maximal-extractable-value bots detected it and replayed the technique. According to Sushi, 18 replayed transactions then drained approximately 1,800 WETH within seconds from the wallet at risk.

How the approval became exploitable

SharkTeam’s April 11 technical analysis traced the problem to insufficient validation in RouteProcessor2. An attacker-controlled route could cause the router to treat a malicious contract as the pool involved in a swap. That contract could call back into RouteProcessor2 and satisfy its limited check because the router had recorded the malicious address as the last-called pool.

The callback could then transfer WETH that the wallet had previously authorized RouteProcessor2 to spend. SharkTeam concluded that the router checked whether the callback sender matched its stored pool value but failed to establish that the sender was a legitimate Uniswap V3 pool deployed by the expected factory.

On April 9, Sushi contributors publicly characterized the defect as an approval bug and urged users to revoke RouteProcessor2 permissions. Contemporaneous reporting said exposure appeared limited to users who had recently interacted with the new router. That was an early operational assessment, not a complete event-day census of affected wallets across every supported network.

Why the response was difficult

Sushi’s official postmortem, published April 18, said RouteProcessor2 had been introduced in an April 8 soft launch and deployed across 14 networks. After the vulnerability was reported, contributors removed the new router from the interface to stop additional approvals.

The contract was non-upgradeable and could not be paused, however. Existing permissions remained controlled by individual wallets, leaving public disclosure, user revocation and white-hat intervention as the available defenses. This made the episode an institutional test as well as a coding failure: deployment scope, emergency controls and allowance design determined how quickly a single defect became a multi-network response.

Later context

The April 18 postmortem reported that 885 ETH from the initial drain had been returned by that date and that additional value had entered Ethereum’s execution-layer rewards system during block construction. It also said a security team had rescued more than $750,000 of other user assets across multiple networks. Those recovery figures clarify the aftermath but were not established on April 9 and should not be subtracted mechanically from the original estimate without a complete transaction-level reconciliation.