公开事件复盘Solana · Ethereum复盘 v1.0事件评级 · 严重风险

Wormhole 跨链桥签名校验绕过事件复盘

基于公开披露资料的事后复盘,非 umibit 受托审计。2022-02-02,攻击者利用 Wormhole Solana 端 签名校验的一处账户校验缺失——使用了已弃用的 load_instruction_at、且未校验传入的 Sysvar 账户地址, 伪造出一个「已验签」的 SignatureSet,从而生成合法 VAA、无抵押铸出 120,000 wETH。Jump Crypto 在约 24 小时内补足全部 ETH,保住了 wETH 的偿付能力。

这是一份公开事件复盘,不是 umibit 受托审计。

本页基于公开披露资料对一起真实安全事故做事后分析,用于安全研究与方法论说明,并不代表 umibit 与 Wormhole(Solana ↔ Ethereum 跨链桥) 存在任何业务关系。文中每一项结论均可对照下方「核验来源」独立核查。

报告编号
WORMHOLE-2022
受影响项目
Wormhole(Solana ↔ Ethereum 跨链桥)
区块链
Solana · Ethereum
语言
Rust(Solana program)
损失规模
≈ $326M(120,000 wETH 无抵押铸出)
报告版本
复盘 v1.0
事件日期
2022-02-02
事件评级
严重风险

相关合约 / 链上对象

事件涉及的合约 / 链上对象及其可核验身份(地址 / commit),据公开披露整理。

名称类型commit地址
verify_signatures(Solana program)签名校验指令
post_vaa / complete_wrappedVAA 处理 / 铸造
攻击者地址(Ethereum)链上地址0x629e7Da20197a5429d30da36E77d06CdF796b71A

根因与漏洞

严重 3
ID标题严重状态类别
WH-01使用已弃用的 load_instruction_at,未校验 Sysvar 指令账户地址严重Resolved 已修复签名 / 凭证校验
WH-02攻击者传入伪造的 Sysvar 账户,绕过 Secp256k1 预编译验签严重Resolved 已修复签名 / 凭证校验
WH-03伪造 SignatureSet 经 post_vaa 生成合法 VAA,complete_wrapped 无抵押铸币严重Resolved 已修复业务逻辑

公开事件复盘。 本页基于公开披露资料对一起真实安全事故做事后分析,用于安全研究与方法论说明, 并非 umibit 受托审计。文中数据请以「核验来源」所列公开资料为准。

事件概览

Wormhole 是连接 Solana、Ethereum 等多链的跨链桥,由一组「守护者(guardian)」对跨链消息(VAA)签名背书。 2022-02-02,攻击者在 Solana 端 无任何真实抵押 铸出 120,000 wETH(约 $3.26 亿),其中 93,750 ETH 被桥回以太坊,其余在 Solana 端变现。

根因:账户校验缺失导致验签被绕过

Solana 没有「合约直接调用」的概念,验签依赖 指令内省verify_signatures 会读取「前一条指令」来确认 Secp256k1 预编译确实校验过守护者签名。问题出在两点叠加:

  1. 代码使用了 已弃用的 load_instruction_at,而非带地址校验的 load_instruction_at_checked
  2. 因此 没有校验传入的 Sysvar 账户是否为真正的 Sysvar1nstructions 系统地址

攻击者于是传入一个 伪造的 Sysvar 账户,让 verify_signatures 误以为「签名已被预编译验证」,凭空造出一个 合法的 SignatureSet。再经 post_vaa 生成「有效」VAA、调用 complete_wrapped 铸出 wETH。

修复方式正是把调用换成会校验账户地址的 load_instruction_at_checked

samczsun(Paradigm)曾指出:修复提交在攻击前约 9 小时就已推到 Wormhole 的公开 GitHub,但尚未部署上线; 他同时评估这更可能是一次依赖版本升级的「附带修复」,而非有意的安全补丁。此点按其原始表述引用。

影响与处置

  • Jump Crypto 在约 24 小时内补足了全部 120,000 ETH,wETH 的偿付能力得以维持,普通用户未直接受损。
  • $10M 白帽招安未获回应,被盗资金最终未追回,于 2023 年初被转移。

AI 视角 · 为什么这类风险只会更多

Wormhole 是一个教科书级的 「验签看似做了,其实被绕过」:漏洞不在加密算法本身,而在 对‘谁在证明’这一前提账户的校验缺失。这类「信任了一个未经校验的输入/账户」的模式,跨语言、跨链反复出现, 且极易被自动化工具按模式批量发现——攻击者正用脚本与 AI 大规模扫描这类范式。

防御必须同等地自动化、前置:把「外部传入的关键账户/地址是否被校验」「是否误用了已弃用的不安全 API」当作 可规模化检测的清单项,在上线前对 全量路径 做覆盖,而不是依赖人工恰好读到那一行。

核验来源

本页结论所依据的公开资料,每项数据与论断都可对照独立核查。

如何核验本复盘

请对照上方「核验来源」所列的官方根因分析、安全机构报告与区块浏览器,独立核查事件日期、损失规模、根因与链上地址等每一项论断。

← 返回安全事件复盘