A September 15 Ethereum incident demonstrates a critical distinction in smart-account security: a Safe can require multiple owner signatures and still allow an already-authorised module to move assets without collecting those signatures again.
A user-controlled Safe lost control of an approximately 2,900 rsETH position valued around $7.8 million after an attacker reached a privileged execution path through a custom module.
What happened?
Security researchers traced the incident to a custom liquidity module linked to the victim Safe. The position involved approximately 2,899.99 aEthrsETH held through Aave. The malicious path unwrapped that position into transferable rsETH.
Researchers described an authorised Safe module, a publicly reachable keeper/multicall-style entry point, an attacker-created Uniswap v4 pool and a malicious hook. Because the module was already authorised, the exploit did not need the normal Safe owner signatures.
The original attacker did not capture the main payout
A generalized MEV searcher known as Yoink observed the transaction in the public mempool and executed first. Reporting indicates approximately 2,882.37 rsETH moved to a receiving address later paused by Kelp DAO, while 17.63 rsETH was routed through Uniswap v4.
The victim still lost control of the position even though the original attacker did not receive the main proceeds.
Kelp DAO response
Kelp placed a temporary wallet-level pause on the principal receiving address. Kelp stated that its core contracts were safe, rsETH remained fully backed, normal minting/withdrawals/integrations continued, and the pause applied to one suspicious wallet rather than the entire token.
Safe core was not the identified failure
Security researchers said the issue was not a Safe core-contract or owner-key bug. The dangerous capability came from an enabled module.
Module security therefore depends on module code, who can call it, downstream contracts, hooks, keeper permissions and upgradeability—not only owner keys.
Why this matters beyond one wallet
Many institutional and DeFi smart accounts use modular architectures. A “3-of-5 multisig” label can create false confidence if an authorised module has a separate execution path callable under weaker conditions.
Evidence Status
Confirmed / Security Analysis + On-chain Reporting
~2,900 rsETH affected; authorised module involved; owner-signature path not required; Yoink captured main payout; Kelp paused principal receiver; Kelp said core contracts and backing were safe.
Developing
Final disposition of rsETH, victim recovery, formal module-vendor attribution, consolidated loss and whether additional wallets use the same unsafe configuration.
Risk Assessment
High user-wallet / module risk. The event did not compromise Safe or rsETH system-wide, but it demonstrates how one over-permissioned module can defeat the security assumption associated with multisig ownership.
What to Watch Next
Kelp pause outcome, return/settlement of rsETH, module-vendor response, additional vulnerable wallets and Safe/security-firm recommendations.
FAQ
Was Safe itself hacked?
Current analysis says the Safe core was not the weakness.
Were owner keys stolen?
No owner-key compromise is established.
How much was moved?
Roughly 2,900 rsETH, valued around $7.8M.
Who received the main payout?
An MEV searcher known as Yoink front-ran the original attacker.
Was rsETH unbacked?
Kelp said rsETH remained fully backed.
What is the main lesson?
Authorised modules need the same or greater security scrutiny as owner keys.