Kelp DAO 漏洞深度复盘：揭秘 LayerZero 幽灵消息攻击

约 2.92 亿美元资产流失，116,500 枚 \$rsETH 被盗。这是 2026 年迄今为止规模最大的 DeFi 攻击事件。

加密推特（CT）上流传着许多谣言，但事实并非如此。让我来清晰地梳理一下，将链上已证实的事实与尚不确定的疑点区分开来。

PS：如需更深入的调查和证据，请务必查看这份报告：https://gist.github.com/banteg/705d0284513b74ad20f61d90f5b5de62

TL;DR：实际发生了什么

一个结构看起来完全正常的 LayerZero 数据包（nonce 308）在以太坊（Ethereum）上通过了验证、提交并执行——从真实的桥接库存中释放了 116,500 枚 rsETH。然而，在源链 Unichain 上并没有对应的销毁记录、资金扣减或 Nonce 推进。

这并不是一次铸造（mint）漏洞利用，也不是重入攻击（reentrancy）。它是一条“幽灵”跨链消息，被以太坊端误当作合法消息接受并执行。

路径配置成为单点故障

Unichain → Ethereum 的 Kelp 路径被配置为 1-of-1 DVN（去中心化验证网络）：

这是关键的架构弱点。在 LayerZero 的安全模型中，你可以配置 X-of-Y-of-N 验证器组合。而 Kelp 使用了 1-of-1 配置，这意味着只要单个验证器被攻破，就足以在这条路径上伪造任何消息。

重要的是，这并非临时的配置变更。早在漏洞被利用前至少 90 天，这个 1-of-1 设置就已经存在。这是一个长期的设计选择。

LayerZero 自身的基础设施

以太坊端所需的 DVN 地址（0x589ded...）在 Etherscan 上被标记为 “LayerZero: DVN”。这并不是 Kelp 盲目信任的随机第三方验证器，而是 LayerZero 官方的 DVN 产品。

当你选择 LayerZero Labs 作为唯一验证器并配置为 1-of-1 时，实际上是在隐含地信任 LayerZero 自身的运营安全。合理的假设是：“如果 LayerZero 官方的 DVN 出故障，那就是 LayerZero 应该披露的安全问题。”

行业常见的 1-of-1 模式

从调查的大背景来看：在 Kelp 通往以太坊适配器的 12 条入站路径中，有 11 条都配置为 1-of-1。

这并不是针对 Unichain 的特有疏忽，而是 Kelp 在所有链上的标准部署模式。值得注意的是，只有 Unichain 出现了 Nonce 不匹配的情况，其他使用相同配置的路径目前都在正常运行。

如果 1-of-1 配置本身是根本原因，那么理论上所有路径都会出现异常。仅 Unichain 被攻击的事实表明，故障是特定于该路径或特定 DVN 运营商的，而非单纯的配置层缺陷。

幽灵数据包（Nonce 308）

攻击在约 2 分钟内分三个紧凑步骤展开：

• 17:33:35： 以太坊接收库显示 PayloadVerified 交易链接
• 17:35:11： commitVerification —— 数据包被提交 交易链接
• 17:35:35： lzReceive —— 116,500 枚 rsETH 被释放 交易链接

该数据包在结构上与合法包无法区分：具有相同的源元组、接收者，以及与正常的对照包（nonce 307）完全相同的 28 字节 Payload 格式。编码没有畸形。唯一的异常对以太坊端点是不可见的：源链端根本没有发生真实的触发事件。

铁证：Nonce 不匹配

这是证明此次攻击性质最直接的证据：

• 以太坊目标端点： lazyInboundNonce = 308 ✅（接受了 Nonce 308）
• Unichain 源端点： outboundNonce = 307 ❌（从未发送过 Nonce 308）

对于 Kelp 的其他所有路由（Arbitrum、Base、zkSync、Mantle、Scroll 等），源端和目标端的 Nonce 均匹配。Unichain 是唯一存在真实 Nonce 失配的路径。此外，Unichain 源端代币的 totalSupply() 始终保持平稳，从未发生 116,500 枚 rsETH 的销毁。

执行者：一次性混币钱包

LayerZero 的模型将验证与执行分离——一旦数据包通过验证，执行环节是无需许可的。攻击者利用了这一点：

• 配置的执行者（0x4208D6...）处于闲置状态：Nonce 为 0，无代码，无活动。
• 实际执行者（0x4966260...）是一个新钱包，仅有 5 笔交易且全部集中在该 Kelp 路径，并在数小时前通过 Tornado Cash（0x47ce0c...）获取资金。

这是一个刻意的设计：利用 LayerZero 验证后的无需许可执行机制，攻击者自行投递数据包，而无需攻破指定的执行者角色。

DVN 签名者稳定性与管理员扩张

目标 DVN 合约（0x589ded...）并非代理合约，没有可升级的实现插槽（implementation slot）。其签名者委员会（3 名签名者，2 名法定人数）在攻击前后未发生变化，也没有 UpdateSigner 或 UpdateQuorum 事件。

然而，确实发生了以下变化：

• 两个地址（0xD3A227... 和 0xD95D77...）于 2025 年 2 月被授予 ADMIN_ROLE。
• 2026 年 4 月 8 日发生了更大规模的管理员扩张——在攻击发生前 10 天，有 10 笔新的 grantRole(ADMIN_ROLE, ...) 交易。

关键在于，正是这两个地址提交了 Nonce 308 和 309 的 PayloadVerified。它们是长期授权的 DVN 管理员，而非新植入的攻击者私钥。它们还在同一个接收库上验证许多其他数据包，行为与常规 DVN 运营商一致。

资金流向与攻击者活动

116,500 枚 rsETH 在约 5 分钟内被分散到 7 个预先准备好的分支钱包中，所有钱包的初始资金均来自 Tornado Cash。

• 以太坊归集钱包（0x5d3919...）： 收到约 75,700 ETH，Nonce 为 0 —— 目前资金尚未移动。
• Arbitrum 归集钱包（0x5d3987...）： 收到约 30,765 ETH 等值资产，Nonce 为 6，并有一些指向分支钱包的异常零值交易。

攻击者在 Aave（以太坊和 Arbitrum 上）的未平仓头寸仍然活跃：

这些头寸已危险地接近清算阈值，代表了攻击者在 Aave 上的持续风险敞口。

Kelp 的快速响应

• 18:23:11 UTC： Kelp 的 Safe 多签钱包通过 rsETH 代币合约的 sweep(address[],address) 功能冻结了接收地址 0x8b1b6c...，并设置了 transfersBlockedUntil。
• 此举成功阻止了 Nonce 309（第二个涉及 40,000 枚 rsETH 的幽灵数据包）的执行——尽管该包当时已被验证并提交。
• Nonce 309 因 TransfersBlocked 报错回滚。由于适配器有足够的库存（40,357 rsETH），这道封锁是阻止第二次资金外流的唯一屏障。
• Kelp 随后暂停了主网及多个 L2 上的 rsETH 合约。

此次冻结挽救了约 1 亿美元。46 分钟的响应窗口虽然紧迫，但非常有效。目前主网上所有的 rsETH 仍有足额支持。Kelp 核心协议合约中持有的底层 LST 抵押品（stETH、ETHx 等）未受影响。

仍然未知的部分

验证路径中的确切根因尚未锁定：

• 假设 1：LayerZero DVN 已被入侵
  • 支持证据：DVN 带有 LZ 官方标签；10 天前有管理员扩张；提交者为长期管理员。
  • 反对证据：签名者委员会未变；相同的管理员在正常验证其他大量数据包。
• 假设 2：DVN 存在验证逻辑漏洞
  • 支持证据：数据包结构正常；无需源端事件即可触发。
  • 反对证据：其他路径未出现 Nonce 异常。
• 假设 3：Unichain 侧的上游输入错误
  • 支持证据：源端 Nonce 未推进；无销毁事件。
  • 反对证据：路径配置已稳定运行 90 天。

故障范围比“某个薄弱的第三方 DVN”更窄——唯一必需的 DVN 在 Etherscan 上被标记为 LayerZero 相关。但它又比单纯的 LZ 基础设施被破更有迷惑性——同一个 DVN 在其他数百条路由上运作正常。

纠正误解

目前流传的许多说法都过于简化。以下是修正对比：

更广泛的影响

• 对于 LayerZero 用户： 1-of-1 DVN 配置是官方支持并有文档记录的有效最小化设置。但此次事件证明，它会造成单点故障——无论是通过攻击、Bug 还是错误输入。建议采用独立提供商构成的多 DVN 方案。
• 对于 Aave： 协议目前面临约 1.77 亿美元的 rsETH 抵押坏账。在不引发 rsETH 价格崩盘的情况下，这些头寸难以被干净地清算。攻击者头寸的健康因子（1.027–1.032）正处于清算边缘。
• 对于整个生态： 这是 2026 年最大的 DeFi 攻击。攻击者的 ETH 收益（仅以太坊上就有约 75,700 ETH）正闲置在 Nonce 为 0 的钱包中。其下一步动向将受到严密监视。

• 原文链接： x.com/stacy_muur/status/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～