← SushiSwap RouteProcessor Exploitreviewed 2026-09-07 · 28 claims checked
Fact-check findings
What an automated fact-checker found when it re-read SushiSwap RouteProcessor Exploit against the sources the page cites. Only the most recent review is shown.
Read this first
These findings are produced by an automated reviewer, and its results vary between runs: the same page, checked three times on the same day, came back with 15%, 20% and 34% of its claims disputed, mostly because each run extracted a different number of claims. Treat what follows as leads, not rulings.
“Disputed” means the reviewer could not reconcile the claim with the evidence it cited. It does not mean the claim is false. “Unverifiable” means no reachable source settled it either way.
Nothing here changes the page on its own. A proposed correction is applied only after a human moderator approves it; until then the page reads as it did when reviewed.
link rot
1 claimA cited source no longer resolves or no longer says what the page attributes to it.
- #28[link rot][awaiting moderator]in section: Team Response and User Guidance
“https://coinmarketcap.com/academy/article/83d32e02-fa70-48fd-a8d4-41254aa0a6fa”
reviewerThe cited CoinMarketCap Academy article (Jared Grey / revoke guidance source) is live at the URL given.The originally-cited CoinMarketCap academy URL 404s; the same article has been relocated to CoinMarketCap's community-articles path and is live there.Proposed correction (not yet applied)https://coinmarketcap.com/community/articles/6432780eaa622e516b951a03/
partially supported
2 claimsThe cited evidence supports part of the claim but not all of it.
- #10[partially supported][awaiting moderator]in section: Losses and Affected Users
“The vulnerability affected any user who had interacted with RouteProcessor2 across all 14 supported networks: Arbitrum, Arbitrum Nova, Avalanche, Boba, BSC, Ethereum, Fantom, Fuse, Gnosis, Moonbeam, Moonriver, Optimism, Polygon, and Polygon ZkEVM.”
reviewerThe vulnerability affected any user who had interacted with RouteProcessor2 across all 14 supported networks (listed by name).The 14-network deployment figure is well corroborated, but HYDN's own writeup states unique affected addresses were concentrated on 8 of the 14 chains, so the claim that the vulnerability 'affected any user...across all 14 supported networks' somewhat overstates the actual exposure footprint versus deployment footprint. - #19[partially supported][awaiting moderator]in section: Team Response and User Guidance
“SushiSwap's Immunefi bug bounty report for the vulnerability was initially auto-closed before being reopened, raising questions about the responsiveness of the triage process.”
reviewerSushiSwap's Immunefi bug bounty report for the vulnerability was initially auto-closed before being reopened, raising questions about the responsiveness of the triage process.The underlying facts (auto-closed, then reopened) are accurate, but the page's editorializing that this 'rais[es] questions about the responsiveness of the triage process' is not supported by the source, which shows a 20-minute turnaround and frames the gap as a scope-list procedural issue rather than a triage-speed issue.
confirmed
25 claimsThe cited evidence supports the claim as written.
- #1[confirmed][no action needed]in the summary
“On April 9, 2023, SushiSwap's RouteProcessor2 contract — deployed just one day earlier across 14 blockchain networks — was exploited due to a failure to validate user-supplied pool addresses, allowing an attacker to redirect token transfers from wallets that had approved the contract.”
reviewerRouteProcessor2 was deployed one day before the exploit (April 8, 2023, exploited April 9, 2023), across 14 blockchain networks.Deployment/exploit dates and 14-network scope corroborated by the official post-mortem and independent reporting. - #2[confirmed][no action needed]in the summary
“On April 9, 2023, SushiSwap's RouteProcessor2 contract — deployed just one day earlier across 14 blockchain networks — was exploited due to a failure to validate user-supplied pool addresses, allowing an attacker to redirect token transfers from wallets that had approved the contract.”
reviewerThe root cause was a failure to validate user-supplied pool addresses, allowing redirection of token transfers from approved wallets.Cited primary URLs (hacken.io, blockapex.io) returned HTTP 403 to automated fetch (bot-protection, not confirmed dead), but the substance is corroborated by multiple other independent technical writeups located via search. - #3[confirmed][no action needed]in the summary
“Approximately $3.3 million (roughly 1,800 WETH) was drained, with a single high-profile victim (@0xsifu) accounting for the majority of losses.”
reviewerApproximately $3.3 million (roughly 1,800 WETH) was drained.Figure widely corroborated across independent news reporting. - #4[confirmed][no action needed]in the summary
“Approximately $3.3 million (roughly 1,800 WETH) was drained, with a single high-profile victim (@0xsifu) accounting for the majority of losses.”
reviewerA single high-profile victim (@0xsifu) accounted for the majority of losses.Confirmed by multiple contemporaneous reports naming 0xsifu as the primary/dominant victim. - #5[confirmed][no action needed]in the summary
“Whitehat security teams front-ran further exploitation and recovered over $750,000, while SushiSwap committed to making all affected users whole through a two-tier compensation process.”
reviewerWhitehat security teams recovered over $750,000 by front-running further exploitation.Confirmed. Note the HYDN blog's own title references $600k, but its body and the official Sushi post-mortem both state over $750,000 was rescued. - #6[confirmed][no action needed]in the summary
“Whitehat security teams front-ran further exploitation and recovered over $750,000, while SushiSwap committed to making all affected users whole through a two-tier compensation process.”
reviewerSushiSwap committed to making all affected users whole through a two-tier compensation process.Confirmed. - #7[confirmed][no action needed]in section: Vulnerability Mechanics
“The contract's `processRoute()` function failed to verify that the `pool` parameter passed in the `bytes route` argument referred to a legitimate Uniswap v3 pool. An attacker could supply an arbitrary contract address as the pool, causing RouteProcessor2 to call `IUniswapV3Pool(pool).swap(...)` on the attacker-controlled contract.”
reviewerThe processRoute() function failed to verify that the pool parameter referred to a legitimate Uniswap v3 pool, allowing an attacker to supply an arbitrary contract that RouteProcessor2 called as if it were a pool.Technical mechanics corroborated by multiple independent security writeups, though the two cited primary sources (hacken.io, blockapex.io) could not be fetched directly due to bot-blocking (403). - #8[confirmed][no action needed]in section: Vulnerability Mechanics
“That contract then re-entered RouteProcessor2 via `uniswapV3SwapCallback`, supplying malicious calldata that redirected ERC-20 token transfers from any wallet that had previously approved the RouteProcessor2 contract.”
reviewerThe attacker's contract re-entered RouteProcessor2 via uniswapV3SwapCallback, redirecting ERC-20 token transfers from wallets that had approved RouteProcessor2.Confirmed via corroborating independent technical sources. - #9[confirmed][no action needed]in section: Vulnerability Mechanics
“The contract was non-upgradeable and could not be paused, making real-time mitigation impossible once the exploit was discovered.”
reviewerThe RouteProcessor2 contract was non-upgradeable and could not be paused, making real-time mitigation impossible once discovered.Confirmed directly by the official post-mortem. - #11[confirmed][no action needed]in section: Losses and Affected Users
“The exploit window was narrow — the contract had been deployed less than 24 hours before exploitation began — but the scale of approvals collected during that window was sufficient to cause significant losses.”
reviewerThe exploit window was narrow — the contract was deployed less than 24 hours before exploitation began.Confirmed. - #12[confirmed][no action needed]in section: Whitehat Rescue and MEV Complications
“On the evening of April 8, HYDN's real-time monitoring systems detected the RouteProcessor2 vulnerability. HYDN's team created a proof-of-concept, contacted SushiSwap leadership, and established a joint war room.”
reviewerHYDN's monitoring detected the vulnerability on the evening of April 8, created a proof-of-concept, contacted SushiSwap, and established a joint war room.Confirmed directly against HYDN's own account. - #13[confirmed][no action needed]in section: Whitehat Rescue and MEV Complications
“HYDN drained vulnerable user funds to a labeled whitehat wallet (0x74ebb8e8d0b0cc65f06040eb0f77b5da0e33ffee) and deployed a cross-chain watcher contract to front-run further exploitation.”
reviewerHYDN drained vulnerable user funds to a labeled whitehat wallet (0x74ebb8e8d0b0cc65f06040eb0f77b5da0e33ffee) and deployed a cross-chain watcher contract.Wallet address independently corroborated by SushiSwap's own claim-portal announcement. - #14[confirmed][no action needed]in section: Whitehat Rescue and MEV Complications
“In total, HYDN rescued over $750,000 in user assets and was awarded a $200,000 bounty.”
reviewerHYDN rescued over $750,000 in user assets and was awarded a $200,000 bounty.Confirmed. - #15[confirmed][no action needed]in section: Whitehat Rescue and MEV Complications
“However, a separate whitehat researcher (@trust__90) also attempted an independent rescue, but used the public mempool rather than a private RPC endpoint, and attempted to rescue only 100 ETH rather than all at-risk funds.”
reviewerA separate whitehat researcher (@trust__90) attempted an independent rescue via the public mempool rather than a private RPC, and tried to rescue only 100 ETH rather than all at-risk funds.Confirmed directly against the cited BlockSec writeup. - #16[confirmed][no action needed]in section: Team Response and User Guidance
“Jared Grey, SushiSwap's head chef (lead developer), publicly confirmed the exploit and urgently instructed users to revoke all RouteProcessor2 approvals across all chains, stating: 'Sushi's RouteProcessor2 contract has an approval bug; please revoke approval ASAP. We're working with security teams to mitigate the issue.'”
reviewerJared Grey publicly confirmed the exploit and tweeted: 'Sushi's RouteProcessor2 contract has an approval bug; please revoke approval ASAP. We're working with security teams to mitigate the issue.'Exact quote independently verified against Jared Grey's original tweet. - #17[confirmed][no action needed]in section: Team Response and User Guidance
“Grey directed users to revoke.cash and sushi.com as tools to remove approvals.”
reviewerGrey directed users to revoke.cash and sushi.com as tools to remove approvals.Confirmed via a live replacement of the (now-404) cited CoinMarketCap URL; see separate link_rot finding. - #18[confirmed][no action needed]in section: Team Response and User Guidance
“The SushiSwap UI was rolled back to prevent further approvals from being generated.”
reviewerThe SushiSwap UI was rolled back to prevent further approvals from being generated.Confirmed, though phrased in the source as disabling the frontend rather than a version 'rollback'; substantively equivalent. - #20[confirmed][no action needed]in section: Recovery and Compensation
“Users whose funds were rescued by whitehats (Group 1) could reclaim tokens on a 1:1 basis through a Merkle-tree claim portal at sushi.com/claims/rp2, provided they had first revoked the RouteProcessor2 approval. Users whose funds were stolen by malicious actors (Group 2) were asked to submit claims via a Google Form, with each case reviewed individually and verified against on-chain data.”
reviewerUsers whose funds were rescued by whitehats (Group 1) could reclaim tokens 1:1 via a Merkle-tree claim portal at sushi.com/claims/rp2; Group 2 (stolen by malicious actors) submitted claims via a Google Form reviewed individually against on-chain data.Confirmed. - #21[confirmed][no action needed]in section: Recovery and Compensation
“Of the 885 ETH accounted for by the HYDN rescue, 685 ETH was deposited to Sushi operations, 190 ETH returned to a victim, and 10 ETH went to the rescue contract. Approximately 795 ETH was redirected as block builder rewards into the Lido vault due to MEV bot activity, and 94.9 ETH remained in an unauthorized wallet at the time of the post-mortem.”
reviewerOf the 885 ETH accounted for by the HYDN rescue, 685 ETH went to Sushi operations, 190 ETH to a victim, 10 ETH to the rescue contract; ~795 ETH went to a Lido vault via block builder rewards from MEV activity; 94.9 ETH remained in an unauthorized wallet.All figures independently confirmed against the primary source. - #22[confirmed][no action needed]in section: Security History and Prior Incidents
“In August 2021, Paradigm researchers discovered a critical vulnerability in SushiSwap's MISO dutch auction contract that could have resulted in approximately $350 million in losses; the bug was patched in under five hours with no funds lost.”
reviewerIn August 2021, Paradigm researchers discovered a critical vulnerability in SushiSwap's MISO dutch auction contract that could have caused ~$350M in losses; patched in under five hours with no funds lost.Confirmed. - #23[confirmed][no action needed]in section: Security History and Prior Incidents
“In September 2021, SushiSwap's MISO launchpad suffered a supply chain attack when an anonymous contractor (GitHub handle: AristoK3) injected malicious code into the platform's frontend and redirected auction proceeds, stealing approximately $3 million in ETH from the JayPegs Auto Mart auction; the funds were later returned by the attacker.”
reviewerIn September 2021, an anonymous contractor (GitHub handle AristoK3) injected malicious frontend code into SushiSwap's MISO launchpad, stealing ~$3M in ETH from the JayPegs Auto Mart auction; funds were later returned.Confirmed. - #24[confirmed][no action needed]in section: Security History and Prior Incidents
“In November 2022, a logic bug in SushiSwap's KashiPairMediumRiskV1 contract led to asset drainage from affected pools.”
reviewerIn November 2022, a logic bug in SushiSwap's KashiPairMediumRiskV1 contract led to asset drainage from affected pools.Confirmed via search-corroborated content; direct fetch of the cited Medium URL was blocked by a 403 (bot-protection). - #25[confirmed][no action needed]in section: Post-Exploit Security Improvements
“The protocol committed to implementing pausability in high-activity smart contracts, shifting from unlimited token approvals to per-swap approval patterns, allowing adequate audit timelines before deployments, conducting gradual rollouts rather than mass simultaneous multi-chain deployments, and ensuring all new contracts are within scope of bug bounty programs before any UI launch.”
reviewerPost-exploit, SushiSwap committed to pausability, per-swap approvals, adequate audit timelines, gradual rollouts, and including new contracts in bug bounty scope before UI launch.Confirmed directly against the official post-mortem. - #26[confirmed][no action needed]in section: Concurrent SEC Subpoena
“Jared Grey had previously disclosed that SushiSwap received a subpoena from the U.S. Securities and Exchange Commission. Grey publicly released SushiSwap's response to the subpoena around the same time as the exploit, on or around April 10, 2023.”
reviewerJared Grey had previously disclosed that SushiSwap received a subpoena from the SEC, and released the response around the same time as the exploit, on or around April 10, 2023.Confirmed; the page's hedged phrasing ('around the same time,' 'on or around') is appropriate given the sources describe close but not identical timing. - #27[confirmed][no action needed]in the timeline
“SushiSwap launches RouteProcessor2 claim portal (sushi.com/claims/rp2) for Group 1 victims (rescued funds), enabling 1:1 token reclamation after revoking the vulnerable contract.”
reviewerThe RouteProcessor2 claim portal launched April 25, 2023.Date independently verified by decoding the cited tweet's Twitter snowflake ID timestamp.
How this fits together. The reviewer reads the published page and its cited sources and records one finding per claim. A human moderator decides whether each proposed correction is applied; those decisions, and the score changes they cause, appear in the audit log. Earlier review runs are not shown here; only the latest reflects the page as it stands.