2026年9月15日，一个以太坊钱包在无需任何所有者签名的情况下丢失了约 2,882 枚 rsETH。该钱包是一个 Safe 多重签名钱包，其设计之所以被认为特别安全，是因为需要多个密钥共同签名。然而，余额仍然被清空，是通过所有者自己启用的一个模块进行的。如果您使用智能合约钱包，在此案例之后的任务既简单又具体：查看您的钱包中启用了哪些模块，并移除任何您不再需要或无法解释的模块。

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

Safe 模块解析：模块在智能合约钱包中可以做什么

Safe 模块是一个独立的智能合约，钱包永久允许其代表执行交易，而无需通常数量的所有者签名汇集。这不是设计缺陷，而是设计的要点。任何想要运行自动工资单、定期再平衡例程或流动性策略的人，都不能让三个人对每一步进行签名。因此，钱包将该部分委托给合约。

从技术上讲，这通过函数 execTransactionFromModule 或其带有返回值的变体进行。已启用的模块调用它，钱包执行模块指示的任何内容。在此过程中，签名阈值并未被绕过；它只是在此路径上未提供。Safe 文档以不同寻常的清晰度阐明了后果：模块可以执行任意交易，只应添加经过审计和信任的模块，恶意模块可以完全接管钱包。这在官方 Safe 智能账户模块文档中有详细说明。

两个特性使模块对攻击者具有吸引力。首先，它们是永久的：一旦激活，模块将保持活动状态，直到有人明确将其关闭。其次，它们在日常中是不可见的。您在发送、接收或余额中看不到它们。它们只出现在您寻找它们的地方。

9 月 15 日的攻击：DELEGATECALL 如何释放 2,882 枚 rsETH

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

故障在于钱包用于 Uniswap v4 流动性策略的定制模块。该模块提供了一个入口点，将调用者提供的数据未经检查地直接传递给钱包函数 execTransactionFromModuleReturnData，操作标志为 1。标志 1 代表 DELEGATECALL，这是决定性的一点。

一句话解释 DELEGATECALL

DELEGATECALL 在您自己的合约的存储中以及以其身份执行外部程序代码，就好像钱包自己编写了该代码一样。能够触发此调用的人不是针对钱包行事，而是作为钱包行事。

由于模块的入口点没有对外部调用者的访问控制，任何地址都可以访问它。而且由于该模块已在钱包中启用，钱包不再进行任何进一步检查。所有者列表和签名阈值在此序列中不再起作用。

Uniswap v4 钩子和 Keeper 多重调用：攻击者的路线逐步解析

该链条经历了几个阶段，并使用了设计为便利功能的功能。攻击者首先调用了一个公开可访问的 Keeper 多重调用函数。Keeper 是保持策略运行的服务，例如通过调整头寸；它们的调用通常是故意开放的，以便任何人都可以触发它们，策略永远不会停滞。

通过该调用，攻击者将钱包的流动性模块引导至他自己控制的 Uniswap v4 池。Uniswap v4 允许所谓的钩子（hooks），即在池中的某些事件旁边自动运行的自定义代码。此池中的钩子属于攻击者。

最后一步是解包。钱包持有的不是裸 rsETH，而是 aEthrsETH，即借贷市场 Aave 的生息包装器内的 rsETH。以这种形式，它不能简单地被带走。钩子将持有物解包为可自由转移的 rsETH，从而使余额变得可移动。

MEV 机器人而非攻击者：为什么“yoink”拿到了钱

攻击者将他的交易发送到了公共内存池（mempool），即任何人都可以检查的未确认交易等待区。一个名为“yoink”的 MEV 机器人在那里读取，重建了相同的序列，并在同一区块内抢先一步。2,882.37 枚 rsETH 落入了属于该机器人的地址，在执行时刻的估值约为 780 万美元。

对于被盗的钱包来说，这没有任何改变。对您来说，这改变了两件事。首先，该案例表明，模块中的开放漏洞不仅涉及发现它的攻击者：一旦序列公开可见，任何足够快的人都可以重建它。其次，它解释了为什么此处的恢复前景与经典盗窃不同。Kelp DAO 在 UTC 时间 06:03 暂停了接收地址 24 小时，并同时声明其自己的合约未受影响，rsETH 仍得到充分支持。故障在于单个钱包的定制模块，而不在于代币或协议。

并非首例：2026 年 5 月 25 日的 SquidRouterModule 漏洞利用

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

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

从这两个案例中可以得出相同的教训。如今多重签名的弱点很少在于签名阈值。它在于钱包在某个时刻允许绕过该阈值的合约。在选择您的托管解决方案时，这是一个几乎不出现在任何产品描述中的标准；我们的硬件钱包比较根据您对签名的实际控制程度对设备进行了排名。

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

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

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

在 Safe 界面中打开您的钱包，并进入设置中的 Modules 条目。它列出了为此钱包启用的合约地址。对于绝大多数私人钱包，那里什么都没有，这是好的情况。如果列出了某些内容，请逐一检查每个地址，并回答三个问题：您还记得启用此模块是为了什么吗？您今天是否仍在使用相关应用程序？您能否为该地址找到可追溯的提供商，并附带审计报告？

如果其中任何一个问题悬而未决，该模块就属于待移除列表。这里的举证责任在于保留方。一个您无法再说出其目的的模块仍在继续工作。

通过合约：getModules 和 isModuleEnabled

任何想要独立于界面了解情况的人都会直接向钱包合约询问。读取函数 getModules 返回所有已启用模块的地址，isModuleEnabled 针对单个地址回答是否已启用。这两个调用都是纯读取调用：它们不收取任何费用，不需要签名，并且可以通过任何区块浏览器或 SDK 运行。

合约路线具有实际优势。它向您显示链的状态，而不是应用程序的渲染。如果界面由于某种原因未能显示模块，它仍会在此处列出。

移除模块：为什么 disableModule 需要您的签名阈值

关闭操作通过钱包函数 disableModule 进行。与查看不同，这是一笔真正的交易。它需要网络费用，并需要您的所有者提供常规数量的签名。在 Safe 界面中，您在刚刚阅读的同一模块列表中启动该过程；然后所有者像确认任何其他交易一样进行确认。

有一个怪癖值得了解：模块在合约中存储为链表，因此关闭还需要前一个条目的地址。界面和 SDK 会自行插入此值。任何手动构建交易的人都必须确定它，否则调用将失败。

将移除安排在网络费用较低的时刻，并在一个会话中处理多个模块。这不适用于纯检查：它不收取任何费用，可以立即进行。

代币批准和模块：两种权限，两次单独检查

这里经常会出现一种混淆，可能导致昂贵的后果。代币批准（合约术语中的 approve）允许外部合约从您的地址借记特定数量的特定代币。相比之下，模块允许外部合约在您的钱包内行动，并针对您所有的持有物进行操作。

范围的差异很大，因此这两种检查不能相互替代。干净撤销其批准的人可能仍然启用了具有完全访问权限的模块。如何清除批准以及撤销在当前 Gas 价格下的成本，在我们的以太坊代币批准指南中有描述。对于模块，除了上述检查外，还适用上一部分的检查。

顺便说一句，这两种检查仅涉及您自己管理的钱包。如果您的余额存放在交易所，其托管方决定此事，那里的清单看起来完全不同。

如 aEthrsETH 之类的再质押包装器：为什么包装代币扩大了损失

该案例的一个侧面值得单独关注。受影响的钱包以多重包装形式持有其以太坊：首先是作为 Kelp DAO 的流动再质押代币 rsETH，然后再次作为借贷市场中的生息 aEthrsETH。每个包装器都是另一个合约，带来权利、规则以及在有疑问时的弱点。

对您来说，这意味着一件事：包装越深，您必须检查的合约链就越长，以便真正了解您的头寸。任何通过再质押和借贷构建收益的人都至少应该能够说出涉及的层。我们的质押平台概述为每个提供商列出了您和您的以太币之间有多少个合约层。

为了完整起见：9 月 15 日，Kelp DAO 明确声明其自己的合约未受影响，rsETH 仍得到支持。包装并未造成损失。它使损失变得可移动，一旦攻击者访问了钱包。

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

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

钱包软件属于其范围，我们在关于钱包制造商报告义务的文章中更详细地阐述了其对提供商的影响。在实践中这意味着：对于总部位于欧盟或向欧盟销售的提供商，您今后应该及时听到关于积极利用的漏洞的消息。

然而，这种保护有一个限制，9 月 15 日的案例清楚地显示了这一点。有故障的模块不是制造商的产品，而是单个钱包的定制合约。对于自建或单独委托的合约，没有人通知您。在那里，检查仍然是您自己的工作。

检查 Safe 模块：要点总结

今天查看您的模块列表。打开智能合约钱包的设置，并阅读已启用的合约地址。这不收取任何费用，也不需要签名。如果您正在考虑您的托管方案，请并行比较哪种解决方案适合您的持有物：设备并排列在我们的硬件钱包比较中。

移除您无法再解释的内容。每个您无法说出其目的或不再使用其应用程序的模块，都应通过 disableModule 关闭。将交易安排在费用较低的时刻。如果您更愿意将日常持有物保留在没有模块逻辑的精简钱包中，候选者在我们的软件钱包比较中。

计算您收益头寸的层数。对于每个包装头寸，记下您和您的以太币之间有哪些合约，并决定额外的收益是否值得这条链。提供商及其合约层在我们的质押平台概述中。

9 月 15 日的案例并不是反对智能合约钱包的论据。它是阅读无人阅读的列表的论据。序列的细节由 The Crypto Times 于 9 月 15 日重建。

（截至 2026 年 9 月 16 日。本文不是投资建议。价格和费用结构会发生变化；购买前请与提供商确认条款。）