XRP Ledger 支付引擎爆出藏著一個自 2015 年就存在的整數溢位漏洞，攻擊者只需數百枚 XRP 的成本，就能一次印出遠超 1,000 億枚上限的新幣。RippleX 緊急修補，並稱未發現任何公開網路遭利用的跡象。
（前情提要：XRP Ledger 上線「權限委派」功能！銀行可分權管理，穩定幣合規再近一步）
（背景補充：Zano 駭客印出 1,800 兆枚假穩定幣！鏈上無法辨別，團隊回滾一個月）
一個在 XRP Ledger 支付引擎裡躺了約十年的算術漏洞，差點讓 XRP 的 1,000 億枚總量上限失守！XRPL 官方在 10 月 9 日公布的漏洞揭露報告指出，這個缺陷從 2015 年現行支付引擎寫成時就存在，直到今年 9 月 22 日才有人通報。
但是先講結論：漏洞已經補上，官方確認未發現任何公開網路遭利用的跡象。不過這次修補做了一件前所未有的事，刻意跳過修正案流程，是修正案制度推出十多年來的頭一遭。
三天補洞：評級從 Major 一路升到 critical
故事從 9 月 22 日開始。Cayden Liao 與 Veria AI 走漏洞賞金管道遞交通報，原評為 Major。RippleX 當天在本機獨立伺服器上實測，再用單元測試驗證，發現印出的 XRP 果真能拿去付款，立刻把等級從 Major 拉高到最高的 critical。
修補程式碼在 9 月 22 日至 23 日私下開發、經多輪審查，9 月 25 日隨 xrpld 3.4.1 發布。版本說明寫道，這是修補資安敏感問題的緊急版本。
最關鍵的是速度：發布當天，預設 UNL 上超過 80% 的驗證者已升級，儘管當時看不到修補的原始碼。10 月 9 日的報告才寫明，原始碼現已公開。
收銀機加總爆表，差額就是憑空多出的 XRP
漏洞本身怎麼運作？把支付引擎想成收銀機就好懂了。當一筆支付從訂單簿一次吃下很多筆掛單，引擎要加總買方的應付金額；官方指出，這段加總用的是一般 64 位元整數，沒做溢位檢查。總和一旦超過上限，不會報錯，而是像收銀機數字爆表歸零，變成一個很小的數字。
後果是每位掛單者照樣收到全額 XRP，買方卻只被扣掉幾百 drops 外加手續費。差額就是帳本上本不該存在的 XRP，還能在後續支付中照常花用。
攻擊者只需開出數百個帳戶，各掛一筆用極少量某種代幣換極大量 XRP 的掛單，再由另一個帳戶送出一筆支付吃光它們。官方強調，天文數字是掛單者收到的金額，不是攻擊者的本金；成本只有幾百枚 XRP 的帳戶與掛單儲備金（可退回），加上一般手續費。
兩道防線一起失靈，漏洞潛伏十年
XRP Ledger 原本有兩道保險。第一道是確認交易沒有創造 XRP 的不變量檢查，但它加總淨變動用的是同一種 64 位元計數器，一樣歸零，淨變動看起來只剩手續費。
第二道是單一帳戶餘額檢查，只在某個帳戶持有量超過 XRP 總量時才觸發。攻擊者把新幣分散到數百個帳戶，每個餘額都在上限之內，輕鬆過關。
更讓人背脊發涼的是年資：不得創造 XRP 的檢查是兩年後才加進去，卻建在同一套未檢查的算術上。正常支付離溢位遠得很，只有刻意構造的掛單才碰得到，因此潛伏約十年。
破例跳過修正案：賭的是驗證者的速度
修法的思路是讓支付在算每一步總額前，先確認不會超出上限；真會超出，該段支付就乾淨地失敗，交易以一般的 path dry 或 partial payment 結果收場，不會鑄出任何 XRP。合併多條路徑的步驟同樣加了防護，不變量檢查也換成不會歸零的更寬計數器。
正常的規則變更要先隨軟體上線但預設關閉，取得超過 80% 受信任驗證者贊成並維持兩週才生效。這次修補卻是每部伺服器升級到 3.4.1 的當下就立即生效。官方的理由是 xrpld 開源，發布修補就等於公布漏洞位置，走修正案的話，漏洞會公開好幾週，主網卻仍可被攻擊。
代價是升級期間新舊版本規則不同，若有人那時發動攻擊，新舊伺服器會對帳本結果意見分歧，未升級者脫鉤，最糟整個網路停擺；官方認為，停擺仍好過寫入難以回滾的錯誤帳本，並強調只有比停擺更糟的漏洞才夠格跳過修正案，決定由 XRPL Foundation、RippleX 與驗證者共同做出。
同一份報告另揭露 Batch 功能（一次打包最多 8 筆交易）的包裝驗證漏洞，新舊版本伺服器可能因此對同一筆交易是否有效各說各話。Ripple 等驗證者先改投反對票，讓 BatchV1_1 的啟用倒數歸零重來，等修補用的 fixBatchV1_2 就位，兩者已在 10 月 9 日一起於主網生效。該功能先前從未在主網上線，沒有帳戶或資金受影響。
對節點營運者來說，現在最實際的一點是：還停在舊版的伺服器，會被新修正案擋在門外、跟不上主網帳本，升級到 3.4.1 以上已是唯一選項。
信任、獨立性與老漏洞
驗證者在看不到原始碼的情況下當天就升級，這點說明的是兩件事。一是 UNL 營運者反應迅速，是這次沒釀災的關鍵；二是這次的關鍵決定與風險，落在一小群彼此信任的 UNL 營運者身上，而不是修正案那套公開表決、兩週觀察期的集體把關。韌性與集中度，是同一枚硬幣的兩面。
開源與緊急閉源之間也有張力：開源讓每一份修補都像尋寶圖，為了搶在有人逆向工程之前補洞，就得先發布成品、事後才公開原始碼，驗證者等於憑信任升級。這次奏效，下次未必有同樣的默契。
更深一層的教訓是，檢查機制不能和被檢查的程式共用同一套算術。不變量檢查本該是獨立的第二雙眼睛，卻跟支付引擎一起算錯，同一個錯誤同時騙過施工與驗收。
再加上 AI 輔助分析與漏洞賞金的壓力，十年沒人碰到的邊角案例只會更快浮出水面。官方也新增規則：所有標記為已修復的資安發現，不論來自稽核、賞金或 AI 紅隊演練，都要用重現原始問題的測試複驗，過關才結案。
XRP 總量在 2012 年帳本啟動時就創造完畢，憑空增發將大舉衝擊價值根基，所幸對持有者與機構而言，這次沒被利用是虛驚一場。但供應上限終究靠程式碼守住，而不是靠宣示。
📍相關報導📍
Bitget 駭客轉出 8,300 萬鎂 XRP！XRPL 不支援凍結，Ripple 無能為力
Claude Opus 找到 45 億美元漏洞，讓 Zcash 崩盤背後的資安省思
Zcash 化解雙花危機！緊急啟動硬分叉升級修復零知識證明漏洞，官方確認無資金損失
