XRP Ledger 的一個溢位漏洞，原本可能讓單筆交易創造出超過現有總供應量的 XRP。Ripple 的開發部門 RippleX 與 XRPL Foundation 已揭露並修補此漏洞，該漏洞可能自 2015 年起即存在，並於 2026 年 9 月下旬完成修補。沒有任何證據顯示它曾被利用。

本可能被突破的供應量上限

XRP Ledger 是 XRP 背後的去中心化區塊鏈。它透過內建的訂單簿處理支付與交易，而支付引擎則是將支付與訂單簿上的報價進行撮合的元件。總供應量在發行時為 1,000 億枚 XRP。沒有挖礦、沒有通膨，只有銷毀的交易手續費會略微減少供應量。這個固定上限建立在帳本層級的不變量之上——即任何交易不得創造 XRP 的規則——而這正是此溢位漏洞所破壞的保證。

xrpld 伺服器軟體 3.4.1 版於 9 月 25 日發布，揭露報告則在 14 天後發布。在此之前，Default Unique Node List（UNL）上已有超過 80% 的驗證節點完成升級。此漏洞影響 xrpld 3.4.0 及所有更早的版本。回報此漏洞的 Veria Labs 計算，單筆攻擊交易原本可能創造出約 18 兆枚 XRP。

攻擊如何憑空鑄造 XRP

支付引擎會加總一筆支付在訂單簿中消耗的所有報價金額，使用的是沒有溢位檢查的 64 位元整數加法。如果總和累積到足夠大，數值就會回繞成一個小數字。每個報價擁有者都會收到全額支付，但帳本只向買方扣除回繞後的金額。差額就會以新 XRP 的形式憑空產生。

原本有兩道防護機制應該阻止這種情況。然而，規定任何交易不得創造 XRP 的不變量使用了同樣會溢位的算術運算。此外，每個戶的餘額檢查只在超過總供應量時才會觸發，而新創造的 XRP 卻會分散到許多帳戶中。

進行此攻擊時，攻擊者需要設置數百個帳戶，每個帳戶以極小的代幣份額報價換取巨額 XRP。單筆支付隨後消耗所有報價，而每個涉及的帳戶都可能屬於攻擊者。成本僅為數百枚 XRP 的可回收準備金加上手續費，因此攻擊者不需要龐大的初始餘額。

不過，沒有人能夠意外觸發此溢位。正常支付永遠不會達到所需的總和，因為沒有真實交易者會報出這樣的價格。報告也指出，沒有任何證據顯示在任何公共網路上發生過利用行為。Veria Labs 的 Cayden Liao 表示，此攻擊串連了兩個各自單獨評級都屬低嚴重性的漏洞，他懷疑這就是為什麼沒有人更早發現此缺陷。

透過漏洞賞金計畫回報

Cayden Liao 與 Veria AI 於 9 月 22 日透過網路的漏洞賞金計畫回報此漏洞，最初將其評為「Major」。RippleX 重現了該攻擊並將評級提高至「critical」，隨後私下開發修補程式。一天後，修補程式進入 3.4.1 版的發布分支，並隨候選版本 3.4.1-rc1 出貨。自那時起，支付引擎在加總報價金額時會檢查溢位；如果總和溢位，該部分支付即告失敗。

只有 Veria Labs 提供了關於發現過程本身的細節。該公司表示，一個 AI 代理程式發現了此漏洞並建構了可運作的攻擊。相比之下，揭露報告僅將 Liao 與 Veria AI 列為回報者。約 18 兆枚 XRP 的數字來自 Liao 的計算，相當於總供應量的 184 倍。Veria 也表示收到了 250,000 美元的最高賞金，不過報告並未提及金額。像這樣的計畫是各主要區塊鏈網路獎勵負責任揭露的標準機制。

根據報告，此漏洞很可能自 2015 年支付引擎開發時就存在於程式碼中，約十年未被察覺。此案例符合 AI 輔助漏洞挖掘的更大趨勢，這種方式能更快地發現缺陷——RippleX 開發人員也持相同觀點。

無需修正程序即生效的修補

XRP Ledger 上的規則變更通常需經過所謂的修正程序，需要在兩週期間內獲得超過 80% 可信驗證節點的支持。然而，此修補隨著每台伺服器個別升級而立即生效。報告稱這是修正程序機制問世以來，首次對交易處理進行的此類蓄意變更。發布當天，超過 % 的 Default UNL 驗證節點已在執行 3.4.1 或更新版本。

RippleX 以時間窗口為由解釋此做法：常規的開源發布會在修補生效前數週就向攻擊者暴露漏洞所在。因此，XRPL Foundation、RippleX 成員與 XRPL 驗證節點營運者事先同意，此風險證明採取快速做法是合理的。在他們看來，只有最嚴重的漏洞才值得採取此步驟，其他所有變更仍需經過修正程序。

「AI 改變了一切。你無法把關鍵漏洞修補悄悄塞進常規的公開發布流程，它會立刻被發現並被逆向工程。」—— Mayukha Vadari，RippleX

然而，團隊在二進位檔發布約兩週後，才在 GitHub 上公布 3.4.1 的原始碼。Cyber Capital 創辦人 Justin Bons 在 X 上批評，XRP 已在閉源程式碼上運行了兩週。延遲揭露的靜默修補是軟體安全領域的常見做法，但在一個具有治理企圖心的去中心化網路中，這仍然存在爭議。

批次功能中的第二個漏洞

3.4.1 版還修補了批次功能（XLS-56）中的第二個漏洞，該漏洞影響 xrpld 3.3.0 與 3.4.0。一個批次最多可容納八筆內部交易，依規範每筆都必須位於名為 RawTransaction 的欄位中。伺服器並未檢查這一點。因此，可能產生永久格式錯誤的帳本條目，進而干擾索引器、瀏覽器與 SDK。

共識層面的變體更為嚴重。在軟體版本混用的情況下，一筆精心構造的交易可能以一筆交易手續費的代價使驗證停擺，不過攻擊者在鏈上不會獲得任何利益。主網未受到影響，因為 BatchV1_1 並未在主網上啟用。

此發現最初出現在 Sherlock Attackathon 上，最初被評為「low」。9 月 18 日，XRPL Foundation 的 Denis Angell 確認先前的修補並不完整。四天後，Mayukha Vadari 識別出共識風險。隨後，Ripple 與驗證節點營運者 Vet 撤回了對 BatchV1_1 的投票，該修正程序原定於 9 月 29 日啟用。此次發布啟動了 fixBatchV1_2 為期兩週的啟用程序，且自 10 月 9 日起，兩項修正程序均已在主網上啟用。

強化的審查流程

因此，RippleX 正在改變其審查流程。從現在起，每個標記為已修復的安全發現都必須針對候選版本進行新的測試，只有在測試重現原始漏洞且候選版本通過測試後，團隊才會將其關閉。報告中列出的其他額外防護措施公開的 attackathon 與 AI 輔助的紅隊測試。

較舊的版本被視為「amendment-blocked」，無法再保持同步。因此，營運者需要將其伺服器升級至 xrpld 3.4.1 或更新版本。網路下次如何處理關鍵發現——是透過這條預留的快速通道還是常規修正程序——將決定這種做法是否仍如報告所描述的那樣屬於例外。

來源：XRPL 漏洞揭露報告，經由 Crypto Valley Journal