XRPレジャー、XRPを無から発行できた欠陥を公表 悪用の形跡なし

1回の決済でXRPを新たに作り出せる欠陥が、XRPレジャー（XRPL）に10年近く潜んでいた。XRPL公式サイト（xrpl.org）は10月9日（現地時間）に脆弱性開示レポートを公表し、この欠陥を9月25日に緊急リリースしたサーバーソフトxrpld 3.4.1で塞いだと明らかにした。レポートは「We have found no evidence that this issue was exploited on any public network」（公開ネットワークで悪用された証拠は見つかっていない）と記した。

同じレポートには、9日夜にメインネットで有効化されたバッチ取引機能の欠陥も併せて掲載された。Coinyongが9日に報じたバッチ関連アップグレード2件が、なぜ一度延期された後に有効化されたのかがこのレポートで明らかになった。

1. 9月18日バッチ機能の検証漏れを再確認、公開の修正作業を開始
2. 9月22日バグ報奨金で決済エンジンの欠陥が報告され、当日「XRP発行可能」を再現
3. 9月22〜23日決済エンジンの修正版を非公開で開発、投票なしで配布すると決定
4. 9月23〜24日リップルなどバリデーターがバッチ機能への賛成票を撤回、バッチ修正を3.4.1に統合
5. 9月25日xrpld 3.4.1を配布、同日、デフォルトの信頼ノードリスト（UNL）のバリデーターの80%超がアップグレード
6. 10月9日23:15バッチのセキュリティ修正（fixBatchV1_2）がメインネットで有効化（韓国時間）
7. 10月9日23:47バッチ取引（BatchV1_1）がメインネットで有効化（韓国時間）

合計があふれると小さな数に戻った

問題は、決済が取引所の板（オーダーブック）の注文を複数まとめて買い取る際に起きた。XRPLの決済エンジンは買い手が支払う額を64ビット整数で足し合わせていたが、合計が上限を超えてもエラーにならず、ごく小さな数に戻ってしまった（オーバーフロー）。エンジンは注文を出した各アカウントに全額を支払う一方、買い手からは戻った小さな合計しか受け取らず、その差額分だけ存在しないはずのXRPが生まれた。

XRPLには「どの取引もXRPを生み出せない」という安全チェックがあるが、このチェックも同じ方法で合計を計算していたため同様に数が戻り、何も検知できなかった。1つのアカウントが総発行量より多く保有すると引っかかるチェックは、発行したXRPを数百のアカウントに分散させれば回避できた。レポートは、この欠陥が現在の決済エンジンが作られた2015年から存在していたと調査で判断したとしている。

攻撃に大きな元手も必要なかった。レポートによると、攻撃者は数百のアカウントを作ってそれぞれ少量のトークンを法外な量のXRPで売る注文を出し、別のアカウントからそれらの注文を一度に買い取る決済を送ればよかった。かかる費用はアカウント・注文の準備金数百XRPと手数料程度だった。報告時の深刻度は「Major」だったが、リップルXのエンジニアチームが欠陥を再現し、発行されたXRPが実際に使えることを確認した後に「critical」へ引き上げた。レポートは、悪用されていれば「could have created spendable XRP far beyond the total supply in a single validated transaction」（1回の取引で総発行量をはるかに超えるXRPを作れた）とし、取引所へ送ることもできたと説明した。ただし、実際のトレーダーが使わない価格の注文が数百件必要なため、偶然起きることはなかったとも付け加えた。欠陥はバグ報奨金プログラムの参加者であるケイデン・リャオ氏とVeria AIが報告した。

投票なしで変わった初のルール

XRPLの取引処理ルールは通常「アメンドメント」と呼ばれる投票を経る。信頼されたバリデーターの80%超の支持が2週間続いて初めて、全サーバーで同時に有効になる。今回の修正はこの手続きを経ず、各サーバーが3.4.1に更新した時点で即座に適用された。レポートは「the first time a change to transaction processing has deliberately shipped this way since the amendment system was introduced more than ten years ago」（10年余り前にアメンドメント制度が導入されて以来、取引処理の変更を意図的にこの形で配布した初の事例）だとした。

理由として挙げたのはコードの公開性だ。xrpldはオープンソースのため修正版を出せば欠陥の場所も明らかになり、投票手続きを踏めば数週間にわたり欠陥が知られたままメインネットで悪用されかねなかったという。バージョンが混在する間はサーバー同士で台帳が食い違いネットワークが停止する恐れもあったが、レポートは誤ったXRPが台帳に残るより停止する方がましだと判断したと説明した。デフォルトの信頼ノードリスト（UNL）の運営者の80%超が、ソースコードが公開される前の配布当日にアップグレードを済ませた。レポートは、この決定がXRPL財団、リップルX、バリデーターの合意で行われ、今後も取引処理の変更はアメンドメントを経ると強調した。

バッチ機能は投票を戻して延期

併せて公表されたもう1つの欠陥は、最大8件の取引を1つの束として処理するバッチ機能（XLS-56）にあった。束の中の取引は「RawTransaction」という欄に入れる必要があるが、サーバーがこれを確認していなかったため、別の欄に入った取引も受け入れられた。レポートは、この場合サーバーのバージョンごとに判断が分かれて台帳の確定が止まる恐れがあり、取引記録を読むウォレットやエクスプローラーが誤作動する可能性もあったと説明した。資金を引き出せる欠陥ではなく、機能が有効化される前だったためメインネットの被害もなかった。

バッチ機能は当初9月29日に有効化される予定だった。リップルなどのバリデーター運営者は賛成票を反対に切り替えて2週間の待機期間をリセットし、修正案が多数の支持を得た後に再び賛成に戻した。その結果、XRPLエクスプローラーXRPSCANによると、修正案が韓国時間9日午後11時15分に、バッチ機能が32分後に有効化された。3.4.1に更新していないサーバーは、もはやネットワークと同期できない。

バッチ有効化の翌日、XRPは1900ウォン台で横ばい

韓国時間10日午後5時30分、XRPはアップビットのウォン建て市場で1917ウォンで取引された。前日終値比0.4%高で、同時刻のビッサムでは1916ウォンだった。バイナンス現物価格は1.4065ドルで、これをウォン換算した価格よりアップビットが約1.6%高かった。この差はキムチプレミアム（韓国の取引所価格と海外価格の差）と呼ばれる。アップビットにおけるXRPの過去52週の最高値は、2025年10月27日の3970ウォンだ。