XRPL／官方：支付引擎整數溢位可鑄無限 XRP——緊急釋出 3.4.1 跳過修訂投票；十月九日披露並啟用 fixBatchV1_2

Key takeaway

XRP Ledger（XRPL）官方於二零二六年十月九日發布漏洞披露報告，交代參考實作 xrpld 3.4.1 緊急修補一項可導致「憑空鑄造」可花費 XRP 的支付引擎整數溢位；同日 fixBatchV1_2 修訂亦於主網啟用。來源真實性已驗證自 xrpl.org 官方披露與 3.4.1 發布說明，並以 Cointelegraph、The Block 等專業媒體就「跳過常規修訂投票」的後續辯護報道交叉核對。報告指漏洞可追溯至約二零一五年支付引擎寫法，經漏洞賞金計劃於九月二十二日呈報；九月二十五日釋出修補後，當日逾八成預設 UNL 驗證者已升級；官方稱未發現任何公網遭利用證據。

XRPL／官方：支付引擎整數溢位可鑄無限 XRP——緊急釋出 3.4.1 跳過修訂投票；十月九日披露並啟用 fixBatchV1_2

XRP Ledger（XRPL）官方於二零二六年十月九日發布漏洞披露報告，交代參考實作 xrpld 3.4.1 緊急修補一項可導致「憑空鑄造」可花費 XRP 的支付引擎整數溢位；同日 fixBatchV1_2 修訂亦於主網啟用。來源真實性已驗證自 xrpl.org 官方披露與 3.4.1 發布說明，並以 Cointelegraph、The Block 等專業媒體就「跳過常規修訂投票」的後續辯護報道交叉核對。報告指漏洞可追溯至約二零一五年支付引擎寫法，經漏洞賞金計劃於九月二十二日呈報；九月二十五日釋出修補後，當日逾八成預設 UNL 驗證者已升級；官方稱未發現任何公網遭利用證據。

本文整理溢位攻擊路徑、為何首次刻意繞過逾十年修訂機制、Batch 包裝驗證第二漏洞，以及香港與亞洲節點／交易所營運者應立刻核對的版本與治理啟示。

XRPL／官方：支付引擎整數溢位可鑄無限 XRP——緊急釋出 3.4.1 跳過修訂投票；十月九日披露並啟用 fixBatchV1_2

一、核心事件：十年隱患變成「可鑄幣」臨界漏洞

技術細節

根據 XRPL 官方《Vulnerability Disclosure Report for xrpld 3.4.1》，研究人員透過 XRPL Bug Bounty 呈報：支付引擎在加總「單筆付款同時吃掉大量掛單」的金額時，使用未檢查溢位的六十四位整數加法。XRP 餘額以有固定上限的整數儲存；當加總超過上限，數值會「繞回」成極小數，而不是失敗退出。引擎仍向每名掛單方逐筆記入完整 XRP，卻只向買方收取繞回後的微小總額，差額即為不應存在、卻可立即花費的新 XRP。

披露指出，攻擊者無需龐大起始餘額：可用數百個帳戶各自掛出「極少量代幣換極大量 XRP」的刻意掛單，再以一筆付款一次吃掉；成本主要是帳戶與掛單保證金（物件刪除後可退回）及一般手續費。官方強調此路徑無法被普通交易「無意觸發」——掛單定價須極端到遠低於真實流動性，路徑尋找與正常付款在實測中不會走到溢位點。

更棘手的是既有防禦失效：「不得創造 XRP」的不變量檢查，用同樣六十四位加總方式計算淨變化，溢位後看起來只像付了手續費；單帳戶餘額上限檢查亦可被「把新鑄 XRP 分散到數百帳戶」繞過。RippleX 在獨立節點與單元測試重現鑄造，並確認鑄出的 XRP 可在後續付款中花費，遂將嚴重度由 Major 升為 critical。

二、技術原理深度解析

XRP 總供應在協議層有固定設計；支付引擎卻在「跨多筆掛單加總應付額」這條熱路徑上，把「單一掛單金額合法」誤當成「加總後仍安全」。這是典型的整數溢位／繞回（wrap-around）與「不變量與業務邏輯共用同一缺陷算術」的組合失敗。

修補策略分兩層：自 xrpld 3.4.1 起，支付引擎在跨掛單加總與多路徑合併結果時檢查溢位；若會溢位，該段付款乾淨失敗，結果呈現為正常的 path dry 或部分付款，不會鑄幣。同時「不得創造 XRP」檢查改用更寬、不會以同樣方式繞回的計數器，並對其他跨帳戶加總路徑做防禦性硬化。

同一版本還處理第二個問題：Batch（XLS-56）內部交易包裝欄位驗證缺口（fixBatchV1_2）。規格要求內部交易必須包在 RawTransaction；舊邏輯只要是「已知物件型欄位」即可，不同版本對欄位集合不一致時，可能造成共識分歧甚至驗證停滯。該修訂於二零二六年十月九日與相關 Batch 路徑一併在主網啟用；官方指 BatchV1_1 在發現時尚未於主網啟用，故無主網資金損失。披露亦說明團隊曾先撤回 BatchV1_1 投票以重置啟用時鐘，待修復修訂取得多數支持後再恢復，避免「帶已知缺陷上線再事後補丁」。

三、代幣經濟學／協議層影響

XRP 的固定供應敘事是市場定價與合規論述的核心假設之一。若溢位鑄幣在公網被成功利用，新鑄可花費 XRP 可進入普通帳戶、交易與交易所入金，損害極難逆轉。官方稱截至披露時未發現公網利用證據，且攻擊需刻意構造、成本相對低但路徑極端。

協議治理層面同樣敏感：官方承認這是修訂機制引入逾十年來，首次刻意讓「交易處理規則變更」在節點升級當下立即生效，而不是先公開修補、經逾八成信任驗證者連續兩週投票後才齊步切換。理由是：開源釋出修補等於公開漏洞位置；若走常規修訂，修補會在仍可被利用的狀態下公開數週。代價是升級窗口內不同版本規則可能短暫不一致——官方判斷「短暫升級風險」遠低於「公開可利用鑄幣窗口」，且正常交易不會走到該路徑；若有人嘗試利用，未升級節點可能失步，最壞甚至共識停滯，但仍優於寫入錯誤帳本狀態。

Cointelegraph 於十月十二日報道，XRPL 開發者與基金會反駁「緊急二進位釋出等於中央化」的批評：強調決定由基金會、RippleX、核心開發與驗證者共同評估嚴重性；3.4.1 最終仍須經常規修訂投票、逾八成支持兩週才成為網絡要求；獨立驗證者營運方亦指「協調升級≠放棄獨立性」。這場辯論直接觸及 XRPL「充分去中心化、公鏈」定性——該定性長期與證券屬性爭議綁在一起，故市場與合規讀者應分開看待「安全應急」與「日常規則變更」兩套門檻。

四、日常應用場景

1. 開發者與技術團隊

運行 xrpld 的團隊須確認版本為 3.4.1 或更新；fixBatchV1_2 啟用後，舊版伺服器會被 amendment block、無法與網絡同步。支付與交易介面應把極端加總下的 path dry／部分付款視為預期失敗，而不是盲目重試繞過。解析 Batch 交易的索引器與 SDK，應假設僅接受 RawTransaction 包裝。

2. 企業與隱私敏感行業

交易所、託管、做市與支付通道應核對入金／出金節點軟體版本與 UNL 健康度，並把「供應不變量」納入鏈上監控（異常大量小額帳戶同向入帳、異常掛單密度等）。漏洞賞金與負責任披露流程，說明公開鏈核心軟體仍須持續紅隊與形式化之外的賞金激勵。

3. 一般用戶

一般持幣用戶無法靠日常轉帳「誤觸」此漏洞；官方亦稱未見公網利用。用戶應留意的是：緊急升級期可能伴隨節點軟體版本分化與短暫服務中斷風險，選擇基礎設施時宜優先已完成升級、有公開狀態頁的服務商。

4. 香港與亞洲市場視角

香港是亞洲虛擬資產交易與托管活躍市場之一，多家平台與專案與 XRPL／跨鏈橋接生態有直接或間接曝險。本地營運者應把本次事件納入節點變更管理與事件通報演練：誰有權決定「跳過常規治理窗口」的緊急升級、如何對客戶說明供應完整性，以及如何與審計／合規同步披露口徑。亞洲驗證者與託管商若仍停留在 3.4.0 或更早，已不僅是「建議升級」，而是同步性硬性要求。

五、專業評價與潛在考量

優勢

  • 賞金計劃成功挖出約十年隱患，並在披露前完成主網防護與修訂啟用，屬負責任披露的正面案例。
  • 修補同時硬化不變量計數器，降低「同一算術缺陷再次 concurrent fail」的機率。
  • 官方公開完整時間線、根因與為何跳過修訂，有助業界評估去中心化與安全應急的權衡。

需要留意的地方

  • 「首次跳過修訂」會成為往後每次緊急釋出的先例參照；社群對透明度（例如曾暫緩公開源碼）與協調壓力仍有爭議。
  • 升級窗口的混合版本風險雖被評估為可接受，但對運維不成熟的小型營運者仍是實務挑戰。
  • 未發現公網利用≠可假設歷史上從未被私有探測；監控與事後鏈上分析仍值得持續。

結語

XRPL 本次支付引擎溢位事件，把「固定供應」從行銷口號打回工程現實：不變量必須用不會與業務邏輯一起繞回的算術來守護；而公鏈治理在「極端可鑄幣」面前，也可能選擇以協調升級換取縮短公開利用窗口。對香港與亞洲的鏈上基礎設施團隊而言，當務之急是核對 xrpld ≥ 3.4.1、理解 fixBatchV1_2 已啟用的同步含義，並把緊急升級決策寫進可審計的營運程序。

若企業需要在香港落地錢包、節點、跨鏈或合規導向的鏈上產品，可參考 YSK Limited 的 Web3 區塊鏈開發服務（https://ysk.hk/services/web3-blockchain）。瀏覽器端鏈上市場與持倉工具亦可了解開源 YSK Mint v1.4.14（https://mint.ysk.hk/；自行簽名、非託管、合約未經審計，並非投資建議）。主機與節點營運若需單機 Linux 控制平面，可一併評估 YSK Server v1.1.28（https://ysk.hk/products/ysk-server，預設埠 9287）。

參考來源

Related services & products

Related posts