LayerZero回应KelpDAO 安全事件： 攻击事件是怎么发生的

2026 年 4 月 18 日，KelpDAO 遭遇攻击，损失约为 2.9 亿美元。初步迹象表明，此次事件可归因于一个高度复杂的国家级攻击组织，极有可能是朝鲜的 Lazarus Group，更具体地说是其旗下的 TraderTraitor。此次事件仅局限于 KelpDAO 的 rsETH 配置，其直接原因是其采用了单一 DVN（去中心化验证网络）设置。该事件未波及任何其他跨链资产或应用。

此次高度复杂攻击的目标是污染 LayerZero Labs DVN 所使用的下游 RPC 基础设施。目前，所有受影响的 RPC 节点均已弃用并完成替换，LayerZero Labs DVN 已恢复上线。我们公开这些细节，旨在帮助社区更好地理解并防范这种新出现的国家支持型攻击向量。

背景

LayerZero 的模块化安全架构

LayerZero 协议建立在模块化、可由应用端配置的安全基础之上。去中心化验证网络（DVN）是独立实体，负责验证跨链消息的完整性。关键在于，该协议并不强制规定单一的安全配置。相反，它赋予每个应用和资产发行方定义自身安全态势的能力，包括选择依赖哪些 DVN、采用何种组合方式以及设定怎样的冗余阈值。

行业最佳实践——也是 LayerZero 向所有集成方明确推荐的做法——是配置具备多样性和冗余性的“多 DVN”方案。这意味着任何单一 DVN 都不应成为单点信任或单点故障。

范围与影响

仅限于 rsETH

我们对 LayerZero 协议上的活跃集成进行了全面审查，可以确信此次事件未扩散至任何其他资产或应用。该事件完全局限于 KelpDAO 的 rsETH 配置，这是其采用单一 DVN 设置的直接后果。

受影响的应用是由 KelpDAO 发行的 rsETH。事件发生时，其 OApp 配置依赖于 1-of-1 的 DVN 设置，仅由 LayerZero Labs 作为唯一验证者——这种配置直接违背了 LayerZero 一直向所有集成合作伙伴推荐的多 DVN 冗余模型。采用单点故障配置意味着没有独立的验证者来发现并拒绝伪造的消息。LayerZero 和其他外部方此前曾多次向 KelpDAO 传达有关 DVN 多样化的最佳实践。尽管有这些建议，KelpDAO 仍选择使用 1/1 DVN 配置。如果采用了适当加固的配置，则需要多个独立 DVN 达成共识，即使在任一 DVN 被攻破的情况下，也能使此次攻击失效。

我们对 DVN 配置的立场已在集成检查清单中明确说明（见下图）。

事件经过

2026 年 4 月 18 日，LayerZero Labs 的 DVN 成为一次高度复杂攻击的目标，该攻击很可能源于 Lazarus Group（具体为 TraderTraitor）。此次攻击专门设计用于操纵或污染下游 RPC 基础设施，通过攻破 LayerZero Labs DVN 在验证交易时所依赖的 RPC 节点法定配额（Quorum）来实现。攻击并非通过利用协议、DVN、密钥管理或其他方式的漏洞完成。

相反，攻击者设法获取了我们 DVN 使用的 RPC 列表，并攻破了其中两个独立节点——这两个节点运行在彼此无直接连接的独立集群上——随后替换了 op-geth 节点上运行的二进制文件。由于我们遵循最小权限原则，他们无法攻破实际的 DVN 实例。然而，他们利用这些受损节点作为支点执行了 RPC 欺骗攻击。其恶意节点使用了一个专门定制的有效载荷（payload），旨在以尽可能少的警告向 DVN 伪造消息。该伪造消息仅展示给 DVN，而节点会对任何其他发起 RPC 请求的 IP 地址（包括我们的 Scan 服务）返回真实信息；Scan 服务会将攻击相关信息同步到我们所有的内部可观测性基础设施中。这一设计经过精心安排，目的是防止安全监控系统从外部 RPC 报告的信息中发现异常。此外，该程序被设计为在攻击完成后自毁：禁用 RPC、删除恶意二进制文件及相应的本地日志和配置。

然而，即便如此仍不足以伪造消息。我们的 DVN 设置经过了信任最小化设计，同时结合使用内部和外部 RPC 以实现冗余。为了完成攻击，他们对未受损的 RPC 发起了 DDoS 攻击，触发了系统向受污染 RPC 的故障切换（failover）。以下为攻击期间外部 RPC 流量的示意图。

外部 RPC 遭受 DDoS 攻击。攻击发生在太平洋时间上午 10:20 至 11:40 之间。

攻击期间内部尝试访问外部 RPC 的记录。

由于这种操纵，由 LayerZero Labs 运营的 DVN 实例确认了实际上从未发生过的交易。

RPC 验证是所有链下服务（包括跨链桥、交易所等）面临的一个根本性限制。我们分享这些经验，旨在帮助整个行业学习并适应这类新型攻击向量。

LayerZero Labs 的安全态势

我们希望明确此次攻击所需突破的安全环境。

在内部，我们在每一台设备上都部署了完整的端点检测与响应（EDR）系统；实施了按应用划分的访问控制；采用完全隔离的环境和完整的系统日志；拥有专职的内部安全团队及外部安全供应商；并且目前正处于 SOC2 审计验证的最后阶段。

我们的 DVN 基础设施结合运行在自营和外部 RPC 节点上，确保不存在对单一供应商的系统性依赖。所有访问生产系统的设备均受到严格的设备管理和端点安全控制。访问策略遵循最小权限原则，具有分层认证要求，并进行定期访问审查。

后续路径

• LayerZero Labs DVN 已恢复运行。所有采用多 DVN 设置的应用均可放心恢复运营。
• 我们正在联系所有仍采用 1/1 DVN 配置的应用，推动其迁移到具备冗余性的多 DVN 设置。
• LayerZero Labs DVN 将不再为任何使用 1/1 配置的应用进行签名或消息证明。
• LayerZero Labs 正在与全球多个执法机构直接沟通，并配合其调查。
• 我们正在积极支持行业合作伙伴和 Seal911 追踪资金流向。

我们希望在此明确一点：在整个事件过程中，LayerZero 协议本身完全按预期运行，未发现任何协议漏洞。

如果这是一个单一系统或共享安全系统，影响可能会非常广泛，波及所有应用。LayerZero 架构的核心特征在于模块化安全，在本次事件中，它恰恰发挥了预期的作用：将攻击风险完全隔离在单个应用中，整个系统不存在扩散风险，没有其他 OFT 或 OApp 受到影响。

我们将继续致力于维护 LayerZero 生态系统的安全与完整，并将在调查取得进展时提供进一步更新。

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