A hacker who spent hours setting up a $7.8 million heist on Ethereum lost the loot within seconds, to a bot. An attacker exploited a Gnosis Safe wallet early Tuesday and moved about 2,900 rsETH, worth roughly $7.8 million, out of the account. Before the transaction could settle, an automated trading bot known as Yoink spotted it in the public queue, paid nearly 19 ETH, about $47,000, to be processed first, and took the tokens for itself.
Security firms BlockSec, Blockaid and SlowMist traced the attack to a flaw in a custom module attached to the wallet, not to Safe itself. The wallet owner had authorized a helper contract linked to a Uniswap v4 liquidity position. That module approved any caller that simply named the contract as its target, letting the attacker issue instructions as if they came from the wallet owner.
How the attack worked
According to Binance Square research citing Odaily, the attacker used a public keeper multicall to insert a custom Uniswap v4 liquidity provider module into the Safe’s approved set. The attacker had first created a hook-based liquidity pool, and the module’s hook unwrapped aEthrsETH into plain rsETH during the call. Two transactions in the same block drained about $7.73 million in rsETH, equivalent to roughly 2,153 ETH at the time.
The check that failed was minimal. Safe modules are meant to carry scoped permissions for one strategy. This one accepted any caller whose calldata referenced the module’s own address. A wallet owner interacting with the module through the intended path would satisfy that check, and so would anyone else who copied the pattern. Blockaid classified the loss at $7.73 million; other trackers rounded to $7.8 million based on 2,900 rsETH in play.
How the bot won the race
Ethereum transactions sit briefly in a public waiting area called the mempool before a block builder includes them. Anyone can watch it. Yoink saw the attack transaction, calculated the value of the tokens it would move, and outbid the attacker for block placement by paying a builder roughly 19 ETH in priority fees, close to $47,000.
The attacker’s transaction still executed, but by then the wallet was empty. The stolen rsETH landed in a fresh address controlled by the bot and was later split across several wallets. Researchers described the outcome as a rare case of funds being intercepted before they reached a mixer or a bridge, the usual laundering route.
Kelp DAO steps in
rsETH is a restaking token issued by Kelp DAO, and the protocol moved fast. It froze the destination address and suspended rsETH deposits and withdrawals for 24 hours, locking the funds in place while it decides what happens next. The freeze also left the token and related vaults holding worthless placeholders in the attacker’s path.
Kelp DAO has precedent for clawbacks. After an earlier hack, a community vote reverted part of the stolen funds. Whether the Yoink operator returns the tokens is a separate question. The bot’s operator has given no public statement, and MEV extraction sits in a legal gray area: the bot did nothing the protocol forbids, it simply paid more for priority.
“The issue stemmed from an over-permissioned Multicall helper module that allowed unauthorized instructions to be executed as if they were from the wallet owner,” Blockaid researchers wrote in their incident summary.
A familiar pattern with a twist
Front-running attacks for profit is standard MEV practice. Bots routinely outbid each other for arbitrage and liquidations. What makes this case unusual is the target: instead of racing other traders for a risk-free spread, Yoink raced a hacker for stolen funds and won.
Security researchers have long noted that MEV bots could act as accidental white hats. The economics line up. A hacker draining a wallet creates a one-block arbitrage opportunity like any other, and a bot watching the mempool does not care who the seller is. Yoink paid $47,000 for a shot at $7.8 million, a trade almost no human could execute in the seconds available.
The same dynamic cuts the other way. If the bot operator keeps the funds, the original victim’s recovery depends on negotiations with an anonymous counterparty who acted purely for profit. Kelp DAO’s freeze gives it leverage, but the tokens sit in a wallet the DAO does not control. Past MEV salvage cases have ended in negotiated bounties, silent retention, and everything between.
What wallet owners should take from it
The root cause was permissioning, not a Safe vulnerability. The wallet owner had granted broad authority to a custom module tied to a Uniswap v4 liquidity strategy, and that module’s access check was a single name comparison. Anyone who could call the module while naming it as the target passed the check.
BlockSec and SlowMist both published post-mortems within hours. Their advice is consistent: treat every module a wallet trusts as attack surface, audit access checks, and avoid granting open-ended authority to helper contracts built for one strategy. The victim, whose identity remains unknown, appears to have run a leveraged rsETH position through the module.
The episode also shows the limits of prevention. The attacker needed one weak permission check. The defense that worked was another profit-seeking actor with faster infrastructure. Kelp DAO’s freeze remains the only reason the funds might return to their owner, and the protocol has 24 hours to decide whether a clawback vote follows.