The multisig wasn’t broken—$7.8 million still left the wallet
On September 15, an Ethereum Safe wallet lost about 2,900 rsETH, worth approximately $7.8 million. The issue wasn’t in Safe’s core contracts, nor was it leaked multisig private keys—it was an auxiliary module the wallet had previously authorized.
This module was originally used to automatically execute liquidity operations. Its permission checks mistakenly treated “the call target is the module itself” as a valid authorization. The attacker used this to insert arbitrary instructions, and then Safe proceeded to move the funds out as if it were executing normal module operations.
This highlights a commonly misunderstood aspect of multisigs: M-of-N only governs how many keys are required to approve ordinary transactions. Enabled modules may have the ability to bypass the usual signing flow and directly call the wallet. Even if the multisig door lock is strict, long-term authorized automation modules can still become a side entrance.
Even more dramatically, after the attack transaction entered the public mempool, an MEV bot executed it first. The bot paid about $46,000 to secure ordering and ultimately intercepted around 2,882 rsETH. On-chain transparency makes the attack observable, and it also enables third parties to copy it and front-run.
For corporate treasuries and DeFi users, you can’t just audit the signers—you also need to regularly list enabled modules, spending limits, and callable contracts. Disable modules that are no longer needed, and restrict automation permissions to specific assets, targets, and amounts.
Wallet security depends not only on who holds the keys, but also on which contracts have already been allowed to enter without knocking.
#WalletSecurity #Multisig #DeFi
On September 15, an Ethereum Safe wallet lost about 2,900 rsETH, worth approximately $7.8 million. The issue wasn’t in Safe’s core contracts, nor was it leaked multisig private keys—it was an auxiliary module the wallet had previously authorized.
This module was originally used to automatically execute liquidity operations. Its permission checks mistakenly treated “the call target is the module itself” as a valid authorization. The attacker used this to insert arbitrary instructions, and then Safe proceeded to move the funds out as if it were executing normal module operations.
This highlights a commonly misunderstood aspect of multisigs: M-of-N only governs how many keys are required to approve ordinary transactions. Enabled modules may have the ability to bypass the usual signing flow and directly call the wallet. Even if the multisig door lock is strict, long-term authorized automation modules can still become a side entrance.
Even more dramatically, after the attack transaction entered the public mempool, an MEV bot executed it first. The bot paid about $46,000 to secure ordering and ultimately intercepted around 2,882 rsETH. On-chain transparency makes the attack observable, and it also enables third parties to copy it and front-run.
For corporate treasuries and DeFi users, you can’t just audit the signers—you also need to regularly list enabled modules, spending limits, and callable contracts. Disable modules that are no longer needed, and restrict automation permissions to specific assets, targets, and amounts.
Wallet security depends not only on who holds the keys, but also on which contracts have already been allowed to enter without knocking.
#WalletSecurity #Multisig #DeFi