Deep Analysis: The Safe Module Authorization Exploit and the MEV Race — A Full-Chain Review

1. What Happened

In the early hours of September 15, 2026, a wallet holding a leveraged restaking position on Ethereum was emptied of roughly 2,900 rsETH, about $7.73M, in a single transaction confirmed in block 25,980,525 at 04:38:47 UTC. The victim was a Gnosis Safe running the Safe Singleton implementation version 1.3.0, holding aEthrsETH — Aave's interest-bearing wrapper for deposited rsETH — as collateral on Aave V3. The position was burned and the equivalent in rsETH withdrawn, then unwrapped and moved out of the wallet without the owner signing anything. The exploit transaction itself had been broadcast to the public mempool; an automated MEV searcher executed first in the same block and took the tokens, and the attacker's transaction then failed.

2. The Architecture

A Safe is a smart-contract wallet: funds sit at the Safe address, and movements require a threshold of owner signatures. That design is deliberately extensible — a Safe can authorize modules that execute transactions on its behalf, which is how treasury wallets automate recurring operations, manage positions, or let third-party keepers rebalance them. Modules are therefore a convenience layer with real power: once whitelisted, a module can generally call into the Safe's execution context, including, for some patterns, via delegatecall. Alongside the Safe sat a custom Uniswap v4 liquidity-provider module that could manage the wallet's positions, a helper contract the wallet used to check whether a caller was authorized, and a Multicall contract the wallet had previously approved for batched calls. None of these is a Safe product; all of them were attached to this wallet by its owner.

3. The Flaw: The Caller Gate That Was Never There

Two defects compounded, and both are about who may give an instruction. First, the module exposed an entry point that forwarded fully caller-supplied calldata into the Safe's execTransactionFromModuleReturnData function — with the operation flag set to one, meaning delegatecall — and never gated the external caller. Because the module was already an authorized Safe module, any address able to reach that entry point could execute arbitrary code inside the Safe's own execution context. Second, the helper contract intended to verify whether a caller was authorized had a flawed check: setting the target parameter to address(this) caused the inner multicall to pass validation, because the message sender in that nested call was the contract itself. Security researchers were explicit that this is a component-level failure — Safe's core contracts, the owner set and the signature threshold were never the failing part.

4. The Attack, Step by Step

The reconstructed call path runs from a public keeper address (0x4f005592…) through a helper contract (0xeA18B13d…) into the Safe's execTransactionFromModuleReturnData, then through the custom Uniswap v4 liquidity module at 0xDcDc4ef8…, on through Permit2 and the v4 PositionManager, and into a Uniswap v4 pool created for the occasion and carrying an attacker-controlled hook. That hook performed the unwrapping: the wallet's aEthrsETH became freely transferable rsETH, which then left the Safe. Four things are worth noticing. The exploit required no private key and no owner signature. It reused infrastructure the wallet trusted, so no novel contract had to be deployed for the wallet to interact with. It ran through standard Uniswap tooling — Permit2, the PositionManager — which is exactly why the call path looked routine. And the entire sequence was broadcast publicly, in a mempool anyone can watch.

5. The Race

The exploit's most unusual feature is that it was executed in the open. The searcher Yoink paid roughly 18.93 ETH — about $46,000 — to a block builder for priority, claimed 2,900 rsETH at the top of block 25,980,525, moved 2,882.37 rsETH to a receiving address, and swapped the residual 17.63 rsETH for about 18.95 ETH. The attacker's own transaction confirmed later in the same block and failed. In economic terms this was not a theft with an anonymous beneficiary; it was an auction, won by the participant willing to pay the most for block position, with the victim paying the bill. Two consequences follow. First, the recovery picture is different from a normal exploit: the tokens are at a known address held by an identifiable operator rather than scattered through mixers. Second, the security lesson is uncomfortable — if your exploit is visible in the mempool, your window is not the hours it takes to patch, it is the seconds it takes someone else to replicate your transaction, and the same early-disclosure logic cuts both ways, as the Liquid Network's on-chain white-hat negotiation showed two weeks ago.

6. Containment and Recovery

The only control that fired was at the issuer. Kelp DAO, which issues rsETH, detected activity on the receiving address and placed it under a 24-hour wallet-level pause at 06:03 UTC — a token-level action that stops rsETH moving in or out — while stating that its own contracts were unaffected, that rsETH remained fully backed, and that minting, withdrawals and integrations continued normally. That pause has since expired. No freeze has been reported, nothing has been returned, and no commitment to return has been made. Analysts expect the searcher to give the tokens back, which is a reasonable expectation and not a fact; this desk does not count expectations as recoveries. The residual ~18.95 ETH converted on-chain and the ~18.93 ETH paid to the builder are outside any claim. For context, this is rsETH's second 2026 incident after April's 116,500 unbacked rsETH minted through a LayerZero verifier compromise — the two share no mechanism, and the issuer's contracts and backing were not at fault in either.

7. The Money Trail

The trail is short and unusually legible. The victim wallet is 0x40E93a52F6Af9fCD3b476aeDADD7FeABD9f7AbA8. The unwrapped position left through the module and the attacker-created v4 pool; 2,882.37 rsETH landed at the searcher's address, and 17.63 rsETH became about 18.95 ETH, of which about 18.93 ETH went to a block builder as the priority payment. There is no mixer step in the published trail and no evidence that the original attacker received anything at all. What is unresolved is ownership rather than location: whether the searcher is a party that returns the funds, a party that keeps them, or a party that ends up in litigation is not a technical question, and no public commitment exists on any of the three.

8. The Lesson

Three lessons, in descending order of how much they cost to learn. First, an authorized module is an owner: every module, keeper, helper and approval attached to a treasury wallet should be inventoried, and each entry point that can reach fund-moving functions must be checked for a caller gate independent of the wallet's signature policy — 'the wallet trusts it' is not the same as 'only the wallet may call it'. Second, delegatecall with caller-supplied calldata is the single most dangerous pattern in this incident; it turned a convenience module into an execution proxy for anyone with a mempool view. Third, incident response for on-chain exploits now runs on a clock set by the mempool: the rsETH race was decided in seconds, by a fee, and the only lever that worked in the whole incident — the issuer's address-level pause — was a token-level authority that most projects do not have. Wallets that cannot pause their own assets should assume that whoever watches the mempool gets their money before they finish reading the alert.