Super Sushi Samurai Hack
What happened
Super Sushi Samurai's SSS token contract had a self-transfer accounting flaw. An exploiter repeatedly sent their full SSS balance to the same address, creating additional tokens, then sold the inflated supply into the SSS/ETH Thruster liquidity pool on Blast. Contemporary reports valued the withdrawal at about $4.6 million, while security roundups used a $4.8 million estimate.
The custom transfer implementation did not handle the aliasing case where sender and recipient are the same address. _update and _postCheck separately mutated balances before resolving that case, allowing a stale recipient calculation to overwrite the sender debit and create tokens through repeated self-transfers.
How it happened
The custom tax-transfer logic split balance handling across _update and _postCheck. It credited balances[to] before finalizing the sender debit. When from equalled to, both variables resolved to the same storage slot, so the final recipient assignment overwrote the debit with a stale-balance-plus-transfer calculation.
Transferring the full balance to oneself therefore approximately doubled it. The exploit contract repeated this process 25 times, then swapped the artificially inflated SSS for WETH from the Thruster pool. This was a token-state accounting failure, not a flash-loan or oracle attack.
Protocol details
Evidence
- report Post-mortem rekt.news
- transaction Blast Exploit Transaction blastscan.io
- analysis DeFiLlama defillama.com
- analysis Super Sushi Samurai Official Incident and Recovery Announcements t.me
- analysis Super Sushi Samurai Hack Analysis blog.solidityscan.com
- analysis HashDit March 2024 Incident Sharing docs.hashdit.io
- analysis Super Sushi Samurai Liquidity Pool Incident theblock.co
Build your security review skills
Work through hands-on labs covering real exploit mechanics, review techniques, and defensive patterns.
