Last Updated on 2026年10月10日 by Co-Founder/ Researcher
XRP Ledgerでは、取引処理のルールを変えるとき、バリデーターの80%超が2週間支持し続けることを条件にしてきました。9月25日に配られた修正は、その投票を一度も通らないまま有効になっています。10年以上続いた合意の手続きを、なぜこのときだけ外したのか。そこに、XRPを生み出せた脆弱性そのものより重い問いがあります。
XRP Ledgerの公式ブログは2026年10月9日、同ブログによると9月25日公開のサーバーソフトウェア「xrpld 3.4.1」で修正した2件の脆弱性を開示した。1件は支払いエンジンの整数オーバーフローで、数百件の注文を1件の支払いでまとめて約定させると、総供給量をはるかに超えるXRPを1件の取引で生み出せた。
9月22日にバグバウンティ経由で報告され、深刻度はクリティカルに引き上げられた。修正はアメンドメントを経ず、各サーバーが3.4.1へ更新した時点で有効になった。公開ネットワークで悪用された証拠はない。もう1件はBatch機能の内側トランザクションの検証漏れで、修正用のfixBatchV1_2が10月9日にMainnetで有効化された。
From: Vulnerability Disclosure Report for xrpld 3.4.1
【編集部解説】
今回の開示でまず押さえておきたいのは、仕組みそのものは驚くほど素朴だという点です。
支払いエンジンは、数百件の注文で支払うべきXRPの合計を、64ビットの整数で足し算していました。整数には上限があり、それを超えると、車の走行距離計が999999の次に000000へ戻るように、値が小さな数へ折り返します。売り手一人ひとりには満額が支払われる一方、買い手の請求額は折り返したあとの小さな数で済んでしまう。その差額が、存在しなかったXRPとして台帳に現れる構造でした。
XRP Ledgerには、取引のたびに「XRPが新たに生まれていないか」を確かめる不変条件（インバリアント）があります。ところが、この検算も同じ64ビットの足し算で行われていたため、検算する側も同じように折り返し、異常を見逃していました。さらに、1つのアカウントが1,000億XRPを超える残高を持てば別の検査に掛かりますが、生まれたXRPは数百のアカウントに分散するため、そこもすり抜けます。
台帳を守る二重の仕組みが、同じ一つの前提を共有していたことが、この脆弱性の核心です。開示によれば、支払いエンジンが書かれた2015年からこの状態が続いていた可能性があり、不変条件はその2年後に、同じ演算のまま追加されました。
一部のSNS投稿では「無制限に新規発行できる」と伝えられていますが、開示文書が説明しているのは、総供給量をはるかに超えるXRPを、1件の検証済み取引で生み出せたという問題です。生成量の具体的な上限は示されていません。XRPは2012年の発行時に1,000億XRPが生成され、新たに作られない前提で設計されています。その前提を数百XRP程度の準備金と手数料だけで破れた以上、RippleXが深刻度をクリティカルに引き上げたのはうなずける判断でした。
そして、Crypto Verseがこの事案でもっとも重く見るのは、修正の届け方です。
XRP Ledgerでは、取引処理のルールを変えるとき「アメンドメント」という手続きを踏みます。信頼されたバリデーターの80%超が2週間にわたって支持し続けて、はじめて変更が有効になります。ルールの変更には参加者の合意が要るという、分散型台帳の根幹にあたる仕組みです。
今回の修正は、この手続きを通りませんでした。各サーバーが3.4.1へ更新した瞬間に、新しいルールが適用される方式です。開示によれば、アメンドメント制度が導入されて10年以上がたつなかで、取引処理の変更を意図的に制度の外で配ったのは今回がはじめてです。
理由は明快です。アメンドメントとして配れば、有効化までの2週間とバリデーターが更新を終えるまでの期間、脆弱性は塞がれないまま残ります。そのあいだに修正の中身が知られれば、直すための公開が、そのまま攻撃の手引きになりかねない状況でした。悪用が安価で、一度生まれたXRPを元に戻すのも難しい。そこで開発陣は、内容を伏せた緊急リリースとして3.4.1を配り、ソースコードは開示に合わせて公開する道を選びました。
ここで見落とせないのは、通常のアメンドメント投票を省いたことと、関係者の合意がなかったことは同じではないという点です。開示文書によれば、この判断はXRPL Foundation、RippleX、XRPLのバリデーターの関係者が同意し、コミュニティと協働して下したものです。そして、その判断を実際の防御に変えたのは、各運営者による更新でした。リリース当日のうちに、デフォルトUNLに載るバリデーターの80%超が3.4.1以上へ更新しています。ソースコードの公開前に、多くのバリデーターが同じ日に更新に踏み切ったことを、Crypto Verseは緊急対応を支えた信頼の表れと受け止めます。
開発陣は、更新の途中で悪用が試みられれば、バージョン間で台帳の判定が食い違い、ネットワークが止まるおそれがあったことも認めています。それでも、悪用の取引を処理して誤った台帳を作るより、止まるほうが望ましいと判断しました。そのうえで、今回の件はプロトコルの変え方を変えるものではなく、取引処理の変更は引き続きアメンドメントを通すと明言しています。例外が正当化されるのは、悪用の被害がネットワークの停止よりも深刻な、最重大級のバグに限られるという基準です。
もう1件のBatchの不具合からも、同じ方向の教訓が読み取れます。Batchは、1つのアカウントが最大8件の取引をひとまとめに送れる機能です。この機能は発見時点でMainnetでは有効になっておらず、資金や取引への影響もありませんでした。外部の攻撃コンテスト（Sherlock Attackathon）で見つかった指摘はいったん修正済みとされていましたが、再検証で修正が不完全だと分かりました。開発陣はこれを受け、監査やバグバウンティ、AIによるレッドチーミングで出た指摘を、リリース候補で元の事象を再現するテストが通るまで閉じない方針に改めています。
オーバーフローの報告者として、ケイデン・リャオ氏とともに「Veria AI」の名が挙がっていることも目を引きます。開示文書は防御の層として、独立した監査や公開の攻撃コンテスト、ファジング、形式検証と並べて、AIを使ったレッドチーミングを挙げています。今回の発見にAIがどう使われたかは、開示文書では説明されていません。それでも、10年以上見過ごされてきた可能性のある問題をバグバウンティが拾い上げ、検証の道具立ても広がっているのは確かです。見つける力が上がるほど、直して配る手順の確かさが台帳の安全を左右する時代に入ったと言えそうです。
開示文書が求めている対応は、ノード運営者によるサーバーの更新です。悪用の証拠は見つかっていません。ノードを運営している場合は、fixBatchV1_2の有効化により、3.4.1未満のサーバーはアメンドメント・ブロックの状態となり、台帳と同期できなくなります。早めの更新が必要です。
今回の開示文書は、何が起き、なぜ制度の外で直し、どこにリスクを残したかを、自らの判断の重さも含めて記録しています。合意の仕組みを持つ台帳が、合意を待てない危機にどう向き合うか。その一つの答えが、詳細な記録とともに公開されたことは、XRP Ledgerに限らず、パブリックチェーン全体のこれからの作法を考える手がかりになるはずです。
【用語解説】
xrpld
XRP Ledgerのサーバーソフトウェア。旧称はrippled。ノードの運営者がこれを動かし、取引の検証や台帳の同期を行う。
整数オーバーフロー
コンピューターが扱える整数の上限を計算結果が超えたとき、値が小さな数へ折り返したり、誤った値になったりする現象。今回は、64ビットの加算で注文額の合計が折り返した。
不変条件（インバリアント）
取引の処理後に、台帳が満たすべき条件を確かめる仕組み。XRP Ledgerでは、取引が手数料分を除いてXRPを生み出していないこと、各アカウントの残高が0以上1,000億XRP以下であることなどを検査する。
アメンドメント
XRP Ledgerで取引処理のルールを変える手続き。信頼されたバリデーターの80%超が2週間にわたって支持し続けると、変更が有効になる。
アメンドメント・ブロック
有効になったアメンドメントに対応していない旧版のサーバーが陥る状態。台帳の検証や取引の処理ができなくなり、最新版へ更新すれば解消する。
バリデーター
XRP Ledgerで取引の検証と合意形成に参加するサーバー。アメンドメントへの投票も担う。
UNL（デフォルトUNL）
Unique Node Listの略で、各サーバーが信頼するバリデーターの一覧。デフォルトUNLは、多くのサーバーが標準で採用している推奨リストを指す。
Batch
1つのアカウントが最大8件の取引をひとまとめに送れる機能（仕様番号XLS-56）。全部成功か全部失敗かを選べるなど、複数の操作をまとめて扱える。
バグバウンティ
脆弱性を見つけて報告した人に報奨金を支払う制度。今回のオーバーフローは、XRPLのバグバウンティを通じて報告された。
レッドチーミング
攻撃者の立場からシステムの弱点を探す検証手法。AIを使って行うものも含まれる。
ファジング
ランダムな入力や異常な入力を大量に与えて、プログラムの不具合を探すテスト手法。
形式検証
プログラムが仕様どおりに動くことを、数学的な証明によって確かめる手法。
【参考リンク】
XRPL.org（外部）
XRP Ledgerの技術文書、開発者向け資料、脆弱性開示やリリースノートを掲載するコミュニティ主導の公式ポータルサイト。
XRPL Foundation（外部）
XRP Ledgerのコミュニティを支える非営利組織。インフラ、コア開発、ガバナンスなどの作業部会を通じてネットワークを支援する。
RippleX（Ripple）（外部）
RippleでXRP Ledgerの開発者支援を担うチーム。今回のオーバーフローでは、報告の再現と深刻度の引き上げを担った。
Sherlock（外部）
Web3のセキュリティ企業。専門家による監査や公開の監査コンテスト、AIを使ったレビュー、バグバウンティを提供している。
XRPLF/rippled（GitHub）（外部）
XRP Ledgerのサーバーソフトxrpldのソースコードを管理するリポジトリ。3.4.1のソースは開示に合わせて公開された。
【参考記事】
Introducing XRP Ledger version 3.4.1（XRPL.org）（外部）
xrpld 3.4.1の告知。緊急リリースであること、fixBatchV1_2の有効化予定日、配布ファイルのハッシュと署名を記載する。
XRP Ledger patched decade-old bug that could create billions of dollars in XRP from nothing（CoinDesk）（外部）
2015年からとされるバグにより、XRPを新たに生み出して使えた可能性を報じた。RippleXは悪用の証拠はないとしている。
XRPL patches payment engine bug that could mint spendable $XRP（DeFiprime）（外部）
注文の合計を64ビットで加算した際の折り返しの仕組みと、修正をアメンドメントの外で配った判断の経緯を詳しく整理している。
RippleX Finds No Evidence of Exploitation After XRPL Patch（TokenPost）（外部）
悪用の証拠なしとするRippleXの説明を中心に、9月22日の報告からデフォルトUNLの80%超が当日更新するまでを伝えた。
Strengthening XRP Ledger Security with AI For Next Phase of Growth（Ripple）（外部）
2026年3月の公式ブログ。AIを活用したレッドチームが10件超のバグを見つけたとし、監査の拡充や攻撃コンテストの継続を掲げた。
【編集部後記】
3.4.1のリリースノートには、配布ファイルごとのSHA-256ハッシュと、XRPL Foundationの鍵による署名が添えられていました。ソースコードは後日公開とされ、示されたコミットのIDも、公開時のブランチでは変わると書かれていました。
更新を決めた運営者の手元にあった確かめる手段は、ハッシュと署名だけだったことになります。受け入れたバイナリが、いま公開されたソースと同じものなのか。その答え合わせに挑める材料が、ようやく誰の手にもそろいました。