本期收录 2026 年 9 月 21 日至 10 月 4 日发生的 8 起区块链安全事件估计损失合计约 $418.4M涉及 Ethereum、BNB Chain、Solana、Bitcoin、TRON、XRP Ledger、Zcash、Avalanche、NEAR 及相关网络。事件类型包括第三方安全产品漏洞、疑似证明系统 soundness flaw、区块与输入校验失败、网络配置核验不足、访问控制缺陷等。重点分析的两起事件中下游签名和执行都建立在错误的上游信息之上。资产系统需要在签名前和资金释放前进行独立校验。过去两周2026/09/21 - 2026/10/04共发生 8 起区块链安全事件估计损失合计约 $418.4M。图 1本期安全事件概览入选理由Bitget该事件占本期损失的绝大部分。攻击者从链下系统入手伪造提现指令最终形成有效链上转账过程中没有发生私钥泄露或智能合约漏洞利用NEAR Intents退款校验错误和状态回滚缺失把跨链充值解析失败转化为没有资产支持的内部余额并让该余额通过正常提现路径转出。Bitget9 月 24 日约 $387.5M 从 Bitget 的部分热钱包和温钱包基础设施转出涉及 Ethereum 及其他 EVM 网络、XRP Ledger、Zcash 和 TRON。链上交易带有有效的钱包签名。Bitget 表示攻击者利用第三方安全产品中的漏洞取得内网访问凭据并伪造提现指令私钥和冷钱包仍然安全。事件概述两份独立调查报告进一步解释了攻击路径但没有披露两款受影响安全产品的名称。Chen 发现攻击者取得两款安全设备的特权访问权限在 Product B 上部署 web shell 并建立 C2 连接随后横向移动至生产 wallet job server。调查人员恢复了一款定制提现工具该工具会伪造 risk-control 参数、构造提现请求并调用提现流程。攻击者如何在所有相关系统之间移动仍在调查中。公链记录的是最终签名转账而不是这些上游操作。链上记录显示18:31 UTC攻击者先收到 93 枚 TRX11 秒后又收到 0.84 枚 ETH。Bitget 最新时间线显示对账系统于 19:05 UTC 发现显著差异并在 19:14 UTC 启动最高级别应急响应。19:16 UTC攻击者控制的 TRON 地址另收到 20.59M 枚 TRXChen 称攻击者随后在另外 8 条网络上发起 17 笔大额转账合计约 $361M。Bitget 于 19:40 UTC 开始执行遏制措施并在 21:44 UTC 关闭钱包提现和签名服务。资金状态与生态响应截至 9 月 29 日 16:35:28 UTCBitget 官方持仓页面记录的攻击者当前持仓为 $322.67M已冻结资金约 $632,700仍可由发行方冻结的稳定币约 $312,500另有 $55.87M 处于跨链途中或仍在分析。地址浏览器采用另一套分类口径其中余额主要集中在 BTC$288.51M、ZEC$28.91M和 ETH$7.17M。Binance 共享情报并协助资金追踪Bybit 则更新 LazarusBounty 并提供帮助。基础设施服务方选择了不同做法。Bitget 要求 Bitget 拒绝向已公布的攻击者地址提供服务并表示去中心化不应成为协助已知被盗资金流通的挡箭牌。THORChain 拒绝选择性拉黑称其控制机制只能暂停更广范围的活动或某条链的路线不能只针对一个地址或一笔交易。NEAR Intents 表示SHIELD 在去除重复尝试后识别并阻断了超过 $50M 与攻击者相关的尝试流量。约 $503,000 在执行过程中被冻结约 $166,000 成功通过其中 $50M 指尝试流量并非冻结或追回金额。追踪页面后来将 NEAR Intents 处的 $293,507 归类为已冻结资金公开来源尚未解释两者差异。经验与启示攻击者通过第三方安全产品进入内部系统触达 wallet job server并将伪造提现请求转化为带有有效签名的链上交易。具备这类访问能力的第三方产品属于实际资产安全边界机构应隔离部署此类产品限制身份与权限持续监控其行为并在签名前独立验证提现意图追回权限分散在交易所、稳定币发行方、路由服务和基础协议之间任何单一参与方都无法独立完成处置。受影响机构需要尽快共享经核实的地址和交易数据基础设施服务方与安全团队则应在各自技术和治理约束下协同完成资金追踪、冻结、交易筛查和追回。NEAR Intents9 月 30 日至 10 月 1 日intents.near 中的退款校验错误和状态回滚缺失产生了没有对应资产支持的内部余额导致 NEAR Intents 损失约 $3.87M。攻击者利用该余额取得有效的 HOT MPC 提现签名并从协议位于 BNB Chain 的 vault 中提取真实 USDT。背景NEAR Intents 是部署在 NEAR 上的意图执行系统。其核心合约 intents.near 持有 omni-assets、记录用户内部余额并根据用户签署的 intent 处理资产交换和提现。在跨链充值过程中源链上的 vault 锁定真实资产。Omni 在 NEAR 上创建对应的 omni-asset 并转入 intents.near随后 intents.near 增加用户的内部余额。图 2NEAR Intents 跨链充值流程提现时intents.near 请求 Omni 销毁对应的 omni-asset 并创建提现记录。HOT MPC 验证该记录并生成签名目标链上的 vault 验证签名后释放真实资产。因此intents.near 记录的内部余额必须始终由合约实际持有的 omni-assets 提供支持。图 3NEAR Intents 跨链提现流程漏洞分析充值路径会在跨合约转账完全完成解析之前先增加接收方的内部余额。在解析过程中resolve_deposit_internal()使用接收方持有该代币的总余额限制 receiver 可控的 requested_refund却没有使用 deposited 限制退款deposited 表示本次正在解析的充值实际转入了多少也是本次操作允许退款的最大范围。总余额只能说明账户付得起多少不能说明其中有多少属于本次充值。缺少 deposited 这一上限后拥有大量历史余额的接收方就能请求远高于本次充值金额的退款。图 4退款逻辑使用接收方总余额限制 requested_refund对于包含多个长 token_id 的批量充值错误的退款数值会扩大序列化后的 MtBurnEvent。当该事件超过 NEAR 的日志总长度限制时check_refund().unwrap_or_panic_display().emit()路径会 panic导致 mt_resolve_deposit receipt 失败。图 5超长日志导致退款事件生成失败内部余额已在更早的 receipt 中记入。此次 panic 会回滚 callback receipt 尝试执行的余额与总供应量扣减却不会撤销此前已经提交的内部余额。Omni 随后把已转移资产返还给发送方攻击者因此保留了可提现的内部余额而 intents.near 不再持有匹配的 omni-assets。该漏洞由退款校验错误和异步 receipt 序列中的状态回滚缺失共同造成。攻击分析以下攻击过程还原基于公开信息分析。阶段一在 NEAR 上制造没有资产支持的内部余额Step 1攻击者通过 BNB Chain 上的 Omni/HOT vault 充值 10 枚 USDT使恶意接收方账户在 NEAR 上拥有非零 omni-asset 余额。Step 2攻击者调用 v2_1.omni.hot.tg 的 mt_batch_transfer_call()。在 mt_on_transfer()中intents.near 先通过 deposit()增加接收方余额再通知恶意接收方并把返回结果交给 mt_resolve_deposit()处理。Step 3恶意接收方返回远高于本次充值金额的 requested_refund。由于校验以接收方的代币总余额为上限该异常数值进入退款处理阶段。Step 4在这批条目中过大的退款数值使序列化后的 MtBurnEvent 超过 NEAR 的日志总长度限制。mt_resolve_deposit callback 发生 panic回滚了本次 callback 尝试执行的退款扣减但没有撤销更早 receipt 已经提交的内部余额。Omni 退回已转移资产而 intents.near 中的余额仍然可用。攻击者重复这一过程获得了可提现但没有资产支持的余额。阶段二从 BNB Chain vault 提取真实资产Step 59 月 30 日 18:57 和 20:05 UTC攻击者使用有效的 HOT MPC 授权先后从 BNB Chain vault 测试提现 10 枚和 11 枚 USDT。第一笔测试交易确认该 vault 会接受上游授权。图 6Phalcon 展示的首笔小额测试提现交易Step 6从 9 月 30 日 23:54 UTC 至 10 月 1 日 06:08 UTC攻击者发起 5 笔大额提现金额分别为 800,000 枚、1.2M 枚、1.5M 枚、330,000 枚和 35,000 枚 USDT合计从 vault 转出 3.865M 枚 USDT。结论NEAR Intents 事件的根本原因是退款校验错误和充值解析失败后的状态回滚缺失。攻击者通过超额退款请求让底层资产退回后内部余额仍然保留并利用这笔没有资产支持的余额发起提现。Omni 据此创建提现记录HOT MPC 对记录签名BNB Chain 上的 vault 验证签名后释放真实 USDT。退款处理应针对每种代币将退款金额限制在当前正在解析的充值金额以内。协议还应尽可能让余额增加与解析原子化无法原子化时必须在失败后执行可靠的补偿回滚。发出提现签名前系统应核对内部余额总量与实际 omni-asset 持仓发现不一致时立即暂停提现。事件生成也必须设置边界避免过大的日志使关键状态解析路径中止。