Harmony 跨鏈 ONE 鑄幣事件 + 約4700萬美元金鑰洩露損失

在過去一週(2026/08/10 - 2026/08/16),以下 5 起重大安全事件值得關注,總損失約為 4700 萬美元。

日期	事件	類型	估計損失
2026/08/10	Coinsbuy	私鑰被盜	~$7.9M
2026/08/10	未知巨鯨錢包	私鑰被盜	~$25M
2026/08/12	Harmony	驗證問題	未知*
2026/08/13	Kite	私鑰被盜	~$14M
2026/08/15	Fox	業務邏輯缺陷	~$117K

*Harmony 報告了第一波確認鑄造的 40 億 ONE,並就更廣泛範圍進行重建,發現約有 3.01 萬億 ONE 被偽造,其中約 2.385 萬億 ONE 已被轉移 [1]。以事件發生前的價格約 $0.001183 計算,被偽造的數量名義價值約為 35.6 億美元,但這大約是 ONE 總供應量的 200 倍,遠遠超過該代幣的市值,因此既無法實現,也未被確認為已實現損失。Harmony 隨後已將鏈回滾至攻擊發生前的檢查點,捨棄被偽造的狀態 [2]。因此 Harmony 不計入總損失。

入選原因

Harmony:入選原因是鏈實現層面的重放保護缺陷,使攻擊者能夠在整個 Harmony 生態系統中進行大規模未授權原生代幣發行。在調查過程中還發現了一個獨立的預抵押(pre-staking)法定人數驗證弱點,但其在此次攻擊中所起的作用尚未得到確認。

本週焦點:Harmony

本週聚焦於 Harmony,因為此缺陷存在於鏈實現本身,而非應用層合約,這是一種影響格外嚴重的故障模式,因為它可能導致整個第一層區塊鏈基礎資產的通貨膨脹。

2026 年 8 月 12 日,分片式第一層區塊鏈 Harmony 因跨分片收據重放缺陷,遭受其原生代幣 ONE 的未授權鑄造。目標分片使用未被來源委員會簽名覆蓋的欄位來識別已消耗的收據,因此攻擊者只需修改這些欄位,就能重新提交一份真實的、先前已入帳的收據,使其再次被入帳,而來源分片卻沒有相應的扣款。Harmony 正在對第一波確認鑄造的 40 億 ONE,與更廣泛範圍重建出的約 3.01 萬億 ONE 偽造量,以及由偽造鑄造錢包轉出的約 2.385 萬億 ONE 進行核對;這些數字均未被確認為已實現損失,最終影響仍取決於回滾及交易所核對結果 [1][2]。在調查過程中,Harmony 另外發現了一個獨立的預抵押法定人數驗證缺陷,但尚未確認此次攻擊是否利用了該缺陷。

背景

Harmony 是一個分片式第一層區塊鏈。每個分片維護自己獨立的狀態,因此來源分片無法直接修改目標分片上的帳戶。為了在分片間轉移價值,Harmony 採用了一種基於收據的非同步設計:來源分片扣除發送者款項並生成一份跨分片收據,目標分片隨後為接收者入帳。

跨分片收據記錄了轉帳本身:

type CXReceipt struct {
    TxHash    common.Hash
    From      common.Address
    To        *common.Address
    ShardID   uint32
    ToShardID uint32
    Amount    *big.Int
}

目標分片不會信任一份未經驗證的收據。收據被包含在 CXReceiptsProof 中,其中攜帶了一個 Merkle 證明、來源區塊標頭,以及來源委員會對該標頭的提交簽名:

type CXMerkleProof struct {
    BlockNum      *big.Int
    BlockHash     common.Hash
    ShardID       uint32
    CXReceiptHash common.Hash
    ShardIDs      []uint32
    CXShardHashes []common.Hash
}

type CXReceiptsProof struct {
    Receipts     CXReceipts
    MerkleProof  *CXMerkleProof
    Header       *block.Header
    CommitSig    []byte
    CommitBitmap []byte
}

正常的驗證路徑會根據已簽名的來源標頭及其委員會簽名來驗證證明:

VerifyIncomingReceipts()
  -> IsSpent()
  -> ValidateCXReceiptsProof()
      -> VerifyHeaderSignature()
          -> verifySignature()
              -> DecodeSigBitmap()
              -> IsQuorumAchievedByMask()
              -> aggSig.VerifyHash()

由於來源分片只會執行一次扣款,目標分片必須確保每份跨分片收據只被消耗一次。

漏洞分析

跨分片結算路徑存在兩個問題:一是識別已消耗收據方式中的重放保護弱點,二是預抵押法定人數驗證弱點。

跨分片收據重放

重放保護會記錄並查詢某份收據的"已消耗"標記,但其鍵值來自 Merkle 證明中兩個可變欄位:

CXMerkleProof.ShardID
CXMerkleProof.BlockNum

Bloom 硬分叉在主網第 2964 個 epoch(2026 年 7 月 13 日)加強了這一機制,由 IsCXMerkleProofReplayFixEpoch 進行控制 [3]:對於已簽名的 Header.Epoch() 等於或晚於該 epoch 的證明,IsSpent() 和 WriteCXReceiptsProofSpent() 會從已簽名的來源標頭(Header.ShardID 和 Header.Number)派生已消耗標記的鍵值,而非使用前述兩個欄位。然而,這種更強的鍵值機制從未追溯應用——對於 Header.Epoch() 早於此次分叉的證明,這兩個函式仍保留舊有的退回機制,使用 MerkleProof.ShardID 和 MerkleProof.BlockNum,而 ValidateCXReceiptsProof() 在這些 epoch 中從未將它們與已簽名標頭進行綁定。

這兩個欄位位於提交簽名覆蓋範圍之外,該簽名僅覆蓋來源 Header。修改 Header 會導致 VerifyHeaderSignature() 驗證失敗,但修改 MerkleProof.ShardID 或 MerkleProof.BlockNum 卻不會觸發任何檢查——既不會影響標頭簽名驗證,也不會影響證明驗證,因為在這些 epoch 中,證明驗證從未將它們與 Header 綁定。由於舊有的已消耗標記鍵值是由這些未經驗證的欄位派生而來,收據的重放保護身份便與驗證其餘證明內容的簽名脫鉤:兩份攜帶相同已簽名標頭和收據、但 MerkleProof.ShardID 或 MerkleProof.BlockNum 值不同的證明,在已消耗追蹤機制中被視為互不相同。

預抵押法定人數檢查

第二個缺陷影響了預抵押法定人數驗證。uniformVerifier.IsQuorumAchievedByMask() 邏輯將門檻值與

len(mask.Publics)

進行比較,並將其視為簽署者的數量。但 mask.Publics 實際上是某個分片和 epoch 的完整委員會公鑰列表,而非實際簽署的驗證者集合;後者是由簽署者位圖(bitmap)表示的。因此,即使簽署者位圖為空,也可能仍達到法定人數門檻,因為該檢查衡量的是委員會規模,而非位圖中被啟用的位元數量。結合一個單位(全零)聚合 BLS 簽名,這可能使一個預抵押時代的來源標頭看似擁有足夠的法定人數。

攻擊分析

攻擊者以一份真實的、來自硬分叉之前來源分片區塊的已處理跨分片收據為起點,僅修改其未經驗證的證明身份欄位,便將其重放。偽造的 ONE 被鑄造到四個攻擊者錢包中。以下分析基於交易 0xf3d4e8b1...8242c7f 和 0x9a756ef9...b0a4d678。

步驟 1:攻擊者從硬分叉之前的來源分片區塊中,獲取了一份有效的歷史 CXReceiptsProof。該證明包含有效的收據、有效的來源區塊標頭,以及有效的來源委員會提交簽名。
步驟 2:目標分片已經消耗過此收據一次,並寫入了其已消耗標記,該標記以 Merkle 證明欄位為鍵值。
步驟 3:攻擊者僅修改了未經驗證的證明身份欄位,而已簽名的標頭以及所有簽名覆蓋的欄位均保持不變:
```
MerkleProof.ShardID
MerkleProof.BlockNum
```
步驟 4:被修改後的證明在稍晚的目標分片區塊中,作為入帳收據提交。IsSpent() 根據被修改後的欄位派生已消耗標記的鍵值,未能找到先前的標記,因此該收據看起來像是尚未被消耗。
步驟 5:ValidateCXReceiptsProof() 仍接受此證明,因為被修改的身份欄位未被簽名覆蓋,而所有經驗證的欄位均保持不變:標頭雜湊值和出帳收據雜湊值、Merkle 證明區塊雜湊值和收據雜湊值、收據雜湊值,以及提交簽名和位圖。
步驟 6:ApplyIncomingReceipt() 在目標分片上執行,並透過 db.AddBalance(*cx.To, cx.Amount) 再次為接收者入帳。由於原始跨分片交易已經執行過一次,來源分片並未發生相應的扣款,導致目標分片上的原生 ONE 出現通貨膨脹。