An attacker drained roughly 2,900 rsETH — about $7.8 million at the time — from a Gnosis Safe wallet on Ethereum during the early hours of September 15, 2026. The theft, however, did not enrich the person who wrote it. A generalized MEV bot publicly tagged as "Yoink" observed the exploit transaction sitting in the public mempool, paid to execute first in the same block, and captured the tokens itself.
The episode was flagged by Blockaid, PeckShield, BlockSec and SlowMist, and reconstructed in detail by CoinDesk and The Crypto Times from on-chain data. It is the largest single-wallet loss on Ethereum since the Symbiosis bridge incident earlier this month.
The victim and the position
The victim wallet is a Gnosis Safe running the v1.3.0 singleton implementation. It held a leveraged rsETH position on Aave V3, in the form of aEthrsETH, the interest-bearing wrapper Aave issues to depositors. In a single transaction, about 2,899.99 aEthrsETH was burned and the same quantity of rsETH withdrawn from Aave — then routed out of the Safe entirely.
The reconstructed call path
According to Blockaid's reconstruction, execution ran from a public keeper address through a helper contract into the Safe's execTransactionFromModuleReturnData function, onward through a custom Uniswap v4 liquidity-provider module, Permit2, and the Uniswap v4 PositionManager. The attacker then supplied the drained liquidity into a Uniswap v4 pool created minutes earlier around a token researchers labeled "Permissionless Attacker Token" — a pool whose hook was under the attacker's control. That hook unwrapped the aEthrsETH into freely transferable rsETH, at which point the tokens left the Safe.
The flaw, per SlowMist and BlockSec, sat in the helper contract the wallet owner had authorized: its permission check approved any caller that named the helper itself as the target. AstraSec summarized the root cause as a flawed authorization check in the Multicall contract. Blockaid's framing was blunt: module-authorization abuse on that Safe — not a Safe core or owner-key bug.
Because the module was already an authorized Safe extension, no owner signature and no threshold were required to move the funds. We publish a separate technical analysis of what this means for smart-wallet security alongside this report.
Yoink gets there first
The exploit transaction was broadcast to the public mempool rather than sent privately — and it never settled to the attacker. Yoink's execution is recorded in the primary extraction transaction, included at 04:38:47 UTC in block 25980525. CoinDesk reports the bot paid roughly $47,000 in priority fees to jump the queue, then moved 2,882 rsETH onward to a separate receiving address.
Loss estimates differ only marginally: Blockaid placed confirmed losses at about $7.73 million, while PeckShield pegged the front-run size at roughly $7.81 million.
Kelp DAO freezes the receiving address
Kelp DAO, the issuer of rsETH, said it detected suspicious activity on the address that received the tokens and — "out of an abundance of caution" — placed it under a temporary 24-hour wallet-level pause, during which rsETH cannot move in or out. The issuer stressed that its core contracts were unaffected and that rsETH remains fully collateralized.
That pause window was due to expire at approximately 06:00 UTC on September 16. At the time of publication, Kelp DAO had not announced an extension, a resolution, or any commitment from the bot operator. The funds are effectively immobilized only for as long as the issuer's restriction — or the holder's goodwill — keeps them in place.
What this is not
Three attributions of blame are being circulated and all three remain unsupported by the evidence so far. This was not a Kelp DAO protocol exploit — the protocol's contracts were not the entry point. It was not a vulnerability in Safe's core contracts — the failure was in a third-party module the owner chose to trust. And no attribution of the exploit attempt has been confirmed by any vendor; a possible architectural link discussed by on-chain researchers remains speculation at this stage.
TrustGrade tracks the security posture of protocols, wallets and infrastructure providers. Verified registry scores and security scans arrive with TrustGrade Code Scoring in December 2026.