A wallet can have strong multisignature security and still lose millions through software it has authorized.
That is the key lesson from the September 15 rsETH incident.
Security researchers traced a roughly $7.73 million loss from a Gnosis Safe wallet to a custom Uniswap v4 liquidity module. The issue was not in Safe’s core contracts and was not attributed to Kelp DAO’s core rsETH contracts.
The vulnerable component had already been authorized by the wallet.
That authorization gave the attacker a path around the protection users normally associate with multisig custody.
A Multisig Only Protects the Actions That Require Signatures
The common mental model of a multisig is simple:
No transaction can move funds unless enough owners sign.
Modules change that model.
A Safe module can be granted authority to execute certain actions without collecting the normal owner signatures each time.
That is useful for automation.
It is also dangerous.
Once a module has privileged execution rights, its own access controls become part of the wallet’s security boundary.
The Attack Targeted an Authorized Extension
Researchers said the custom module exposed a public multicall path and insufficient authorization checks.
The attacker could manipulate caller-controlled data and route execution through an attacker-created Uniswap v4 hooked pool.
Because the module was already authorized by the Safe, malicious execution could occur inside a privileged context.
This is a classic capability-security problem.
The core wallet can be secure while an extension holds enough authority to defeat the intended protection.
The MEV Twist Makes the Incident More Unusual
The original attacker did not necessarily capture the full value.
A generalized MEV searcher known as “Yoink” observed the exploit transaction and front-ran it, capturing most of the rsETH.
That creates a strange recovery problem.
The funds were removed from the victim, but the entity that ultimately received them may not be the same party that discovered and initiated the exploit.
Kelp DAO temporarily paused the receiving address while stating that rsETH remained fully backed and its core contracts were unaffected.
Why It Matters
Wallet risk is increasingly modular.
Modern smart accounts can authorize trading modules, automation systems, session keys, bridges, plugins and account-abstraction infrastructure.
Every privileged extension expands the attack surface.
The correct security question is therefore not:
“Is Safe secure?”
It is:
What can every authorized module do, and under what conditions?
Authorization Scope Should Be Treated Like Capital at Risk
A useful framework is to measure module permissions in economic terms.
If a module can move $10 million without fresh owner approval, then the module effectively controls $10 million of risk.
Security reviews should therefore map:
- callable functions;
- asset limits;
- destination restrictions;
- upgrade authority;
- delegatecall usage;
- emergency revocation;
- time delays.
The size of the permission should determine the strength of the controls.
Risks and Counterarguments
The incident should not be described as a Safe core exploit.
It should also not be described as an rsETH backing failure.
The evidence points to a custom authorized component used by the affected wallet.
That distinction matters because otherwise users may incorrectly conclude that all Safe wallets or all rsETH holders faced the same vulnerability.
What to Watch Next
Watch whether the MEV-captured funds are returned, the final root-cause report, Kelp DAO’s temporary controls, whether similar modules are deployed elsewhere and whether Safe ecosystem tooling adds stronger permission warnings.
The broader lesson is simple:
A secure wallet can delegate its security away.
FAQ
How much was lost?
Security researchers reported approximately $7.73 million in rsETH.
Was Safe itself hacked?
Researchers said the issue was in a custom authorized module, not Safe’s core contracts.
Was Kelp DAO’s rsETH contract hacked?
Kelp DAO said its core contracts and rsETH backing remained unaffected.
What did the module do?
It provided automated liquidity functionality and had privileged execution rights.
Why did multisig signatures not stop the exploit?
The authorized module could perform privileged actions without requiring the normal owner-signature flow for each operation.