XRP Ledger（XRPL）で、XRPの供給上限を破り得る整数オーバーフロー脆弱性が見つかり、サーバーソフトウェア「xrpld 3.4.1」で修正されました。結論から言うと、開発側は公開ネットワークで悪用された証拠を確認しておらず、一般のXRP保有者に移行や交換は求めていません。一方、xrpldの運用者には3.4.1以降への更新が必要です。
報道で目立つ「約18兆XRP」は、研究者が隔離環境で示した単一取引の潜在的な生成量であり、Mainnetで実際に増えた数量ではありません。ただし、決済処理だけでなく、供給増加を検知する安全網まで同種の算術ミスで通過し得たため、コード上の危険性は重大でした。
この記事では、脆弱性が成立する仕組み、xrpld 3.4.1の修正、通常のAmendment投票を待たなかった理由、別件のfixBatchV1_2との違いを解説します。XRPの価格や将来の投資成果を予測する記事ではありません。
執筆・査読：クリプト研究所編集部が一次資料を優先して執筆し、技術編集がXRPLの用語、コード差分、事実と評価の切り分けを確認しています。責任範囲と更新方針はプロフィールで公開しています。
XRP Ledgerで何が起きたのか
供給上限を破り得た決済エンジンの算術欠陥
脆弱性は、xrpld 3.4.0以前のPayment Engineにありました。XRPLのPaymentは、単に同じ資産を一つの口座から別の口座へ送るだけでなく、分散型取引所のOfferを経由して資産を交換しながら決済できます。その処理で複数のOfferに含まれるXRP額を64ビット整数へ無検査で足し合わせると、表現できる最大値を超えて桁あふれする可能性がありました。
桁あふれによって計算結果が小さな値へ巻き戻ると、売り手側には本来のXRPが入るのに、買い手側から差し引く合計だけが小さくなる状態を作れました。差額は単なる画面表示の不整合ではなく、隔離環境の再現では支出可能なXRPになり得ました。固定供給を前提とする台帳にとって、これは「偽造」に相当し得る重大な欠陥です。
「約18兆XRP」はMainnetの被害額ではない
「約18兆XRP」という数字は、研究者が概念実証（PoC）で見積もった潜在生成量です。実際のMainnetで18兆XRPが発行された、流通量がその分だけ増えた、誰かが同額を盗んだ、という意味ではありません。大きな数字だけを切り取ると、脆弱性の能力と現実の被害を混同してしまいます。
公式開示は、公開ネットワークを調べた範囲で悪用の証拠を見つけていないとしています。ただし、「証拠が見つからない」は過去の悪用が数学的に不可能だったという証明ではありません。調査範囲や手法の詳細もすべて公開されているわけではないため、現時点の公式見解として帰属を付けて受け止めるのが適切です。
9月22日の報告から10月9日の詳細開示まで
公式の時系列では、2026年9月22日に問題が報告され、同日に再現されました。9月25日に緊急版のxrpld 3.4.1が公開され、詳細な脆弱性情報は10月9日に開示されました。発見から修正版の配布までが短く、仕組みの全面公開はネットワークへ更新が広がるまで遅らせています。
9月25日までにデフォルトUNLの80％超が更新したと公式報告は説明しています。UNLは各サーバーが合意形成で参照する信頼済みバリデータの一覧です。この数字はXRP保有者の80％や全ノードの80％を意味するものではありません。ネットワークの合意に関わる主要な構成を対象にした更新状況です。
攻撃から安全網の失敗までを因果順に理解する
まなぶ「整数オーバーフローって、数字が大きすぎるだけで、どうしてXRPが増えるんですか？」
クリプ「コンピューターの整数には入れられる上限があるんだ。上限を越えた合計が小さな数へ巻き戻り、支払う額と受け取る額が食い違ったのが核心だよ。」
極端なOffer群を一度に消費するPayment
攻撃の前提は、XRPLのクロス通貨決済が複数の流動性経路とOfferをまとめて利用できることです。OfferはDEX上の交換注文で、Paymentは条件に合うOfferを順番に消費し、送金元の資産を送金先が受け取る資産へ変換できます。この柔軟性そのものは通常の機能ですが、集計値の上限確認が欠けていました。
再現された攻撃は、数百の口座に極端な価格のOfferを用意し、それらを一度に消費するよう細工したPaymentを送るものでした。日常的な送金でたまたま発生する種類の問題ではなく、台帳の処理経路と数値境界を理解した攻撃者が、意図的な入力を組み立てる必要がありました。
買い手の引落額だけが小さく巻き戻る仕組み
理解の鍵は、「各Offerの処理」と「全体の合計」が別の計算だった点です。各売り手へ渡すXRPは個別に処理される一方、買い手から差し引くXRPの合計は64ビット整数へ加算されました。その合計が上限を越えると、値が正しい巨大な合計ではなく、小さな値へ巻き戻る余地がありました。
その結果、売り手群への入金合計と買い手からの引落額が一致せず、差額が台帳内に現れ得ました。これは価格変動による利益でも、通常の取引手数料でもありません。同じ決済の借方と貸方を一致させるはずの算術が壊れたことによる供給増加です。
数百口座への分散が必要だった理由
XRPLには単一口座が持てる残高に関する上限チェックがあり、生成しようとするXRPを一つの口座へ集めれば別の検査に阻まれます。しかし、攻撃側が多数の売り手口座を用意し、入金を分散すれば、各口座は個別上限の内側に収められます。
つまり、単一口座の制限は局所的な異常には有効でも、台帳全体で発生する差額を検出する仕組みの代わりにはなりません。攻撃に数百口座や大量の細工したOfferが必要だったことは難易度を上げますが、脆弱性の影響を消す条件ではありません。
最後の安全網も同じ桁あふれで機能しなかった
まなぶ「安全網まで同じ計算なら、鍵を二つ掛けても同じ合鍵で開いてしまう感じですか？」
クリプ「その理解でいいよ。3.4.1は入口で危険な加算を拒み、検査側にはより広い整数型を使って、二つの守りを同じ壊れ方から切り離したんだ。」
決済処理と検査処理に共通していた弱点
供給不変条件は、取引の前後でXRP総量が不正に増えていないかを確かめる安全網です。XRPLでは取引コストが焼却されるため、正当な処理で供給はわずかに減ることがありますが、決済処理が新しいXRPを生むことは想定されません。異常な増加があれば取引を失敗させるのが不変条件の役目です。
ところが、この検査も供給量を同種の64ビット整数で合算していました。攻撃入力によって決済側の合計が桁あふれしただけでなく、検査側の合計も桁あふれし、増加を正しく比較できませんでした。処理本体と安全網が同じ数値幅の前提に依存していたため、一つの境界条件が二重の防御を同時に破りました。
単一口座の残高上限だけでは防げなかった
複数の防御が存在していても、守る範囲が違えば代替にはなりません。口座残高の上限は一口座の異常値を防ぎ、供給不変条件は台帳全体の増減を検査します。今回の入力は前者を分散で避け、後者を同じ桁あふれで通過し得ました。
安全設計の観点では、処理結果を検査する仕組みは、処理本体と異なる数値表現や独立した計算方法を使うほど共通原因故障を避けやすくなります。3.4.1では加算時の拒否だけでなく、供給検査により広い整数型を使う修正が含まれました。
xrpld 3.4.1は何を修正したのか
オーバーフローする加算を失敗として拒否
第一の修正は、XRP額を加算する時点でオーバーフローを検出し、計算を続けず失敗として扱うことです。値が巻き戻ってから後段で辻褄を合わせるのではなく、正しい範囲に収まらない加算そのものを拒否します。これにより、買い手の引落額が小さく化ける経路を閉じます。
重要なのは、巨大な支払いを別の小さな支払いへ自動変換する修正ではないことです。表現可能な範囲を越える入力は有効な決済として完了させず、エラーにします。台帳では、成功と誤認させて供給差額を残すより、安全に失敗させることが優先されます。
経路間の合算と供給検査を強化
修正は一か所の足し算に限定されません。複数経路をまたぐ額の集計も強化され、供給不変条件には従来より広い整数型が採用されました。入力値が64ビットの境界へ近づいても、検査側が同じように巻き戻らず、異常な供給増加を捉えられるようにします。
公開された3.4.0から3.4.1への差分では、Paymentや台帳ヘルパーの整数演算強化と、後述するBatchラッパー検証の変更を確認できます。利用者がコード差分を直接読めない場合でも、公式リリースの署名済みタグ、配布パッケージのハッシュ、公式説明という複数の情報を照合できます。
修正後の過大な決済はどう処理されるか
修正後、合算が安全な範囲を越える決済経路は成功扱いになりません。意図した資産移転は起きず、供給差額も残りません。通常の金額と経路による送金を一律に止める修正ではなく、問題の境界を越える加算を拒否するものです。
失敗がtec系結果として検証済み台帳に記録された場合、資産移転が失敗しても取引コストは消費され得ます。送信直後の応答は最終確定ではないため、ウォレットや取引所はvalidated台帳の結果を確認し、失敗を利用者残高へ成功として反映しない設計が必要です。公式開示はこの境界超過に固有の結果コードを示していないため、本記事でも特定コードまでは断定しません。
ここでいう「過大」は、利用者の残高が少し足りない、送金額の入力を通常範囲で間違えた、といった一般的な失敗と同義ではありません。問題になったのは、多数の経路とOfferを通る合算値が整数の表現上限を越えるよう設計された入力です。したがって、3.4.1は通常のXRP送金額を新たに引き下げる変更ではありません。正当なPaymentは従来どおり処理され、境界を越える計算だけが完了前に止まります。
また、失敗時の手数料は「送金先へ一部だけ渡った代金」ではありません。XRPLの取引コストはネットワークのスパム抑止を目的にXRPから焼却されます。アプリの残高表示では、送金資産が動かなかったことと取引コストが差し引かれ得ることを分けて示す必要があります。利用者も、成功・失敗の表示だけでなく、validatedになった取引結果と残高変化を一組で確認すると誤解を避けられます。
なぜ通常のAmendment投票を待たなかったのか
まなぶ「Amendmentって何ですか？今回は投票を飛ばしたんでしょうか？」
クリプ「台帳の取引ルールを段階的に有効化する仕組みだよ。今回はオーバーフロー修正だけを更新版で即時適用し、別件のfixBatchV1_2は通常のAmendmentで有効化したんだ。」
通常のAmendmentが有効化されるまで
Amendmentは、XRPLの取引処理ルールをネットワーク全体で安全に変更する仕組みです。通常は、各サーバーが支持状況を追跡し、信頼するバリデータの80％超の支持が2週間続くと、その変更が恒久的に有効になります。参加者が対応ソフトウェアへ移る時間を確保しながら、切り替え条件を共有できます。
有効化されたAmendmentを理解できない古いサーバーは「amendment blocked」となり、検証済み台帳の追跡を正常に続けられません。この仕組みは未対応ノードが異なる規則で処理を続けることを防ぎますが、通常の待機期間があるため、詳細が知られた緊急脆弱性への即応には時間がかかります。
更新したサーバーで修正を即時有効化
今回の整数オーバーフロー修正は、Amendmentとして投票と2週間の待機を経るのではなく、3.4.1へ更新したサーバーで直ちに有効になりました。開発側は、攻撃方法が漏れた場合に固定供給を破られる危険と、通常手順を外す例外性を比較し、先に主要なバリデータへ修正版を行き渡らせる方法を選びました。
これは「XRPLでは今後も開発者が自由に規則を変えられる」と単純化できる事例ではありません。公式開示は緊急のセキュリティ対応として説明しており、報道ではAmendment制度導入後に取引処理変更を意図的に投票なしで配布した初の事例とされています。例外だったからこそ、判断過程と事後検証が重要です。
安全性を優先した異例のプロトコル変更
投票を待たない利点は、脆弱な規則が残る時間を短くできることです。一方で、参加者が公開されたコードを事前に読み、変更内容へ合意する通常の機会は減ります。また、新旧ノードの挙動が一時的に異なるため、主要バリデータを十分に更新してから詳細を明かす運用調整が必要でした。
この対応を評価する際は、「修正が必要だったか」と「修正手続きが十分に説明されたか」を分けると整理しやすくなります。重大な供給リスクを閉じる緊急性は高い一方、例外手続きが常態化しないよう、公開後の差分、署名、時系列を第三者が検証できる状態も欠かせません。
バイナリ先行配布の狙いと検証上の代償
未修正期間を短くするため詳細公開を遅らせた
3.4.1では、実行可能なバイナリと更新案内が先に配布され、攻撃箇所が分かる完全なソースコードは後日公開されました。未修正ノードが多い段階で差分を公開すると、攻撃者が修正内容から脆弱性を逆算し、実用的な取引を組み立てる可能性があります。情報公開を遅らせた狙いは、そのゼロデイ期間を短くすることでした。
同時に、公式パッケージのハッシュを提示し、運用者が入手物の一致を確認できるようにしました。ハッシュ検証は、ダウンロードしたファイルが案内された配布物と同じかを確かめる手段です。ただし、それだけでバイナリ内部の全挙動が安全だと独立検証できるわけではありません。
公開後の差分検証まで含めて評価する
オープンソースの利点は、第三者が変更前後のコードを読み、修正が十分か、別の副作用がないかを検証できることです。バイナリ先行では、その検証可能性が一時的に下がります。運用者は開発チームと配布経路を通常より強く信頼して更新する必要がありました。
判断の妥当性は、非公開期間を緊急時に限定したか、修正後に第三者が追試できる資料を出したかまで含めて評価します。今回は公開後、署名済みタグと3.4.0から3.4.1の差分を確認できる状態になりました。
署名・ハッシュ・コード差分は役割が違う
ソース公開後は、XRPL FoundationのGitHubにある3.4.1の署名済みタグと、3.4.0からの比較画面を確認できます。運用者は非公式なミラーやSNSのリンクだけに頼らず、公式リリース、署名、パッケージハッシュを相互に照合してください。組織内に変更管理がある場合は、取得元と検証結果を記録します。
署名は「誰がそのタグを作成したと示しているか」、ハッシュは「配布物が途中で変わっていないか」、コード差分は「何が変更されたか」をそれぞれ確認するものです。一つの確認で全部を保証するわけではないため、役割の違う検証を重ねることが重要です。
fixBatchV1_2は別の脆弱性への対策
Batchラッパー検証不備が招く合意リスク
3.4.1には、整数オーバーフローとは別にBatch取引の検証不備への対策も含まれます。Batchは最大8件の内部取引を一つに束ね、全件成功などの実行モードを指定できる機能です。問題は内部取引を包むラッパーの検証が不十分で、ノードによって取引の解釈が食い違うリスクがあったことです。
このBatch問題は、XRPを新しく作る算術欠陥でも、秘密鍵を盗む問題でもありません。異なるノードが同じ入力へ異なる判断をすると、合意形成へ影響し得る点が危険でした。二つの問題は同じ緊急版で対応されたため混同されやすいものの、原因、影響、適用方法が異なります。
fixBatchV1_2が拒否する不正な内部取引
fixBatchV1_2は、Batch内のRawTransactionに格納される内部取引について、ラッパーや関連フィールドの条件を正しく検査し、不正な形式を拒否するプロトコル修正です。Batchの便利な実行モードを残しながら、ノード間で同じ検証結果になるよう規則を明確にします。
ここで「3.4.1を入れれば即時有効」と「Amendmentが有効になれば規則が切り替わる」を分けてください。オーバーフロー対策は更新サーバー上で即時に働きましたが、fixBatchV1_2は対応コードを配布したうえで、Amendmentの支持と有効化を経ています。
2026年10月9日にMainnetで有効化
fixBatchV1_2は2026年9月25日に多数支持へ入り、通常の待機を経て10月9日にMainnetで有効化されました。有効化後、未対応の古いxrpldはamendment blockedとなり、ネットワークを正常に追跡し続けられません。このため、ノード運用者にとって3.4.1以降への更新は任意の機能追加ではありません。
日付が重なるのは偶然ではなく、詳細な脆弱性開示も主要な更新とBatch Amendmentの有効化を待って行われました。ただし、「両方の修正が投票なしで10月9日に入った」と理解するのは誤りです。整数オーバーフローは更新時に即時適用、Batchの修正はAmendmentで10月9日に有効化、という二本立てです。
一般保有者とノード運用者に必要な対応
一般保有者にXRPの移行や交換は不要
一般のXRP保有者に対して、今回の修正を理由に新しいXRPへ交換する、別チェーンへ移行する、ウォレットを再同期する、といった公式要件は示されていません。自己管理ウォレットにあるXRPを「修正版トークン」へ変える必要もありません。まず資産を動かすのではなく、利用中の取引所やウォレットの公式案内を確認してください。
XRPLやXRPの基礎を確認したい場合は、リップル（XRP）の仕組みを解説した記事も参照できます。今回更新対象になったxrpldはネットワークへ接続するサーバーソフトウェアであり、保有者の残高を別資産へ置き換えるアップグレードではありません。自己管理時の秘密情報の守り方は秘密鍵管理の基本で確認できます。
ノード運用者は3.4.1以降へ更新
xrpldサーバーを運用している組織や個人は、3.4.1以降へ更新する必要があります。古いバージョンはオーバーフロー修正を持たず、fixBatchV1_2の有効化後はMainnetでamendment blockedになります。監視用やAPI用のノードも、取引を直接提案しないから安全と決めつけず、バージョンと同期状態を確認してください。
更新時は、設定やデータのバックアップ方針、停止時間、再起動後のvalidated ledger追従、ログ上の警告を運用手順に沿って確認します。具体的なコマンドやパッケージは環境によって異なるため、公式の3.4.1案内とリリースノートを基準にしてください。
公式ハッシュと署名を検証する
緊急更新を装うマルウェアを避けるため、配布元は公式サイトまたはXRPL Foundationの公式リポジトリへ限定し、案内されたパッケージハッシュと署名を検証します。検索広告、SNSの短縮URL、第三者が再配布した実行ファイルは、公式の名称を使っていても信頼の根拠になりません。
未修正の脆弱性を見つけた場合は、公開Issueへ再現手順を書かず、SECURITY.mdに示された非公開の報告窓口を使います。責任ある開示は、修正が行き渡る前に攻撃方法を広げないための手順です。すでに公開された不具合の一般的な質問と、未知の脆弱性報告は分けて扱います。
「悪用証拠なし」を過信せず便乗詐欺を警戒
公式調査で悪用の証拠が見つかっていないことは重要ですが、保有者が秘密鍵やシードフレーズを入力して安全確認を行う必要はありません。「供給バグの被害確認」「新XRPへの交換」「ウォレット修復」を名乗るサイトへ接続しないでください。公式サポートを名乗る相手でも、秘密情報を要求する案内は拒否します。典型的な誘導は暗号資産詐欺の対策ガイド、実例に基づく確認点は資産流出を防ぐセキュリティガイドでも整理しています。
また、脆弱性が修正された事実からXRP価格の上昇や下落を断定することもできません。投資判断では、技術リスクの解消状況と市場価格を別の論点として扱い、許容できる損失や保管方法を自分で検討する必要があります。
立場別の確認チェックリスト
- 取引所にXRPを置いている人：取引所の公式な入出金案内だけを確認します。今回の修正を理由に、第三者の指定アドレスへ送金する必要はありません。入出金が一時停止された場合も、復旧時刻をSNSの返信欄ではなく取引所の公式告知で確かめます。
- 自己管理ウォレットを使う人：アプリの正規配布元と更新情報を確認します。秘密鍵やシードフレーズは残高確認、脆弱性診断、トークン交換のためにウェブサイトへ入力するものではありません。取引を送った場合は、表示上の送信完了だけでなくvalidatedの結果を確認します。
- xrpld運用者：稼働中のバージョン、取得元、ハッシュ、署名、同期状況を記録します。3.4.1以降へ更新後、最新の検証済み台帳を追跡できているか、ログにamendment blockedや継続的なエラーがないかを監視します。
- ウォレット・取引所の開発者：Paymentの送信応答を最終確定とみなさず、validated台帳の結果と失敗コードを処理します。極端な経路や複数Offerを扱う入力が失敗した際、利用者残高へ成功として反映しないことを確認します。
今回の用語を短く整理
- Offer：XRPLの分散型取引所に置かれる交換注文。Paymentが経路の一部として消費することがあります。
- Payment Engine：送金や経路を使った資産交換を処理するxrpldの機能。今回の算術欠陥があった中心部分です。
- 整数オーバーフロー：固定幅の整数が表せる範囲を計算結果が越え、正しい合計を保持できなくなることです。
- 供給不変条件：取引処理の前後でXRPが不正に増えていないかを確認する安全検査です。
- Amendment：バリデータの支持を追跡し、XRPLの取引規則をネットワーク全体で切り替える仕組みです。
- amendment blocked：有効なAmendmentを理解できないサーバーが、検証済み台帳を正常に追跡できなくなった状態です。
まとめ：自分の立場に必要な対応を確認する
原因は、細工したOffer群を処理するときの無検査な64ビット加算と、同じ弱点を持つ供給検査でした。3.4.1は境界を越える加算を拒否し、経路集計と検査側の整数演算も強化しています。
一般保有者は資産交換をせず、便乗詐欺を避けてください。ノード運用者は3.4.1以降へ更新し、取得元、ハッシュ、署名、validated ledgerへの追従を確認します。約18兆XRPはPoC上の潜在量で、公式にはMainnetでの悪用証拠は確認されていません。
