損失約4.18億美元：Bitget、NEAR Intents遭利用

在過去兩週（2026/09/21 - 2026/10/04）內，共發生 8 起區塊鏈安全事件，造成的估計總損失約為 4.184 億美元。

日期	事件	類型	估計損失
2026/09/23	Meter Passport	區塊驗證缺陷	~230萬美元
2026/09/24	Payy Network	疑似證明系統完整性缺陷	~190萬美元
2026/09/24	Limit Break	Calldata 驗證不當	~770萬美元
2026/09/24	Duelbits	根本原因未披露	~700萬美元
2026/09/24	Bitget	第三方安全產品漏洞	~3.875億美元
2026/09/27	DYORSwap	網路配置驗證不足	~210萬美元
2026/09/30	NEAR Intents	退款驗證不當及狀態回滾缺失	~390萬美元
2026/10/04	未具名 Base 金庫	存取控制不當	~600萬美元

選取理由

Bitget：該事件造成本期大部分損失，追蹤結果顯示是透過偽造的提款指令將鏈下系統入侵轉化為合法的鏈上轉帳，過程中並未發生私鑰或智能合約被攻破的情況。
NEAR Intents：退款驗證缺陷與狀態回滾缺失，使失敗的跨鏈存款解析結果轉變為未有資產擔保的內部餘額，而該餘額能夠通過正常的提款路徑。

Bitget

9月24日，Bitget 位於以太坊及其他 EVM 網路、XRP Ledger、Zcash 和 TRON 上的部分熱錢包及溫錢包基礎設施流出約 3.875 億美元資金。這些鏈上交易均帶有有效的錢包簽名。Bitget 表示，攻擊者利用了第三方安全產品中的一個漏洞，取得了內部網路存取憑證並偽造了提款指令，而私鑰和冷錢包仍保持安全[1][2]。

事件概述

獨立調查報告為攻擊路徑補充了更多細節,但未指明受影響的兩款安全產品名稱。SlowMist 將 A 產品上最早的惡意活動追蹤至 8 月 31 日，並確認其中一個節點上的某項服務存在零日漏洞。Mandiant 則發現攻擊者取得了兩個安全設備的特權存取權限，在 B 產品上發現了 Web Shell 及命令與控制(C2)連線，並藉此橫向移動至生產環境中的錢包作業伺服器。

SlowMist 另外發現，攻擊者使用內部員工身分存取了 B 產品的管理平台。調查人員還找到了一款經過定製的提款工具，該工具可偽造風控參數、構造提款請求並觸發提款流程。攻擊者在所有涉及系統之間如何移動，目前仍在調查中。公開鏈上記錄所反映的僅是最終經過簽名的轉帳，而非這些上游操作。

鏈上記錄顯示，首批資金移動發生於協調世界時(UTC)18:31，金額為 93 枚 TRX，11 秒後又轉出 0.84 枚 ETH。Bitget 目前公布的時間線顯示，其對帳系統在 UTC 19:05 偵測到異常,並於 UTC 19:14 啟動最高級別應急響應[1]。另一筆 2,059 萬枚 TRX 的轉帳於 UTC 19:16 到達攻擊者控制的 TRON 位址;Chen 稱另有 17 筆跨 8 個其他網路的較大額轉帳,總額約為 3.61 億美元[3]。遏制措施於 UTC 19:40 開始，錢包提款及簽名服務則於 UTC 21:44 關閉[1]。

資金狀態與社群回應

9月29日 UTC 16:35:28，Bitget 官方資金追蹤工具顯示，攻擊者目前持有的資金為 3.2267 億美元,已凍結約 632,700 美元,發行方可凍結的穩定幣為 312,500 美元,另有 5,587 萬美元正在轉移中或仍在分析中。其另一項地址檢視功能顯示，資金主要集中於 BTC(2.8851 億美元)、ZEC(2,891 萬美元)及 ETH(717 萬美元);該檢視所採用的分類範圍與總覽頁面不同。

Binance 分享了情報信息並協助追蹤資金，Bybit 則更新了 LazarusBounty 計畫並提供了協助[4][5]。各基礎設施服務商則做出了不同的選擇。Bitget 要求 THORChain 拒絕為已列明的攻擊者位址提供服務，並主張去中心化不應成為已知贓款流通的庇護[6]。THORChain 拒絕了這種針對性的黑名單做法，並表示其控制機制只能暫停更大範圍的活動或某條鏈路徑，而無法僅針對單一位址或交易進行限制[7]。

NEAR Intents 表示，在過濾重複項目後，其 SHIELD 系統識別並攔截了超過 5,000 萬美元的疑似與攻擊者相關的資金流動嘗試。執行過程中約凍結了 503,000 美元,另有約 166,000 美元已完成流通;該 5,000 萬美元數字為嘗試流動的金額,並非已凍結或已收回的資金。[8]。追蹤工具後續將 NEAR Intents 上凍結的 293,507 美元列入統計，但公開資料來源尚未就該差額做出說明。

經驗教訓

攻擊者透過第三方安全產品侵入系統，進而觸及錢包作業伺服器，並將偽造的提款請求轉化為有效簽名的交易。任何具備此類觸及範圍的第三方產品，都應被納入實際的資產安全邊界之內：機構應對其進行隔離，限制相關身分及權限，監控其行為，並在簽名前獨立核實提款意圖。
恢復權限分散在交易所、穩定幣發行方、路由服務及底層協議之間，因此沒有任何單一參與方能夠獨自主導應對工作。受影響機構需要快速分享已核實的位址和交易資料，同時基礎設施服務商及安全團隊應在各自的技術與治理限制範圍內，協調追蹤、凍結、交易篩查及資金恢復等工作。
關於由本次事件衍生出的預防性控制措施，詳見Bitget 的 3.875 億美元鏈下攻擊事件：超越私鑰與合約層面一文，該文針對特權存取、提款意圖、資產流動監控及應急響應，建構了一套深度防禦框架。

NEAR Intents

在9月30日至10月1日期間，NEAR Intents 因 intents.near 中的一項退款驗證缺陷及狀態回滾缺失，導致系統產生了一筆沒有對應資產擔保的內部餘額，進而造成約 387 萬美元的損失。攻擊者利用該筆餘額取得了有效的 HOT MPC 提款簽名，並從該協議位於 BNB Chain 的金庫中釋放出真實的 USDT[9][10]。

背景

NEAR Intents 是 NEAR 上的一個意圖執行系統。其核心合約 intents.near 持有全鏈資產(omni-asset)，記錄使用者的內部餘額，並根據已簽名的意圖處理資產兌換及提款操作。

對於跨鏈存款，源鏈上的金庫會鎖定真實資產。Omni 隨後在 NEAR 上建立對應的全鏈資產，並將其轉入 intents.near，由該合約為使用者的內部餘額進行入帳。

對於提款，intents.near 會要求 Omni 銷毀對應的全鏈資產並建立提款記錄。HOT MPC 驗證該記錄後發出簽名。目標鏈上的金庫會在釋放真實資產前驗證該簽名。此流程要求 intents.near 所記錄的內部餘額，必須始終與該合約實際持有的全鏈資產保持對應關係。

漏洞分析

存款流程在跨合約轉帳完全解析完成之前，就先為接收方的內部餘額進行了入帳。在解析過程中，resolve_deposit_internal() 函數以接收方在該代幣下的總餘額作為上限，來限制由接收方控制的 requested_refund 參數值，但卻未以 deposited(即本次正在解析的存款交易中實際轉入的金額)作為第二重限制。總餘額僅能反映帳戶可支付的金額，而 deposited 才決定了本次轉帳允許退還的金額上限。若缺少這第二重限制，持有大額既有餘額的接收方便可申請遠高於當前存款金額的退款[10]。

對於包含大量長代幣 ID 的批量存款交易，錯誤的退款數值會導致序列化後的 MtBurnEvent 體積增大。當該事件超出 NEAR 的日誌總長度限制時，check_refund().unwrap_or_panic_display().emit() 路徑便會觸發恐慌(panic)，進而導致 mt_resolve_deposit 收據(receipt)執行失敗。

該內部餘額的入帳操作已在更早的一筆收據中完成。恐慌發生後，雖然回滾了回呼收據(callback receipt)中嘗試執行的餘額及供應量扣除操作，但並未撤銷此前那筆已完成的入帳。隨後，Omni 將已轉入的資產退回給發送方，使攻擊者手中留有一筆可提款的內部餘額，而這筆餘額已不再與 intents.near 實際持有的全鏈資產相匹配。該漏洞結合了退款驗證缺陷以及在非同步收據序列中狀態回滾缺失的問題。

攻擊分析

以下重建過程基於公開可得的資訊[11]。

第一階段：在 NEAR 上建立無資產擔保的內部餘額

步驟 1：攻擊者透過 BNB Chain 上的 Omni/HOT 金庫存入 10 枚 USDT，使惡意接收方帳戶在 NEAR 上獲得一筆非零的全鏈資產餘額。
步驟 2：攻擊者在 v2_1.omni.hot.tg 上呼叫了 mt_batch_transfer_call() 函數。在 mt_on_transfer() 中，intents.near 首先透過 deposit() 為接收方進行入帳，隨後通知該惡意接收方，並將其回應傳遞給 mt_resolve_deposit()。
步驟 3：惡意接收方回傳了一個遠高於當前存款金額的 requested_refund 值。由於驗證機制以接收方的代幣總餘額作為上限，該異常數值因而被允許進入後續的退款處理流程。
步驟 4：在批量交易的多個項目中，過大的退款數值使序列化後的 MtBurnEvent 超出了 NEAR 的日誌總長度限制。mt_resolve_deposit 回呼函數因此觸發恐慌，雖然回滾了其嘗試執行的退款扣除操作，但並未撤銷早先那筆收據中已完成的內部入帳。Omni 將已轉入的資產退回，而該筆已入帳的餘額仍留存在 intents.near 中可供使用。重複執行此流程，便能持續建立攻擊者可提取的無資產擔保餘額。

第二階段：從 BNB Chain 金庫提取真實資產

步驟 5：9月30日 UTC 18:57 及 20:05，攻擊者使用有效的 HOT MPC 授權，對 BNB Chain 金庫進行了 10 枚 USDT 及 11 枚 USDT 的提款測試。首筆測試交易確認該金庫接受了上游的授權。

步驟 6：從9月30日 UTC 23:54 到10月1日 UTC 06:08 期間，攻擊者進行了五次較大額的提款，金額分別為 800,000 枚 USDT、120 萬枚 USDT、150 萬枚 USDT、330,000 枚 USDT 及 35,000 枚 USDT。這些交易從金庫中共計釋出了 386.5 萬枚 USDT。

結論

NEAR Intents 遭利用的原因，是退款驗證邏輯不正確，以及在存款解析失敗後缺少狀態回滾機制。攻擊者利用超額的退款請求，在底層資產已被退回後仍保留了內部信用額度，隨後再利用這筆無資產擔保的餘額申請提款。Omni 建立了對應的提款記錄，HOT MPC 對其進行了簽名，而 BNB Chain 金庫則釋放出了真實的 USDT。

退款處理流程應以本次正在解析的存款交易中實際存入的金額，作為每種代幣退款額度的上限。協議還應盡可能使餘額入帳與解析過程具備原子性，或在失敗後採取有保障的補償性回滾機制。在發出提款簽名之前，系統應核對內部餘額總額與實際持有的全鏈資產是否一致，並在發現不匹配時暫停提款功能。此外，事件生成機制也必須設有合理的邊界限制，以避免過大的日誌內容導致狀態關鍵的解析流程中斷。