An Ethereum user lost approximately $7.73 million in rsETH after an attacker exploited a Safe module execution path to redirect assets through an attacker-controlled Uniswap v4 liquidity pool.

The affected Safe address (0x40e93a52f6af9fcd3b476aedadd7feabd9f7aba8) was targeted early on September 15. Security monitoring identified two transactions responsible for the loss. Available evidence points to the wallet’s custom module and its interaction with a malicious hook, rather than a vulnerability in Safe’s core smart-account contracts.

Custom Module Routed Assets Into a Malicious Pool

The attack used a public keeper multicall to invoke a custom Uni V4 LP Safe module attached to the account. The execution routed liquidity into a Uniswap v4 pool created with an attacker-controlled hook, allowing the malicious routing logic to access assets involved in the position.

The hook then converted the victim’s aEthrsETH position into transferable rsETH. aEthrsETH represents rsETH supplied to Aave, so the attacker first needed to move the position out of its Aave receipt-token form before extracting the underlying rsETH.

Safe’s module architecture allows authorized extensions to execute transactions independently of the normal multisignature flow. Modules can automate complex DeFi operations, but Safe warns that they are security-critical because an enabled malicious or vulnerable module can execute arbitrary transactions from an account. Safe’s documentation on modules is available here.

Because the public keeper multicall could invoke the account’s custom module, the relevant security boundary extended beyond the Safe’s signer flow to the module’s authorization and transaction logic. For similar DeFi-enabled accounts, reviewing the Safe contract alone would not fully describe the account’s active execution surface.

The attack did not compromise Safe’s core multisig contracts, signer keys or Ethereum itself. The identified failure path involved the account’s custom module and an attacker-controlled Uniswap v4 hook. A similar separation emerged in May, when a SquidRouterModule exploit drained 86 Safe accounts across Ethereum and Base while leaving the underlying Safe contracts outside the identified failure path.

MEV Bot Captured the Extraction

The attack transaction was intercepted within the block by an MEV operation associated with the address Etherscan labels MEV Frontrunner Yoink.

The bot front-ran the original extraction and captured the profitable transaction path before the attacker could complete it as submitted. The victim still lost the rsETH because the underlying malicious execution succeeded, while the transaction ordering changed which external address ultimately captured much of the extracted value.

The Safe was left with only a liquidity-position NFT from the malicious pool instead of the rsETH-backed position it held before the transactions.

rsETH Draws Renewed Security Attention

rsETH is Kelp DAO’s liquid restaking token and remains integrated across Ethereum lending and liquidity markets. Its use inside Aave created the aEthrsETH collateral involved in the wallet drain.

Kelp’s token also experienced a major security disruption earlier this year. An April Kelp DAO exploit released roughly $292 million in rsETH from cross-chain infrastructure and created substantial downstream exposure across DeFi lending markets.

The September 15 loss is a separate event. Current evidence centers on the individual Safe’s module execution, the attacker-controlled Uniswap v4 hook and the resulting conversion of the wallet’s Aave-backed rsETH position. No broader compromise of Safe, Aave, Kelp DAO or the rsETH token contract has been established.

Source: Crypto Adventure.