Ethereum rsETH exploit drains $7.73M from Safe wallet via Uniswap v4 flaw

An unidentified Safe wallet user has lost roughly $7.73 million worth of rsETH in an Ethereum rsETH exploit that exposed a weak point inside one of Uniswap’s newest liquidity tools. The loss was flagged by blockchain security firm Blockaid, which traced the attack to a custom module built for Uniswap version 4, one of decentralized finance’s most closely watched protocols.

Key takeaways

• A Safe wallet user lost about $7.73 million worth of rsETH in the exploit, according to Blockaid.
• The attacker used a public keeper multicall function to target a custom Uniswap v4 liquidity provider module.
• Stolen funds were routed into an attacker-created hooked pool.
• The attack specifically hit Uniswap version 4’s liquidity provider architecture.

Massive $7.73 Million rsETH Loss from Ethereum Exploit

The victim’s identity has not been disclosed, but the scale of the loss is not in question. Blockaid reported that the Safe wallet holder saw about $7.73 million in rsETH drained through the exploit, marking one of the more significant single-wallet losses tied to Uniswap v4 infrastructure since the protocol’s rollout.

Affected User and Asset

rsETH, a liquid staking token, was the asset targeted in the breach. Liquid staking derivatives like rsETH are frequently used across DeFi as collateral or trading pairs, which makes them an attractive target when a vulnerability opens up inside a liquidity module that handles them.

Quantified Impact

The $7.73 million figure represents the value of rsETH pulled from the Safe wallet at the time of the exploit. Blockaid’s report does not indicate whether the user has recovered any portion of the funds, and no broader tally of losses beyond this single wallet has been confirmed.

Method of Attack: Public Keeper Multicall Exploit

The attacker exploited a public function known as a keeper multicall, using it to interact with a custom liquidity provider module built on top of Uniswap v4. This is where the incident becomes notable from a technical standpoint: keeper multicalls are typically designed to let automated systems batch routine operations, not to serve as an entry point for redirecting user funds.

Targeted Uniswap v4 Liquidity Provider Module

The module in question was a custom build layered onto Uniswap v4’s architecture rather than a stock component of the base protocol. Uniswap v4 introduced a hooks system that lets developers attach custom logic to liquidity pools, expanding flexibility but also widening the surface area for potential missteps in how third-party modules are coded and secured.

Mechanics of the Keeper Multicall

By leveraging the public nature of the keeper multicall function, the attacker was able to trigger a sequence of calls that ultimately redirected assets away from their intended destination. The exact coding flaw that allowed this redirection has not been detailed publicly, but the outcome was clear: funds meant to stay within the liquidity provider module instead flowed toward the attacker.

Funds Routed to Attacker-Controlled Hooked Pool

Once the multicall exploit executed, the stolen rsETH was funneled into a pool the attacker had created specifically for the operation. This “hooked pool” made use of Uniswap v4’s hooks feature, the same customizable logic layer that made the vulnerable liquidity module possible in the first place.

Attacker-Created Hooked Pool Details

Setting up a dedicated pool before executing the attack suggests a degree of premeditation. Rather than exploiting the vulnerability and hoping for an opportunistic payout, the attacker appears to have engineered a destination for the funds in advance, using the hooks framework to receive and likely obscure the stolen rsETH.

Implications for Uniswap v4 Security

This incident lands squarely on the custom module built around Uniswap v4 rather than on the core protocol itself, but that distinction may offer little comfort to developers building on the platform. Uniswap v4’s hooks system is prized precisely because it lets teams build specialized liquidity logic, yet this same flexibility means any given hook or module carries its own independent security profile. A flaw in one custom module does not necessarily reflect a flaw in Uniswap v4’s base code, but it does show how the expanded surface area created by hooks can become a target when third-party implementations aren’t hardened against public-facing functions like keeper multicalls.

For rsETH holders and liquidity providers more broadly, the episode is a reminder that interacting with newer, custom-built DeFi modules carries risks distinct from those tied to a protocol’s audited core. Public functions intended for routine automation, such as keeper calls, can become attack vectors if permissions and access controls aren’t tightly scoped.

FAQ

What was the financial impact of the Ethereum exploit on the Safe wallet user?

The Safe wallet user lost about $7.73 million worth of rsETH in the exploit.

Which protocol and module were targeted in the exploit?

A custom liquidity provider module built on Uniswap version 4 was targeted.

How did the attacker execute the exploit?

The attacker exploited a public keeper multicall function to reroute funds away from the liquidity provider module.

Where were the stolen funds routed during the attack?

The stolen rsETH was routed into an attacker-created hooked pool built using Uniswap v4’s hooks feature.

Article produced with the assistance of artificial intelligence and reviewed by the editorial team.