2026年7月17日，链下代码文件中缺失的8字节校验让攻击者有机可乘，从Risk Labs运营的中继器中窃取了约450万美元——然而，Across协议的所有用户却毫发无损。Across Solana中继器攻击暴露了区块链所见与链下软件所信任内容之间虽小却至关重要的差距。

要点总结

• 2026 年 7 月 17 日，攻击者利用 Risk Labs 的链下 Solana 中继器中的一个漏洞，伪造了链上从未存在的存款事件。
• 用户资金没有损失或面临风险；所有真实有效的转账都在当天完成或退款。
• Risk Labs 吸收了约 450 万美元的转手资本，净亏损不到 400 万美元，并且随着复苏的继续，亏损还在减少。
• 攻击者向 18 个目的地链提交了 1627 笔伪造存款，总面值约为 4170 万美元；在 Solana 被禁用之前，中继器完成了其中 581 笔存款。
• Solana 服务在大约 12 小时内通过备用 CCTP 路由恢复；执法部门和 SEAL 911 正在积极参与恢复工作。

索拉纳中继器攻击事件详情

此次事件发生在Solana的链上程序和Risk Labs用于读取这些程序的链下软件之间的一条狭窄的技术缝隙内。攻击期间没有资金在链上转移，也没有状态改变。区块链本身运行正常，但监控它的软件却出现了问题。

漏洞的技术原因

Solana 的 SpokePool 合约使用 Anchor 的 CPI 事件模式发出事件：程序通过指定的event_authority PDA调用自身并传递事件数据。Risk Labs 中继器内部的 SvmCpiEventsClient 组件将通过该 PDA 发往 SpokePool 的任何内部指令都视为真实事件。该缺陷很具体：它没有验证用于区分真实事件 CPI 和伪装成事件 CPI 的任意指令的 8 字节 Anchor 事件鉴别器。

这一疏忽为攻击者提供了精准的工具。他们部署了一个包装程序，该程序通过 CPI 嵌入到 SpokePool 的一个看似无害的只读辅助函数 `get_unsafe_deposit_id` 中，并将伪造的`FundsDeposited` 有效载荷附加到该函数上。从中继者的角度来看，这些事件看起来像是合法的存款事件。链上没有任何变化。没有资金转移，没有余额变化，也没有合约被触及。欺骗完全发生在链下读取层。

Risk Labs 后来澄清说，get_unsafe_deposit_id 本身并非漏洞所在。它只是一个无害的只读辅助函数，攻击者只是将其用作攻击载体。根本原因是中继器自身代码库中缺少鉴别器检查。

攻击规模和伪造的沉积物

7月17日05:07至06:14 UTC期间，攻击者从1627个一次性钱包提交了1627笔伪造存款，这些存款分散在18条目标链上。这些伪造头寸的总面值约为4170万美元，全部汇入同一个EVM接收地址。

Risk Labs 的中继器处理了其中 581 笔欺诈性请求，在团队成功禁用 Solana 作为源链之前，已支付了约450 万美元的自有资金。中继器停止处理这些请求后，剩余的约 3700 万美元伪造存款也随之作废。

用户保护和财务影响

事件期间，用户资金没有遭受任何损失。这并非偶然，而是 Across 系统架构本身结构性缺陷的结果。

用户资金无损失或风险

Across 以意图协议的形式运行。用户将资产存入源链上的托管合约；独立的中间商预先投入资金，在目标链上完成转账。协议仅在经过独立的结算流程验证每一笔存款后，才会向中间商支付费用。这种顺序机制确保伪造的存款从未触及用户的托管账户。所有真实的用户存款要么当天完成，要么当天全额退款。

同样重要的是：没有任何智能合约遭到破坏。Solana 程序和所有 EVM 合约在整个事件过程中都完全按照设计运行。整个漏洞存在于链下中继器软件中，而非任何链上逻辑中。

损失仅限于 Risk Labs 的中继资本

Risk Labs直接承担了全部经济损失。中继器支付的总赔偿金约为450万美元。由于约有50万美元的攻击者资金被困在协议内部，净损失低于400万美元，并且随着恢复工作的推进，损失还在持续减少。

与传统桥接架构的对比值得我们深思。在传统的锁定式桥接中，这样的漏洞可能使攻击者直接访问共享的用户资金池。而在基于意图的系统中，中继者的自有资金会承担首次损失——这种设计选择在本例中完全保护了每位用户。

事件响应与恢复

关键缓解措施时间表

攻击被发现后，应对措施迅速展开。以下是7月17日采取的行动顺序（所有时间均为UTC）：

• 05:07 — 首笔伪造存款已提交至 Solana
• 06:14 — 伪造存款流结束；第一个攻击者的地址于 06:16 被列入黑名单
• 08:23 — Solana 已在 API 中禁用作为源和目标链
• 08:35 — Solana SpokePool 链上暂停
• 08:36 — 发布首份公开声明
• 09:37 — 根本原因修复已合并
• 10:26 — 修复程序已部署到 Risk Labs 的所有基础设施
• 17:05 — Solana 存款已通过 CCTP 路由重新启用

根本原因修复程序在检测到问题后约五小时部署完毕。通过备用 CCTP 路由， Solana 服务在大约12 小时内完全恢复。所有其他协议操作在此期间均未受到影响。

路线变更和系统更新

Solana 的订单流现在完全通过备用 CCTP 路由进行路由，Risk Labs 表示该路由覆盖所有主流区块链。在团队重新审核 Solana 链下事件解析逻辑期间，与 Solana 之间的 Intent 路由仍然处于禁用状态，以确认此类漏洞已完全修复，并且事件处理的安全模型在整个技术栈中已实现标准化。

目前也在研发更先进的异常检测技术，旨在自动标记并阻止这种有组织的伪造存款模式，以免造成大量资金损失。

执法部门介入

恢复工作已超越协议本身。Risk Labs正与SEAL 911（事件报告后几乎立即提供支持）以及美国执法部门合作。攻击者的地址已在各大交易所和出站通道上被标记。ACX代币的收购流程则完全不受影响，并按计划继续进行。

安全模型及经验教训

Across意图协议的设计

这次事件成为了对一项精心设计的架构的一次实战检验。Across 最初被设计为意图协议，其决策是让中继节点预先投入资金，而不是动用共享的用户托管资金。这一风险管理策略或许很多用户从未注意到。7 月 17 日，这一决策的价值得到了验证。攻击造成的经济损失是实实在在的，但完全被 Risk Labs 的运营资金所控制。

尽管如此，该事件也揭示了一种结构性矛盾，任何依赖链下事件解析的协议都必须正视这一矛盾。链上合约可以进行正式验证和审计，具有很高的可信度。而链下中继软件则处于一种灰色地带——它解读链上活动并据此采取行动，但其解读逻辑却游离于区块链本身的信任保障之外。仅仅因为这一层缺少一个鉴别器检查，就足以造成450万美元的欺诈性支付。

未来缓解计划和审计

Risk Labs承诺，即使Solana订单流完全通过CCTP运行（这意味着存在漏洞的路径已处于非活动状态），也将重新审核其Solana链下事件解析逻辑。其目标是在重新启用与Solana之间的意图路由之前，确保彻底修复此类漏洞，并规范整个基础设施中事件安全的处理方式。

此次事件引发的更深层次的问题是，业界如何看待链上协议的链下组件。智能合约审计如今已成为标准流程。而链下中继逻辑、事件监听器和解析库等组件历来受到的审查较少——部分原因是它们位于大多数审计人员关注的正式安全边界之外。如果 Across 事件能够改变协议处理这一安全漏洞的方式，那么 400 万美元的损失最终可能会用于资助跨链结算领域更广泛的安全升级。

常问问题

在 Across Solana 中继器攻击中，是否有用户资金损失？

用户资金在任何阶段均未丢失或面临风险。所有真实有效的转账均已于2026年7月17日当天完成或全额退款。

Risk Labs中继器安全漏洞的技术原因是什么？

该漏洞是由链下中继器代码中缺少对 8 字节锚事件鉴别器的验证造成的。这使得攻击者能够伪造存款事件，即使链上实际上没有资金转移，中继器也会将其视为真实事件。

Risk Labs是如何应对针对其Solana中继器的伪造攻击的？

Risk Labs 禁用了 Solana 作为源链，暂停了链上的 Solana SpokePool，在检测到问题后大约 5 小时内部署了根本原因修复程序，并在大约 12 小时内使用回退 CCTP 路由完全恢复了 Solana 服务。

Risk Labs中继器攻击中涉及的智能合约是否已被攻破？

不，没有智能合约被利用。所有 Solana 程序和 EVM 合约在整个事件过程中都完全按照设计运行。漏洞完全存在于链下中继器软件中。

本文由人工智能辅助生成，并经编辑团队审核。