Check Your Safe Wallet Modules: How One Module Moved $7.7 Million Without a Signature

On September 15, 2026 an Ethereum wallet lost around 2,882 rsETH without a single owner signature being required. The wallet was a Safe multisig, the very design that counts as particularly secure because several keys have to sign together. The balance drained anyway, through a module the owners had enabled themselves. If you use a smart contract wallet, the task after this case is small and concrete: look at which modules are enabled in your wallet, and remove anything you no longer need or can no longer explain.

This article explains what a module is technically allowed to do, how the September 15 attack unfolded, and how to run the check yourself in a few minutes. Going through the interface costs you no fee. Only removing a module is a transaction, and that needs the regular number of signatures.

Safe module explained: what a module may do in a smart contract wallet

A Safe module is a smart contract of its own that the wallet permanently allows to execute transactions on its behalf, without the usual number of owner signatures coming together. That is not a flaw in the design, it is the point of the design. Anyone who wants to run automatic payroll, a recurring rebalancing routine or a liquidity strategy cannot have three people sign off on every step. So the wallet delegates that part to a contract.

Technically this runs through the function execTransactionFromModule, or its variant with a return value. An enabled module calls it, and the wallet executes whatever the module instructs. The signature threshold is not circumvented in the process; it is simply not provided for on this path. The Safe documentation spells out the consequence with unusual clarity: modules can execute arbitrary transactions, only audited and trusted modules should be added, and a malicious module can take over a wallet entirely. It is set out in the official Safe documentation on smart account modules.

Two properties make modules attractive to attackers. First, they are permanent: once activated, a module stays active until somebody explicitly switches it off. Second, they are invisible day to day. You do not see them when sending, not when receiving and not in the balance. They show up only where you go looking for them.

The September 15 attack: how DELEGATECALL released 2,882 rsETH

The outflow landed in block 25980525 at 04:38:47 UTC. It hit a single Safe wallet holding a leveraged position in rsETH, the liquid restaking token from Kelp DAO. The security firms Blockaid and PeckShield reported the incident first; their damage figures differ slightly and sit between 7.73 and 7.81 million dollars. The quantity is more precise than the dollar figure: 2,882.37 rsETH.

The fault sat in a bespoke module that the wallet used for a liquidity strategy on Uniswap v4. This module offered an entry point that passed caller-supplied data through unchecked, straight to the wallet function execTransactionFromModuleReturnData with operation flag 1. Flag 1 stands for DELEGATECALL, and that is the decisive point.

DELEGATECALL in one sentence

DELEGATECALL executes foreign program code in the storage and under the identity of your own contract, as though the wallet had written that code itself. Whoever can trigger this call is not acting towards the wallet but as the wallet.

Because the module's entry point had no access control for external callers, any address at all could reach it. And because the module was already enabled in the wallet, the wallet checked nothing further. The owner list and the signature threshold no longer played any part in this sequence.

Uniswap v4 hook and keeper multicall: the attacker's route step by step

The chain ran through several stages and used functions designed as convenience features throughout. The attacker first called a publicly accessible keeper multicall function. Keepers are services that keep a strategy running, for instance by adjusting positions; their calls are often deliberately open so that anyone can trigger them and the strategy never stalls.

Through that call, the attacker steered the wallet's liquidity module towards a Uniswap v4 pool he controlled himself. Uniswap v4 allows what are known as hooks, custom code that runs automatically alongside certain events in a pool. The hook in this pool belonged to the attacker.

The last step was the unwrapping. The wallet did not hold bare rsETH but aEthrsETH, that is rsETH inside the interest-bearing wrapper of the lending market Aave. In that form it cannot simply be carried off. The hook unwrapped the holding into freely transferable rsETH, and with that the balance was mobile.

An MEV bot instead of the attacker: why "yoink" got the money

The attacker sent his transaction into the public mempool, the waiting area of unconfirmed transactions that anyone can inspect. An MEV bot called "yoink" was reading along there, rebuilt the same sequence and got in first within the same block. The 2,882.37 rsETH landed on an address belonging to the bot, worth around 7.80 million dollars at its valuation at the moment of execution.

For the wallet that was robbed, that changes nothing. For you it changes two things. First, the case shows that an open weakness in a module does not concern only the attacker who finds it: as soon as the sequence is publicly visible, anyone fast enough can rebuild it. Second, it explains why the prospects of recovery differ here from a classic theft. Kelp DAO paused the receiving address at 06:03 UTC for 24 hours and stated at the same time that its own contracts were untouched and that rsETH remained fully backed. The fault sat in a bespoke module of a single wallet, not in the token and not in the protocol.

Not the first case: the SquidRouterModule exploit of May 25, 2026

Anyone treating the September incident as a one-off underestimates the pattern. On May 25, 2026 an attack hit a module running under the name SquidRouterModule. According to the outlets that reported it, at least 86 Safe wallets on Ethereum and Base were affected; depending on the analysis, the damage is put at 3.2 million dollars, or in another count at just under 4 million dollars across a good 300 transactions. The sequence lasted around two hours.

The route of attack was a different one and the result was the same. Instead of a DELEGATECALL entry, the attackers used the function executeSameChainActions() and passed themselves off as authorised delegates. Because the module already held far-reaching rights in the affected wallets, the wallet contracts treated the forged instructions as genuine. The provider Squid stated publicly that the exploited contract merely shared a name with its own product architecture and had no connection to it, and that its own users and integrators had not been affected.

The same lesson can be drawn from both cases. The weakest point of a multisig today is rarely the signature threshold. It lies in the contracts that the wallet at some point allowed to work around that threshold. When choosing your custody solution, that is a criterion which appears in barely any product description; our hardware wallet comparison ranks the devices by how much control over signing really stays with you.

Checking Safe modules: how to see what is enabled in five minutes

The check itself is unspectacular, and that is exactly why it so often goes undone. There are two routes, and they answer the same question.

Through the interface: settings and the module list

Open your wallet in the Safe interface and go to the Modules entry in the settings. It lists which contract addresses are enabled for this wallet. For the vast majority of private wallets there is nothing there, and that is the good case. If something is listed, go through each address one at a time and answer three questions: do you still remember what you enabled this module for? Do you still use the associated application today? And can you find a traceable provider for the address, complete with an audit report?

If any one of those questions stays open, the module belongs on the list for removal. The burden of proof here sits on the side of keeping. A module whose purpose you can no longer name carries on working regardless.

Through the contract: getModules and isModuleEnabled

Anyone who wants to know independently of an interface asks the wallet contract directly. The read function getModules returns the addresses of all enabled modules, and isModuleEnabled answers yes or no for a single address as to whether it is enabled. Both calls are pure read calls: they cost no fee, need no signature and can be run through any block explorer or an SDK.

The contract route has a practical advantage. It shows you the state of the chain and not the rendering of an application. If an interface fails to display a module for whatever reason, it is still listed here.

Removing a module: why disableModule needs your signature threshold

Switching off runs through the wallet function disableModule. Unlike looking, this is a real transaction. It costs network fees and needs the regular number of signatures from your owners. In the Safe interface you start the process in the same module list you have just been reading; the owners then confirm as they would for any other transaction.

One quirk is worth knowing: the modules are stored in the contract as a linked list, and switching off therefore also needs the address of the preceding entry. Interfaces and SDKs insert this value themselves. Anyone building the transaction by hand has to determine it, or the call fails.

Schedule the removal for a moment when network fees are low, and work through several modules in one session. That does not apply to plain inspection: it costs nothing and can happen right away.

Token approvals and modules: two permissions, two separate checks

This is where a confusion regularly arises that can turn expensive. A token approval, approve in contract jargon, allows an outside contract to debit a certain amount of a certain token from your address. A module, by contrast, allows an outside contract to act inside your wallet, and to do so across all your holdings.

The difference in reach is considerable, which is why neither check replaces the other. Someone who has cleanly revoked their approvals can still have a module with full access enabled. How to clear out the approvals and what a revocation costs at the current gas price is described in our guide to token approvals on Ethereum. For modules, the check from the previous section applies on top.

Both checks, incidentally, only concern wallets you manage yourself. If your balance sits with an exchange, its custody decides the matter, and the checklist there looks entirely different.

Restaking wrappers like aEthrsETH: why wrapped tokens enlarge the damage

One side aspect of the case deserves attention of its own. The affected wallet held its Ethereum in multiply wrapped form: first as the liquid restaking token rsETH, then once more as interest-bearing aEthrsETH in the lending market. Every wrapper is a further contract that brings rights, rules and, in case of doubt, weaknesses of its own.

For you that means one thing above all: the deeper the wrapping, the longer the chain of contracts you would have to check in order to really understand your position. Anyone building yield through restaking and lending should at least be able to name the layers involved. Our overview of staking platforms sets out for each provider how many contract layers sit between you and your ether.

For completeness: on September 15 Kelp DAO explicitly stated that its own contracts were not affected and that rsETH remains backed. The wrapping did not cause the damage. It made the damage mobile, once the attacker had access to the wallet.

Reporting duty since September 11: what the Cyber Resilience Act changes for wallet providers

For you as a user in Germany there is a regulatory change on top, and it alters how such gaps are handled. Since September 11, 2026 the first reporting duties of the EU Cyber Resilience Act have applied. Manufacturers of products with digital elements have to report an actively exploited vulnerability within 24 hours of becoming aware of it as an early warning to the EU agency ENISA and to the relevant national computer emergency response team; the detailed vulnerability notification follows within 72 hours at the latest. The duty also covers products already on the market.

Wallet software falls under it, and we have set out the consequences for providers in more detail in our piece on the reporting duty for wallet makers. In practice this means: with a provider based in or selling into the EU, you should in future hear about an actively exploited gap promptly.

This protection has a limit, though, and the September 15 case shows it clearly. The faulty module was not a manufacturer's product but a bespoke contract for a single wallet. For self-built or individually commissioned contracts there is nobody who notifies you. There, the check stays your own job.

Checking Safe modules: what to take away

1. Look at your module list today. Open the settings of your smart contract wallet and read the enabled contract addresses. It costs no fee and no signature. If you are thinking about your custody anyway, compare in parallel which solution suits your holdings: the devices sit side by side in our hardware wallet comparison.
2. Remove what you can no longer explain. Every module whose purpose you cannot name, or whose application you no longer use, belongs switched off via disableModule. Schedule the transaction for a moment with low fees. If you would rather keep your day-to-day holdings in a lean wallet without module logic, the candidates are in our software wallet comparison.
3. Count the layers of your yield position. For every wrapped position, note which contracts sit between you and your ether, and decide whether the extra yield is worth that chain to you. The providers and their contract layers are in our overview of staking platforms.

The September 15 case is no argument against smart contract wallets. It is an argument for reading the one list nobody reads. The details of the sequence were reconstructed by The Crypto Times on September 15.

(As of September 16, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)