Blockchain security · Deep dive
Sushi RouteProcessor2: an approval outlived its purpose
A router’s authority comes from yesterday’s token approvals as well as today’s route. That changes both exploit impact and emergency response.
Kinwilder research desk · · AI-assisted analysis
Established findings: a router and its delegated authority
Sushi's first-party postmortem describes its April 2023 RouteProcessor2 rollout, the affected deployments, response work and rescue efforts. The affected router was deployed across fourteen networks. Its account distinguishes exposure from funds actually lost and explains why response transactions themselves mattered.
CertiK's technical analysis describes the 9 April exploit and missing validation around the route-processing path. The incident involved abuse of token approvals through a router, rather than a broken signature primitive. Consult the reports for their respective accounting; this feature does not promote one historical estimate into a final net-loss figure.
Kinwilder analysis: approvals are stored capabilities
A token approval is an authorization that can remain usable after the user has finished the action that motivated it. A router therefore sits between two time scales: a short-lived route and long-lived delegated spending authority. If route input or a callback can steer how that authority is exercised, a bug can affect users who are not actively trading.
That is the interesting boundary. It is tempting to focus on whether the router holds a balance. A router with little stored value may still reach value in other accounts through allowances. Threat modeling should inventory the authority reachable by the contract, not merely its present balance.
The same reasoning applies to service accounts, refresh tokens and cloud roles. Delegated power survives the screen or workflow that created it. A system that treats those grants as background state can underestimate the effect of a later input-validation error.
Defensive review: bind callbacks to their context
In an authorized assessment, inspect how a callback proves that it belongs to an expected operation. Ask which party controls the claimed pool, token, payer and route state; which values are independently derived; and whether one nested operation can reuse authority intended for another. The answer must follow actual control flow rather than a familiar-looking function name.
A useful property is that a callback cannot cause spending outside the initiating operation's authenticated context. Another is that an unrelated caller cannot choose a payer merely because that payer previously granted an allowance. Express these properties in tests with disposable tokens and accounts. No real-user approval or production transaction is necessary to evaluate the design.
For users and custody teams, maintain an allowance inventory that includes chain, spender, scope and business purpose. Revoke grants that no longer serve a purpose. Smaller approvals can reduce exposure, but they do not establish the correctness of a vulnerable spender, and a revocation workflow must itself use authenticated transaction details.
Response: exposure is a graph
An incident team needs a graph of spender deployments, affected chains, token contracts, allowance holders and pending transactions. Looking only for a single compromised contract address is insufficient when the same component exists on several networks.
Response also creates public signals. Before attempting a rescue, consider whether the transaction reveals a reusable technique or competes with other pending actions. A rescue claim should be backed by transaction evidence and explicit accounting of returned assets. Keep gross movement, protected exposure, recovered funds and residual loss in separate columns.
What this case adds to the desk
The point is not to rank the event against a larger theft. This incident teaches a different authorization problem from Nomad's missing proof or Bybit's signer presentation path: authority persisted in an allowance and could be reached through software that interpreted a route.
Limits
This analysis summarizes historical investigations and proposes defensive review questions. It does not provide a wallet-draining payload, assess current deployments, or claim independent exploit reproduction. The response history and loss accounting can evolve; follow the linked first-party sources for their stated scope.
Kinwilder research desk: AI-authored retrospective analysis of linked public investigations. No independent incident response, exploit reproduction, private intelligence or new vulnerability discovery is implied. Incident dates and source estimates describe the historical reports, not current balances.