Check your Safe Wallet module: How a signature-free module transferred $7.7 million

Disclaimer: Content does not constitute investment advice. Trading involves risks—please invest with caution!

2026年9月15日以太坊钱包安全事件深度解析：Safe模块漏洞与防御指南

2026年9月15日，一个以太坊钱包在无需任何所有者签名的情况下，丢失了约2,882个rsETH。该钱包是一个Safe多签钱包，这种设计通常被认为非常安全，因为需要多个密钥共同签名才能执行操作。然而，余额 nonetheless 被清空，这是通过用户自己启用的一个模块完成的。如果你使用智能合约钱包，此案例后的任务既简单又具体：检查你的钱包中启用了哪些模块，并移除那些你不再需要或无法解释其用途的内容。

本文将解释模块在技术上允许做什么，9月15日的攻击是如何展开的，以及如何自己在几分钟内进行检查。浏览界面不收取任何费用。只有移除模块才是一笔交易，这需要常规数量的签名。

Safe模块详解：智能合约钱包中模块的功能边界

Safe模块是一个独立的智能合约，钱包永久授权它代表自己执行交易，而无需汇聚通常所需的所有者签名数量。

这并非设计缺陷，而是设计初衷。任何希望运行自动工资发放、定期再平衡流程或流动性策略的人，都不能让三个人对每一步都进行签字确认。因此，钱包将该部分权限委托给一个合约。

从技术角度来看，这是通过 execTransactionFromModule函数或其带有返回值的变体运行的。已启用的模块调用该函数，钱包执行模块指示的任何操作。在此过程中并未绕过签名阈值；只是在这条路径上未提供签名要求。Safe文档以非同寻常的清晰度说明了后果：模块可以执行任意交易，仅应添加经过审计和信任的模块，恶意模块可以完全接管钱包。这一点在官方Safe关于智能账户模块的文档中有明确说明。

两个特性使模块对攻击者具有吸引力。首先，它们是永久性的：一旦激活，模块将保持活动状态，直到有人显式关闭它。其次，它们在日常生活中是不可见的。你在发送、接收或查看余额时看不到它们。只有在专门查找时才会显示出来。

9月15日攻击详解：DELEGATECALL如何释放2,882个rsETH

资金流出发生在区块25980525，UTC时间04:38:47。它击中了一个持有Kelp DAO液态质押代币rsETH杠杆头寸的单Safe钱包。安全公司Blockaid和PeckShield率先报告了这一事件；他们的损失数据略有不同，介于773万美元至781万美元之间。数量比美元数字更精确：2,882.37个rsETH。

问题出在一个用于Uniswap v4流动性策略的定制模块上。该模块提供了一个入口点，未经检查地将调用者提供的数据直接传递给钱包函数 execTransactionFromModuleReturnData, the operation flag is 1. Logo 1 stands for DELEGATECALL, which is the decisive point.

Explanation of DELEGATECALL in one sentence: DELEGATECALL executes external program code under your contract store and identity, as if the wallet had written the code itself. The person who can trigger this call is not issuing a command to the wallet, but is acting as the wallet.

Since the module's entry point has no access control for external callers, it can be accessed at any address. And because the module is already enabled in the wallet, the wallet no longer performs other checks. Owner lists and signature thresholds no longer work in this sequence.

Progressive resolution of attack paths for Uniswap v4 hooks and Keeper multi-calls

The chain went through several stages and used functions that throughout were designed as a convenient feature. The attacker first called a publicly available Keeper multicall function. Keeper is a service that keeps strategies running, such as by adjusting positions; their calls are usually deliberately open so that anyone can trigger them, ensuring strategies do not stall.

With this call, the attacker directs the wallet's liquidity module to the Uniswap v4 pool he controls. Uniswap v4 allows so-called hooks, custom code that runs automatically when specific events occur in the pool. The hooks in this pool belong to the attacker.

The last step is unpacking. The wallet does not hold naked rsETH, but aEthrsETH, which is the rsETH in the Aave interest-bearing packaging of the loan market. In this form, it cannot simply be transferred away. The hook unpacks the position into freely transferable rsETH, making the balance movable.

The module remains effective until someone shuts it down. This is why it's worth checking out the list of enabled contracts.

MEV bots, not attackers: How "yoink" obtains funds

Attackers send their transactions to a public memory pool (a waiting area for unconfirmed transactions) that anyone can check. A MEV robot called "yoink" was reading there, recreating the same sequence and pre-empting it in the same block. 2,882.37 rsETH fell into addresses belonging to the robot, with a valuation of approximately $7.8 million at the time of its execution.

This has not changed anything for stolen wallets. For you, this changes two things. First, the case shows that open vulnerabilities in modules don't just involve the attacker who discovered it: once the sequence is publicly visible, anyone fast enough can rebuild it. Secondly, it explains why the recovery prospects here are different from classic theft. Kelp DAO suspended receiving addresses for 24 hours at 06:03 UTC, while also stating that its own contract had not been affected and that rsETH still had full support. The problem lies in the customized modules of individual wallets, not the tokens or protocols themselves.

Not the first case: On May 25, 2026, SquidRouterModule exploited vulnerability

任何人将9月的事件视为孤立事件，都低估了模式。2026年5月25日，一场攻击击中了名为SquidRouterModule的模块。根据报道该事件的媒体，至少有86个以太坊和Base上的Safe钱包受到影响；根据分析，损失估计为320万美元，或在另一种计数中，超过300笔交易的损失接近400万美元。整个过程持续了大约两个小时。

攻击路线不同，结果相同。攻击者没有使用DELEGATECALL入口，而是使用函数 executeSameChainActions() 并冒充授权代理。由于模块在受影响的钱包中已经拥有广泛的权限，钱包合约将这些伪造的指令视为真实。提供商Squid公开表示，被利用的合同仅与其自身产品架构共享名称，与之无关，并且其自身用户和集成商未受影响。

从这两个案例中可以得出相同的教训。今天多签的最弱点很少是签名阈值。它位于钱包在某时允许绕过该阈值的合同中。在选择托管解决方案时，这是一个几乎不出现在任何产品描述中的标准；我们的硬件钱包比较设备排名基于你对签名真正保留的控制程度。

检查Safe模块：如何在五分钟内查看已启用的内容

检查本身并不引人注目，而这正是它经常被忽略的原因。有两条路线，它们回答同一个问题。

通过界面：设置和模块列表

Open your wallet in the Safe interface and enter the Modules entry in the settings. It lists the contract addresses enabled for this wallet. For most private wallets, there is nothing there, which is a good situation. If something is listed, check each address one by one and answer three questions: Do you remember what you enabled for this module? Are you still using relevant apps today? Can you find a traceability provider for this address, including audit reports?

If any of these three issues are outstanding, the module should be placed on the removal list. The burden of proof lies with the reserving party. Modules with unclear purposes will continue to work regardless of whether you can name their purpose or not.

Via contracts: getModules and isModuleEnabled

Anyone who wants to know the situation independently of the interface can directly ask for the wallet contract. The read-only function getModules returns the addresses of all enabled modules, and isModuleEnabled answers whether it is enabled for a single address. Both calls are purely read-only calls: there is no charge, no signature is required, and can be run through any block browser or SDK.

The contract route has one practical advantage. It displays the status of the chain rather than the rendering of the application. If the interface fails to display a module for any reason, it will still be listed here.

Three of the four safeguards hold true: For modules, one open point is enough because each module is allowed to act on its own.

Remove Module: Why disableModule requires your signature threshold

The shutdown operation is run through the wallet function disableModule. Unlike checking, this is a real deal. It incurs network fees and requires a regular number of signatures from the owner. In the Safe interface, you can start the process in the same list of modules you just read; the owner then confirms it like any other transaction.

One quirk worth noting is that modules are stored as a linked list in the contract, so closing also requires the address of the previous entry. This value is inserted automatically in the interface and SDK. Anyone who builds a transaction manually must determine it, otherwise the call will fail.

Choose to schedule removals at times when network costs are lower and process multiple modules in one session. This does not apply to ordinary inspections: it is free and can happen immediately.

Token authorization and module: Two permissions, two separate checks

There is often confusion here and can lead to expensive errors. Token authorization (approve in contract terminology) allows an external contract to deduct a certain amount of a specific token from your address. In contrast, modules allow external contracts to move within your wallet and operate across all your positions.

The scope of influence varies widely, so no one check can replace another. Even someone who cleanly revoked authorization may still enable a module with full access. How to clear authorizations and the cost of revocation under current gas prices are described in our Ethereum Token Authorization Guide. For modules, the inspections in the previous section apply additionally.

By the way, these two checks only involve the wallet you manage yourself. If your balance is on an exchange and its custody determines this, the list there is completely different.

Re-pledge packaging such as aEthrsETH: Why packaging tokens expands losses

Another aspect of the case deserves special attention. Affected wallets hold their Ethereum assets in multiple packages: first, the liquid pledged token rsETH, and then the interest-bearing aEthrsETH in the loan market. Each package is a further contract, bringing its own rights, rules, and weaknesses in the case of suspicion.

For you, this means one thing is most important: The deeper the packaging, the longer the chain of contracts you need to check to truly understand your position. Anyone who builds income through re-pledge and loans should at least be able to say the level involved. Our pledge platform overview explains for each provider how many layers of contract there are between you and your ether.

For completeness: On September 15, Kelp DAO made it clear that its own contracts were not affected and that rsETH still had support. The packaging caused no damage. Once an attacker gains wallet access, it makes the damage movable.

自9月11日起的报告义务：《网络弹性法案》对钱包提供商的改变

对于作为德国用户的你来说，监管变化叠加其上，改变了此类漏洞的处理方式。自2026年9月11日起，欧盟《网络弹性法案》的首批报告义务生效。具有数字元素的产品制造商在意识到主动利用漏洞后24小时内，必须向欧盟机构ENISA和相关国家计算机应急响应团队报告早期警告；详细的漏洞通知最迟在72小时内跟进。该义务也涵盖已进入市场的产品。

钱包软件属于其管辖范围，我们在关于钱包制造商报告义务的文章中详细阐述了对其提供商的后果。在实践中这意味着：对于基于欧盟或向欧盟销售的提供商，未来你应该及时听到关于主动利用漏洞的通知。

尽管这种保护有限，但9月15日的案件清楚地显示了这一点。有问题的模块不是制造商的产品，而是为单个钱包定制的合同。对于自建或单独委托的合同，没有人会通知你。在那里，检查是你自己的工作。