NEAR Intents 于 2026 年 10 月 1 日披露了一起发生在 BNB Chain 上、涉及约 $3.8M USDT 的漏洞利用事件，并将该事件追溯至其 Omni 充值与提现基础设施和 NEAR Intents 智能合约之间交互中存在的 bug。
该事件影响的是 NEAR Intents 周边的跨链层，而非 NEAR Protocol layer 1 本身。NEAR 表示，网络持续出块并处理交易，零停机运行；与此同时，NEAR Intents 暂停了服务并修复了合约侧漏洞。截至 10 月 2 日，具体的 bug 类型和确切的失效组件尚未公布，但现有事实指向一个严重的桥接记账与提现授权边界问题。
核心要点：NEAR Intents 的 $3.8M 漏洞利用事件表明，桥接安全必须证明：每一笔资产释放，都对应于每条已连接链上真实、唯一且此前未被使用的充值或扣账。修复智能合约固然必要，但完整防御还必须覆盖 relayer、桥接基础设施、签名者控制以及对账逻辑。
NEAR Intents 漏洞利用期间发生了什么？
攻击者利用 Omni 充值与提现基础设施和 NEAR Intents 智能合约之间交互中的 bug，导致 NEAR Intents 在 BNB Chain 上损失约 $3.8M 的 USDT。在公开披露前，该资金流失已可在链上观察到；NEAR Intents 随后暂停服务、修复合约侧问题，并表示将全额赔偿受影响用户。
链上活动显示，在 9 月 30 日美国东部时间下午，10 USDT 和 11 USDT 的小额转账从被抽干的合约中转出。这些小额转账符合攻击者在尝试大额提取前进行验证的特征，即测试提现、记账或释放路径是否按预期运行。
随后，从 9 月 30 日 23:54 UTC 至 10 月 1 日 06:08 UTC，共发生了五笔较大额转账。这些转账单笔金额约为 $35,000 至 $1.5M。安全分析将 BNB Smart Chain 热钱包的损失估计为 $3.865M，而另一项链上追踪发现，约 3.87 million USDT 从被抽干的合约中被归集。
NEAR Intents 于 10 月 1 日约 12:53 UTC 公开披露了此次漏洞利用。该协议称，在 SHIELD 检测到异常活动后，其服务已停止，合约修复在约一小时内完成。在基础设施完成修复期间，预计 11 个网络上的充值和提现将继续不可用约 12 小时。
| 事件阶段 | 日期或时间 | 具体事件 | 安全意义 |
|---|---|---|---|
| 初始探测 | 9 月 30 日，美国东部时间下午 | 10 USDT 和 11 USDT 从被抽干的 BNB Chain 合约中转出 | 小额转账可揭示资产释放路径是否可被利用 |
| 主资金流失开始 | 9 月 30 日，23:54 UTC | 五笔较大额转账中的第一笔开始发生 | 漏洞利用从探测阶段转入提取阶段 |
| 主资金流失结束 | 10 月 1 日，06:08 UTC | 第五笔较大额转账完成 | 可见的资金提取持续了数小时 |
| 公开披露 | 10 月 1 日，约 12:53 UTC | NEAR Intents 披露已停止服务，并指出基础设施与合约交互存在 bug | 事件沟通发生在链上资金流失之后 |
| 公布返还期限 | 10 月 2 日，00:18 UTC | 攻击者获得 48-hour 返还资金窗口 | 所述截止期限约为 10 月 4 日，00:18 UTC |
公开披露的受影响资产为 BNB Chain 上的 USDT。这一范围很重要，因为它将该事件界定为应用和桥接基础设施事件，而非 NEAR 基础网络遭到入侵，或所有 NEAR Intents 资产发生普遍性故障。
NEAR Intents 已在约 35 条区块链上处理了超过 $30B 的交易量，截至 9 月 22 日，其仪表盘显示历史总交易量为 $31.4B。具备如此规模路由能力的系统，不仅需要安全的智能合约，还需要在不同链、桥接运营方、结算合约、监控系统及运营暂停流程之间维持一致的状态假设。
NEAR Intents 通常如何在链之间转移资产？
NEAR Intents 通过其 intents.near Verifier 合约来结算用户指定的跨链结果。该合约维护已存入 token 余额的账本，在发生 swap 时更新这些记录，并仅通过提现和桥接路径释放 token。此次漏洞利用涉及充值与提现基础设施同该结算层交互的边界。
NEAR Intents 用户签署的是预期结果，而非直接指定每一个执行步骤。Solver 和做市商竞相完成该结果，选定的结果随后在链上结算。该模型能够改善跨链执行，但也形成了广泛的信任与验证攻击面：结算账本必须正确识别哪些资产已充值、哪些资产已交换，以及哪些资产可以提现。
NEAR Intents 文档列出了三种具有不同信任模型的桥接系统：
- Omni Bridge，由 Near One 运营。
- POA Bridge。
- HOT Bridge。
HOT Bridge 的设计与此次事件分析尤其相关，因为公开分析认为，被抽干的 BNB Chain 合约是 NEAR Intents 文档中列出的 HOT Bridge 金库地址，而非 NEAR Intents 的主 vault。该关联属于分析结论，而非官方最终根因判定；截至 10 月 2 日，NEAR Intents 尚未确认究竟是哪一个组件发生故障。
在 HOT Bridge 中，每条支持链上的 locker 合约持有原生资产。NEAR 上的合约以一对一关系铸造对应的 omni-token。Validator MPC 签名为充值和提现提供授权，并且该设计规定每个 nonce 必须只能使用一次。
该架构具有数项不可妥协的安全属性：
- BNB Chain 上的一次资产释放必须对应真实的锁定、扣账或已结算权益。
- 一条充值消息在执行后不得被重放。
- 签名者授权必须绑定至准确的链、资产、接收方、金额和 nonce。
- 不能仅因外部组件声称提现请求有效，便接受该请求。
- 必须持续将金库余额与账本及已授权桥接状态进行对账。
根据我们在 Soken 审计智能合约的经验，最危险的桥接故障往往发生在系统边界处。即使合约能够正确执行其本地规则，若上游消息、链下服务或跨链记账假设在缺乏充分独立验证的情况下被接受，合约仍可能释放资产。
被暂停的 11 个网络与 NEAR Intents 文档中的 HOT Bridge 链列表相符：BNB Chain、Polygon、TON、Optimism、Avalanche、Stellar、Monad、X Layer、ADI、Scroll 和 Plasma。Ethereum、Base、Arbitrum、Solana 和 Bitcoin 未被暂停。链列表的匹配支持了以 HOT Bridge 为重点的假设，但并不能证明确切的脆弱组件。
关于该 bug 已知什么，仍有哪些未知？
NEAR Intents 已确认，Omni 充值与提现基础设施和 NEAR Intents 智能合约之间的交互存在 bug，但截至 10 月 2 日，NEAR Intents 尚未披露确切组件或漏洞类别。任何断言称该问题确定是签名绕过、重放漏洞、记账错误或 validator 遭入侵的说法，均超出了现有证据的范围。
“交互”这一表述至关重要。它表明漏洞未必是某一个合约 function 中简单而孤立的编码缺陷。当两个各自看似合理的组件，对状态转换的含义、最终性或唯一性存在分歧时，跨链系统往往会发生故障。
例如，若链下组件针对从未最终确定的事件生成了批准，若合约接受提现消息却未永久消耗该消息，或者记账层记录了一笔底层 locker 实际上未收到的余额，则桥接释放路径可能失效。这些属于不同的技术机制，但都具有相同的安全失效：资产在没有等值锁定资产或有效扣账的情况下被释放。
NEAR Intents 事件在整体形态上类似于数起重大桥接事件，但其已确认细节仍有区别。
| 事件 | 日期 | 报告损失 | 已确认的失效形态 |
|---|---|---|---|
| Wormhole | 2022 年 2 月 | About $325M | 签名验证 bug 使 guardian 批准可被伪造，并在无抵押物的情况下铸造 120,000 wETH |
| Nomad | 2022 年 8 月 | About $190M | 一次升级将受信任 root 设置为零，导致每条消息都被视为已证明 |
| Kelp DAO over LayerZero | 2026 年 4 月 | About $292M to $293M | 1-of-1 verifier 配置允许虚假的 burn 在 Ethereum 上释放资金 |
| Liquid Network | 2026 年 9 月 6 日 | About $320M | range-proof 验证缓存 bug 使无支撑的 L-BTC 可被 peg out 为真实 BTC |
| NEAR Intents | 2026 年 10 月 1 日 | Approximately $3.8M | Omni 充值与提现基础设施和 NEAR Intents 智能合约交互中存在已确认的 bug |
Wormhole、Nomad、Kelp DAO 和 Liquid Network 共享一种常见的释放侧失效模式：桥接接受了一笔并未映射至真实锁定或扣账的 credit、proof 或消息。NEAR Intents 尚未确认 10 月 1 日的漏洞利用是否遵循了完全相同的机制，但其桥接金库背景使得这一不变量成为事后分析首先应解决的问题。
Ronin Bridge 则构成了有益的对比。2022 年 3 月的 Ronin 事件涉及 9 个 validator 密钥中的 5 个遭到入侵。这主要是密钥管理与 validator 阈值失效，而非合约错误地将无支撑 credit 识别为合法的情形。
NEAR Intents 已承诺在其发布流程中加入形式化验证。当形式化方法被用于直接编码桥接不变量时，它们在此处极具价值：有效提现不得超过用户已结算权益；一条提现消息不得执行两次；总资产释放不得超过整个桥接系统中经过验证的支撑资产。
对于设计类似基础设施的协议而言，技术安全审查 应测试从充值到释放的完整生命周期，而不是将每个合约、服务或签名者域视为独立的安全边界。
为什么响应与遏制决策如此重要？
NEAR Intents 在 SHIELD 检测到异常活动后停止服务，在约一小时内修复合约侧漏洞，并暂停了 11 个受影响网络上的充值与提现，从而遏制了该事件。快速遏制可限制进一步提取，但全面恢复仍取决于资金追踪、法律升级处置，以及证明重启后的桥接流程满足修正后的安全不变量。
面对不确定性，立即停止服务是恰当的响应。当跨链提现路径可能正在产生无支撑释放时，继续正常运行可能使有限的漏洞利用演变为更大范围的金库耗尽事件。其代价是合法用户遭受严重服务中断，因此桥接暂停控制应具备细粒度、经过演练且可观察的特性。
NEAR Intents 表示，其已向执法部门报告事件，并正与安全及区块链分析合作伙伴合作追踪资金、寻求追回。公开报道指出，被盗资金被转入 KuCoin 并桥接至 Bitcoin。另有追踪发现，约 1.5M USDT 经由 CoW Protocol 结算合约流转。
一名 NEAR Intents 代表向攻击者提供了 48-hour 的资金返还窗口，在 Bitcoin、BNB Chain 和 Solana 上公布了返还地址，并未提供任何明确的 bounty。截至 10 月 2 日，尚无资金返还或还款计划的报道。
赔偿承诺同样重要。NEAR 联合创始人 Illia Polosukhin 表示，所有受影响用户都将获得全额赔偿。该承诺能够应对用户影响，但不能取代技术层面的要求：在恢复受影响路由之前，必须公布精确的事后分析和修复记录。
一套有效的事件后资料应包括：
- 确切的脆弱组件和 bug 类别。
- 消除漏洞利用路径的合约和基础设施变更。
- 是否有任何消息、nonce、账本、签名者或对账不变量失效。
- 针对修复措施的独立审查结果。
- 针对 BNB Chain、Polygon、TON、Optimism、Avalanche、Stellar、Monad、X Layer、ADI、Scroll 和 Plasma 的逐链恢复计划。
- 能更早识别相同异常提现模式的监控规则。
该事件还引发了超越代码层面的治理与运营问题。返还地址的发布、资金追踪、与交易所协调、用户赔偿及执法部门介入，均涉及法律与信息披露决策。准备桥接恢复程序的团队应使技术控制与法律及合规支持保持一致，尤其是在托管、用户索赔、制裁筛查或跨境追回变得相关时。
跨链团队应在 NEAR Intents 事件后做出哪些改变？
跨链团队应将每一次桥接提现视为价值守恒证明：资产释放必须绑定至已验证的锁定或扣账、唯一消息、特定目的地以及受限金额。NEAR Intents 事件表明，监控和紧急停止至关重要，但预防依赖于使无效的跨组件状态无法获得授权。
首要工程任务是以业务和技术术语定义桥接的核心不变量。对于 HOT Bridge 风格的系统，不变量不仅仅是“该 MPC 签名有效”。它更接近于：“这笔准确的提现仅被授权一次，针对该资产和接收方，并且是在相应的最终确定且未使用的充值或账本扣账之后。”
必须针对以下失效模式测试该不变量：
- 重复消息和 nonce 重用；
- 链标识符不匹配；
- token 地址或小数位转换不匹配；
- 过期的签名者批准；
- 部分基础设施中断；
- 账本余额与 locker 余额不一致；
- 紧急暂停状态转换；
- 升级或合约迁移后的重放尝试。
其次，协议应将检测与信任分离。SHIELD 在 NEAR Intents 事件期间检测到了异常活动，这有助于触发遏制措施。然而，监控不应成为记账错误与金库损失之间唯一的屏障。监控系统是在可疑行为开始后识别它；合约和桥接验证规则则应在转账可执行之前，拒绝无效的价值转移。
第三，团队应建立对账机制，对比源链锁定、结算账本 credit、目标链释放以及未完成的提现授权。出现差异时，系统应自动收紧限额或停止受影响路由。该控制对于热钱包和金库路径尤为重要，因为在缺乏该控制的情况下，一笔看似有效的交易可能迅速转移流动资产。
第四，形式化验证应聚焦于对桥接业务模型真正重要的属性，而不仅仅是算术安全性。若 NEAR Intents 的形式化验证承诺涵盖充值、Solver 结算、桥接消息创建与提现执行之间的状态转换，则其方向是正确的。若外部基础设施组件能够向某个合约 function 提供错误但被接受的前提，仅对该一个合约 function 进行形式化证明并不足够。
Soken 的研究中心研究了反复出现的智能合约和协议安全失效模式，包括本地合约检查与系统级安全保证之间的差异。对于桥接团队而言，实际教训是一致的：审计范围必须涵盖合约、消息格式、签名者策略、运营控制、监控遥测以及恢复流程。
NEAR Intents 现在需要将其承诺的事后分析转化为可验证的恢复计划：识别失效的交互环节，证明修复后的路径无法释放无支撑的 USDT，并独立测试每一条恢复运行的 HOT Bridge 路由。运营类似跨链基础设施的团队应首先将每一项提现授权映射至其底层锁定或扣账，然后测试这种关联是否能够经受重试、延迟、升级和对抗性消息排序。