XRP Ledger 開發者揭露了一個重大漏洞，攻擊者原本可能藉此憑空創造可花費的 XRP，繞過旨在防止該加密貨幣供給量增加的保護機制。

該漏洞存在於帳本的支付引擎中，由 Cayden Liao 與 Veria AI 於 9 月 22 日透過 XRPL 漏洞賞金計畫回報。RippleX 工程師在獨立伺服器上重現了該攻擊，確認新創造出的 XRP 可在後續支付中被花費，並將其嚴重程度從重大上調至關鍵。此處理方式遵循標準的協調揭露慣例：賞金回報會私下送達維護者，完整技術細節僅在修補版本發布後才會公開。

根據發布於 XRPL 官方部落格的揭露報告，沒有證據顯示該漏洞曾在任何公開的 XRP Ledger 網路上被利用。開發者私下準備了修補方案，並於 9 月 25 日發布 xrpld 3.4.1 版本，也就是修補程式合併至緊急發布分支的兩天後。

整數溢位可能繞過 XRP 供給檢查

該漏洞自 2015 年前後即存在於 XRP Ledger 的支付引擎中，涉及當一筆支付消耗訂單簿中多個報價時未經檢查的 64 位元整數運算。

64 位元數值的上限約為 18.4 quintillion，而這類固定位元寬度運算中的溢位是帳本軟體中眾所周知的缺陷類型——2010 年，Bitcoin 價值檢查中的一個整數溢位曾短暫創造出約 1,840 億 BTC，開發者在數小時內便完成修補。

攻擊者可以建立數百個帳戶，並放置特殊構造的報價，以極大數量的 XRP 出售少量其他代幣。一筆消耗這些報價的支付可能使計算總額超出整數所能支援的最大值。交易不會被拒絕，總額反而會回繞為一個小數字。每個報價擁有者仍能收到其報價中指定的全部 XRP 金額，而買方僅會被收取回繞後小得多的金額。

此攻擊僅需數百枚 XRP 作為帳戶與報價準備金（其中大部分事後可回收），以及一般的交易手續費。

XRPL 內建旨在確保交易無法創造 XRP 的檢查機制原本無法阻止此攻擊。該不變量使用了相同類型的運算，會以同樣方式溢位，而另一個單一帳戶餘額上限則可透過將新創造的 XRP 分散到數百個帳戶來過。此缺陷之所以關鍵，在於 XRP 供給機制的運作方式：全部 1,000 億枚代幣均在帳本啟動時創造，交易手續費銷毀 XRP 而非鑄造新幣，而不變量檢查正是確保任何支付路徑都無法推高總量的保證。該漏洞僅限於刻意構造的交易，無法由一般支付或交易活動觸發。

驗證節點在數小時內升級至 3.4.1

開發者選擇立即部署 XRP 溢位修補，而非走 XRPL 一般的修正案流程，後者通常需要超過 80% 的驗證節點支持並持續兩週，協議變更才會生效。若讓該漏洞在此期間持續暴露，將形成攻擊手法已公開但仍可被利用的空窗期。

在預設的唯一節點清單（Unique Node List）中，超過 80% 的驗證節點已於 9 月 25 日升級至 3.4.1，與緊急版本發布同一天。從私下回報到多數驗證節點採用僅歷時三天，展現了帳本緊急發布機制的完整運作。

3.4.1 版本現在會在報價總額可能溢位時拒絕支付，並為 XRP 創造不變量使用更寬的計數器。其他餘額計算也已針對類似運算錯誤進行強化。

此事件之前，2025 年還發現過一次無關的 xrpl.js 供應鏈入侵事件，其影響的是惡意的 JavaScript 套件發布，而非 XRP Ledger 協議本身。XRPL 的修正案系統也被用於較新的功能，例如提議中的 XRPL Lending Protocol，驗證節點的批准決定新的交易行為是否生效。

此溢位漏洞並未改變 XRP 的現有供給。未發現任何未經授權的 XRP，且伺服器營運者現在必須執行 xrpld 3.4.1 或更新版本，才能與網路保持同步。目前可觀察到的是營運層面的動態：仍在使用舊版本的節點陸續遷移至 3.4.1 或更新版本，而 XRPL Lending Protocol 等提案則繼續走這次修補所繞過的標準修正案流程。

來源：XRP Ledger Patches Decade-Old Flaw That Could Create Spendable XRP — Crypto Adventure