$7.73M rsETH Drained Through Malicious Uniswap v4 Hook Permissions Flaw

A Module Authorization Failure, Not a Wallet Breach

At 04:38:47 UTC on September 15, approximately 2,900 rsETH – worth roughly $7.73 million – left Safe wallet 0x40E93a52F6Af9fCD3b476aeDADD7FeABD9f7AbA8 in a single transaction, with on-chain data from Etherscan confirming the loss. The mechanism behind it exposed a specific and underexamined risk in modular smart-account architecture: what happens when a legitimate execution path gets pointed at an illegitimate destination.

How the Attack Was Constructed

Blockchain security firm Blockaid reconstructed the sequence of events. A public keeper multicall invoked an already-authorized custom Uniswap v4 LP Safe module, routing it into a pool that an attacker had created specifically for this purpose. The attacker-created pool contained a malicious hook – a programmable function that Uniswap v4’s architecture allows to run at various points during a swap or liquidity operation.

That hook performed a conversion: it took aEthrsETH, an Aave-wrapped form of rsETH that is not directly transferable, and converted it into standard, transferable rsETH. Once the conversion occurred, the funds were exposed and movable. The hook did not need to bypass any wallet signature or steal an owner’s private key. It simply exploited the execution path the multicall was already permitted to take.

The fact that the multicall was public – meaning anyone could trigger it – and that the LP module was already authorized within the Safe account’s permission set meant the attacker did not need to compromise anything in the conventional sense. They built a pool, deployed a hook inside it, and waited for a call that was always going to happen to be pointed their way.

This is where the legal and compliance dimension becomes harder to ignore. The attack did not involve a stolen key or a broken protocol. It involved a permissions structure that allowed an authorized component to execute against an attacker-controlled target. Whether that constitutes negligence in the design of the module authorization, or represents a gap in how smart-account security is disclosed to users, will likely depend on how the involved parties characterize the failure in any subsequent proceedings.

MEV Bot Capture and the Question of Proceeds

Defimon Alerts tracked what happened immediately after the hook converted the rsETH. An MEV bot identified as Yoink captured the extracted rsETH in the same block as the drain – a detail that raises its own questions about front-running infrastructure and how quickly attacker-released funds are absorbed by automated bots operating in Ethereum’s mempool and block-building environment.

Defimon Alerts identified 0xC70f00CD7E461686b04B0E912E309becA8b80ea0 as the address that received the main proceeds of the transaction. Whether that address is linked to the attacker who deployed the malicious pool, or to the Yoink bot’s operator, or to a third party, has not been publicly confirmed. That distinction matters considerably if any enforcement or recovery action is pursued, since MEV bots that capture funds released by an attacker occupy an ambiguous position – they did not initiate the exploit, but they extracted direct financial benefit from it.

The same-block capture by Yoink illustrates how quickly value moves once a DeFi position is destabilized. Recovery through on-chain means becomes nearly impossible once funds have passed through an MEV bot and, potentially, onward. For anyone assessing liability or pursuing legal remedies, the velocity of these transactions compresses the window for intervention to near zero.

Under existing frameworks in most jurisdictions, tracing stolen digital assets through multiple addresses and automated intermediaries is technically possible but legally cumbersome. Victims generally need to establish that a specific address holds identifiable proceeds of a specific exploit before courts will grant freezing orders or disclosure orders against exchanges or custodians downstream. The involvement of an MEV bot as an intermediate holder adds a layer of factual complexity that most asset-tracing procedures were not designed to handle efficiently.

Safe’s own documentation describes modules as part of its smart-account architecture, designed to let authorized components extend an account’s execution capabilities. That description is accurate – and it is also precisely why the attack worked. The module behaved as designed. The problem was that its authorization extended to a destination that should not have been reachable. Nothing in the Safe core contracts or the rsETH protocol itself was reported as compromised. The failure, as characterized by the reporting and Blockaid’s reconstruction, was localized to the permissions and execution routing around the custom module.

Delegated Module Risk as a Disclosure and Liability Question

That framing – a permissions issue involving a custom module rather than a core compromise – does not settle the question of accountability. Safe’s modular architecture is a feature, not a bug, and is used across a wide range of DeFi protocols and institutional setups. But the more flexible an execution environment becomes, the more the burden of security shifts toward whoever is responsible for what gets authorized and how broadly that authorization is scoped. In this case, neither the wallet owner’s keys nor the rsETH protocol were at fault, which narrows the potential points of failure but does not eliminate the question of who bears responsibility for the module’s design and deployment.

If the custom Uniswap v4 LP Safe module was deployed or authorized by a protocol team, a DAO, or a third-party operator, any legal action would likely focus on what due diligence was conducted before that authorization was granted – and whether users whose funds were held in or accessible through the module were adequately informed of the risks that a public keeper multicall and a custom hook route could combine to produce exactly this outcome. The wallet address 0x40E93a52F6Af9fCD3b476aeDADD7FeABD9f7AbA8 lost 2,900 rsETH. Who owned that position, and under what terms they authorized the module that ultimately routed it into an attacker’s pool, remains the central open question.