Security · Onchain
2,882 rsETH Went Back to the Safe's Owner 30 Hours After an MEV Bot Took It
A publicly callable module on a leveraged Ethereum Safe let an attacker pull rsETH out, and the MEV bot Yoink front-ran the attacker and got there first. Kelp froze the address holding the tokens for 24 hours. Four and a half hours after that freeze expired, the address sent every token to one of the Safe's owners. No outlet had reported that as of midday UTC on Wednesday.
At 04:38:47 UTC on Tuesday, September 15, an Ethereum Safe lost 2,900 of the Aave-wrapped restaked ether it used as collateral. The exploit's author didn't get it. The transaction that landed in block 25,980,525 was signed by the MEV searcher Etherscan labels "Yoink." Security monitor Defimon Alerts said the attacker had sent the exploit "straight into the mempool," where Yoink front-ran it and captured the whole thing. Blockaid put the confirmed loss at about $7.73 million. PeckShield said about $7.81 million.
Most coverage stopped at that twist. The story kept going onchain. At 10:38:35 UTC on Wednesday, the address holding Yoink's take sent 2,881.37 rsETH to 0x8c2a…fee8. Twelve minutes earlier it had sent a 1 rsETH test. The two transfers add up to exactly the 2,882.37 rsETH it had received. According to the Safe contract's own getOwners call, 0x8c2a…fee8 is one of the Safe's three owners.
How the Safe was opened
The victim, 0x40E9…AbA8, is a Safe v1.3.0 wallet. It held a leveraged rsETH position on Aave V3 as aEthrsETH, the receipt token Aave issues against deposited rsETH. Nobody broke a key, and nobody found a bug in Safe itself. Blockaid called it "module-authorization abuse on that Safe, not a Safe core / owner-key bug."
Safe modules are contracts a Safe's owners authorize to move funds without collecting owner signatures. They're how automated strategies run. According to Blockaid's reconstruction, this Safe had a custom Uniswap v4 liquidity module, and a public keeper function could reach it. The path ran from the keeper through a helper contract into the Safe's execTransactionFromModuleReturnData, then through the module into Permit2 and Uniswap's PositionManager. The attacker created its own v4 pool with a hook. When the module added liquidity to that pool, the hook unwrapped the aEthrsETH into plain rsETH, which then left the Safe.
Defimon's account differs in detail but agrees on the core problem. It says the module exposed an entrypoint that forwarded "fully caller-supplied calldata" into the Safe with a DELEGATECALL "and no gating on the external caller." So anyone who could reach it could run code as the Safe. This desk hasn't read the module's source, and neither the module's author nor the Safe's owners have said anything publicly. The transfer records in the exploit block match the outline both firms describe: 2,900 aEthrsETH went from the Safe to Uniswap v4's PoolManager, were burned for 2,900 rsETH, and 2,882.37 of that went to 0xC70f…0ea0. The same block also shows a token the attacker deployed, whose name is "Permissionless Attacker Token."
Eighty-one minutes with the door open
The first drain wasn't the last. Blockaid listed five more drains between 05:24 and 05:54 UTC. This desk pulled every aEthrsETH transfer out of the Safe from the exploit block onward and found 18 extraction transactions from six sending addresses. The last one landed at 05:55:23. Yoink's own address accounts for the two largest: the first 2,900 and a second pull of 157.7 at 05:53. A different address took 50 through a contract it deployed in the same transaction. Four other addresses took the rest, each taking between half a token and 9.5 tokens.
aEthrsETH pulled from the Safe, by sending address
One of the owners closed it at 06:00:11 UTC. In a transaction signed by 0x8c2a…fee8, the Safe emitted DisabledModule events for the helper contract and the Uniswap v4 module. That was 81 minutes after the first drain. At 07:20:23 a second transaction disabled nine more modules. As of Wednesday's block 25,989,940, the Safe's module list is empty. The Safe needs only one of its three owners' signatures to act.
The freeze, and what came after it
At 06:03 UTC on Tuesday, Kelp posted that it had put 0xC70f…0ea0 "under a temporary 24-hour pause," during which "rsETH cannot move in or out of it." It called that "a precautionary, wallet-level measure only," and said its contracts were safe and rsETH fully backed. Some outlets reported this as a pause on rsETH transfers generally. Coinpedia wrote that Kelp "temporarily paused rsETH transfers for 24 hours." Kelp's own post described a freeze on a single address.
That window closed around 06:03 UTC on Wednesday. At 10:26:23, 0xC70f…0ea0 sent 1 rsETH to the owner address. At 10:38:35 it sent the remaining 2,881.37. 0xC70f…0ea0 signed both transactions itself, and it's an ordinary account, not a contract, that has sent 613 transactions. As of this desk's check it holds no rsETH.
A transfer doesn't come with an explanation. Nobody has said whether the return was negotiated, whether a bounty was agreed, or who controls 0xC70f…0ea0. Not all of Yoink's haul went back through this route either. In the exploit block, Yoink's contract swapped 17.63 rsETH on Uniswap v4 before forwarding the rest. Its second pull of 157.7 rsETH at 05:53 went out through a DEX (The Crypto Times identified it as Fluid) and never reached the frozen address. Between the exploit block and block 25,989,940, the owner address received no rsETH or WETH from anyone except the frozen address. The roughly 66 tokens taken by other addresses are also unaccounted for.
One more thing happened around the return. At 10:29 and 10:32 UTC, and again at 10:47 and 10:50, transactions signed by two unrelated addresses, 0x0124…6641 and 0xd643…6908, produced zero-value rsETH transfer records from 0xC70f…0ea0 to two addresses. Both start with 0x8c2a and end in fee8, just like the owner's address. That's the signature of address poisoning, where a lookalike is planted in a wallet's history in the hope it gets copied by mistake.
The size of what was left
The 3,124 aEthrsETH that left the Safe was a slice of a much larger position. As of block 25,989,940, the Safe still held 50,278.79 aEthrsETH. Aave's getUserAccountData for the address returned about $131 million of collateral against $124 million of debt, with a health factor of 1.0048. The dollar figures move with the ether price. Aave liquidates a position when that figure drops below 1. The loss didn't cause that thin margin, but it shows how little room the position has. Kelp's statement doesn't mention the position, and the desk isn't suggesting it did anything wrong. The failure was in a module the Safe's owners chose to authorize.
The Take
Look at who acted and how fast. A generalized front-runner saw the attack before its author could land it. A token issuer froze one holder's balance within 90 minutes, a power most rsETH holders probably don't think about. The owners needed 81 minutes to disable their own module, and other addresses kept draining it for 77 of them. The happy ending, if that's what the 10:38 transfer is, came from two parties the victim never chose to rely on: an MEV operator's decision to give the tokens back and a token contract that can freeze an address. That's luck, not a security model. A Safe module is an owner signature that never expires. Any module that forwards caller-supplied calls deserves the same audit as the keys, and a kill switch the owners can reach in minutes, not an hour and a half. The owners, or whoever sent the tokens back, should now say publicly what was agreed. Otherwise the next searcher has only this outcome to go on.