A Safe Wallet Lost $7.7M to a Module It Approved Itself

By Alexandr Kerya · · 6 min read

TL;DR - A Safe wallet lost 2,882 rsETH ($7.7 million) on September 15, 2026, when its own liquidity module got routed into an attacker's pool, and an MEV bot grabbed the funds first.

Most of the coverage that week focused on the bot that saved the money. The screening angle got buried under that story: a module doesn't expire, it doesn't ask twice, and a Safe with one switched on can be drained by code its owner never re-read after the day they installed it. This is what happened, why the attacker walked away with nothing, and what it means for anyone who checks a wallet before trusting it.

What happened to the Safe wallet on September 15, 2026?

At 04:38:47 UTC, in block 25,980,525, an attacker triggered a keeper multicall function on a liquidity strategy module the wallet's owner had enabled months earlier to automate an aEthrsETH position. The module, deployed at 0x4f0055926c839D1d960a82CBF84E2eE933958ebC, had an unprotected entry point that forwarded caller-supplied calldata straight into the Safe's own execTransactionFromModuleReturnData function, using operation flag 1: a DELEGATECALL. That's the call type that lets code run with the wallet's own authority, not just call out from it. The attacker pointed the module at a Uniswap v4 pool built for the job. A hook inside that pool unwrapped the wallet's aEthrsETH into plain rsETH and pulled roughly 2,882 of it out, leaving a worthless NFT behind as the only trace of the swap.

Nobody had to sign anything.

How a Safe wallet lost 2,882 rsETH without a single signature.How the rsETH Safe drain happened1. Module already onOwner had enabled anLP module months earlier2. Attacker routes itMulticall points module ata rigged Uniswap v4 pool3. Hook unwraps2,882 rsETH pulled out,a worthless NFT left behind4. Bot front-runs"yoink" captures the fundsin the same blockThe wallet's own pre-approved module carried out every step. No new signature was needed.
A module the Safe's owner had approved months earlier was routed into a malicious Uniswap v4 pool, drained of 2,882 rsETH, then front-run by an MEV bot in the same block.

Why didn't the attacker end up with the stolen rsETH?

Because a bot got there first. An MEV searcher operating under the name yoink was watching the mempool, spotted the malicious transaction before it landed, copied its withdrawal path, and paid the block builder enough to have its own copy included ahead of the attacker's in the same block. It captured the roughly 2,882 rsETH and routed it to a fresh address, 0xC70f00CD7E461686b04B0E912E309becA8b80ea0. Kelp DAO, whose staked ETH derivative the module had unwrapped, paused that receiving address for 24 hours and said its own contracts were untouched and that rsETH remained fully backed.

The attacker built the trap, wrote the multicall, deployed the pool. And still came away with nothing.

Was this a bug in Safe's own contracts?

No. Security researchers who reviewed the transaction and Safe's own documentation agree on that point: modules can execute arbitrary transactions, and a malicious or badly-gated one can take over a wallet entirely, by design. That's the tradeoff a Safe owner accepts the moment they enable one. This module wasn't malicious on purpose. It was a custom strategy executor with a recipe entrypoint that never checked who was allowed to call it, so it did exactly what a DELEGATECALL from an unchecked caller lets it do. The math behind Safe's multisig threshold held. The permission model around one optional add-on didn't.

Does a drain like this reach wallets that had nothing to do with the hack?

Yes, eventually, and that's the part a headline about a clever MEV bot skips. The rsETH is sitting in a paused address right now, and whatever exchange, protocol, or counterparty it moves to next inherits a share of that exposure the moment Kelp DAO's pause lifts. Plastron's own screening corpus tracks 3,901 labeled addresses, and 121 of them are tagged specifically for hack and exploit exposure, kept separate from sanctions or mixer categories. A wallet three hops downstream of a frozen exploit address doesn't get to plead ignorance to an exchange's compliance team. It just gets a lower-confidence version of the same flag.

You can trace a paused or frozen address by hand on Etherscan, following each outgoing transfer one at a time once the hold lifts. Screen the wallet with Plastron instead and get the same hop-by-hop exposure path, plus sanctions and mixer checks across seven EVM chains, in a single report.

What should you check before enabling a module on your own Safe?

Three things, before the module ever touches funds:

  • Read what the module's entry points actually accept, not just the strategy it's marketed to run.
  • Look for operation=1 anywhere in its code. A DELEGATECALL primitive means the module can act with the wallet's full authority, not a limited allowance.
  • Treat "enabled" as permanent until you personally switch it off. A module doesn't retire itself when the strategy it was built for stops making sense.

A dormant module is still a live one.

What a downstream wallet gets checked against.Plastron's labeled corpus, by categoryTotal labeled wallets3,901OFAC SDN sanctioned780Hack & exploit exposure121A wallet downstream of a paused exploit address can pick up the same tag before an exchange ever asks.
Plastron's corpus separates 121 hack-and-exploit addresses from its 780 OFAC-sanctioned entries within 3,901 total labeled wallets - either category can attach to a wallet the moment it receives tainted funds.

FAQ

Does this mean Safe multisig wallets are less secure than other wallets?

No. The multisig threshold that protects a Safe's owner keys was never touched in this incident. The risk sits entirely in optional modules, which any owner can add, remove, or leave dormant, separate from the core signing logic.

Did the attacker keep any of the stolen rsETH?

No. An MEV bot named yoink front-ran the withdrawal in the same block and captured the roughly 2,882 rsETH before the attacker's own transaction could complete.

What is a DELEGATECALL and why does it matter here?

DELEGATECALL is an Ethereum instruction that runs another contract's code using the calling wallet's own storage and authority. A module that accepts one from an unchecked caller can be made to act exactly like the wallet's owner, which is what let this module drain the Safe without a signature.

Can a Safe wallet be screened for exposure the same way as a regular wallet?

Yes. A Safe is a smart contract address on Ethereum like any other, and it can be checked for sanctions, mixer, and stolen-funds exposure the same way a standard wallet can.

Disclaimer: This article is for educational and informational purposes only and is not legal, financial, tax, or compliance advice. Crypto carries risk; you act on this information at your own risk. Always do your own research and consult a qualified professional before making decisions. Views are the author's own and do not constitute financial, legal, or investment advice.

About Plastron

Plastron is a free, non-custodial wallet screening tool. It checks Ethereum and six EVM chains for AML and KYT risk — sanctions exposure, mixer contact, and stolen-funds proximity — and returns a risk report in seconds. It reads public on-chain data only: it never takes custody of funds and never asks for private keys.

How Plastron works and who runs it →

Run the check yourself

Free screening tools for the risks this article covers.

BNB Chain Wallet CheckFantom Wallet CheckLinea Wallet CheckOptimism Wallet Check
Check a wallet

or check your own wallet →

Keep reading

Can a Multisig Wallet Get Sanctioned Like Any Other Address?What to Do If You Received Crypto From a Hacked ProtocolWhy Balancer's Second Hack in a Year Could Flag Your WalletStolen Funds Exposure: How Wallets Inherit It