Last Updated on 2026年10月11日 by oba3
XRPレジャー（XRP Ledger・XRPL）は2026年10月9日、決済エンジンの整数オーバーフローによって、本来存在しないXRPを生成できた重大な脆弱性の詳細を公表した。問題は2015年に現在の決済エンジンが書かれた時点から存在していたとみられ、約10年間見つからないまま残っていた。
修正はすでに9月25日公開のxrpld 3.4.1へ組み込まれており、XRPL側は公開ネットワークで悪用された証拠は確認していないとしている。今回見るべきなのは価格への影響ではない。固定供給を前提とする通貨プロトコルでも、実装上の計算ミスが供給ルールそのものを破壊し得ること、そしてその最終防衛線となる安全チェックまで同じ欠陥を共有していた点だ。
何が起きたのか？
XRPLは10月9日の脆弱性開示で、決済エンジンに整数オーバーフローの問題があったと説明した。脆弱性は9月22日にXRPL Bug Bounty Programを通じて報告され、当初はMajorと評価されたが、RippleXのエンジニアがローカル環境で再現し、生成したXRPを後続取引で実際に使用できることを確認したためCriticalへ引き上げられた。
問題が起きたのは、単一のPaymentがオーダーブック上の多数のOfferを消化するときだ。決済エンジンは買い手が支払うXRP総額を64ビット整数で加算していたが、合計値が扱える上限を超えた場合にエラーを出さず、小さな数値へ巻き戻るオーバーフローが発生した。
一方、それぞれのOffer所有者には本来の大きな金額が個別に支払われた。この結果、買い手から差し引かれるXRPより、Offer側へ加算されるXRPの方が大きくなり、その差額として本来存在しないXRPが生まれる状態になった。
攻撃には数百件の特殊なOfferと、それらを一度に消化するよう意図的に作られたPaymentが必要だった。通常の取引が偶然この条件へ到達することは想定されておらず、XRPLも通常取引では総供給量が64ビット整数のオーバーフロー領域へ近づかないと説明している。
さらに重要なのは、XRPが新規生成されていないことを確認する既存の安全チェックも同じ問題を抱えていたことだ。このチェックも残高変化を同様の64ビット整数で合計していたため、攻撃時に同じオーバーフローを起こし、不正生成を検出できなかった。
なぜ重要なのか？
暗号資産の供給量は、単なる表示上の数字ではない。誰が新しい通貨を発行できるか、どの条件で供給が増減するかはプロトコルの根本的なルールになる。
XRPLではXRPを通常の取引によって新規発行することは想定されていない。しかし今回の欠陥では、特殊な取引を組み合わせることで、正規の発行ルールを通らずに使えるXRPを作れる状態だった。
しかも攻撃者が巨大な初期資金を用意する必要はなかった。XRPLによると、実際に必要となるコストは数百アカウントやOfferを維持するための準備金と通常の手数料が中心で、生成されたXRPは一般アカウントへ移動し、取引所へ送ることも技術上可能だった。
これは固定供給という経済ルールが、最終的にはコード内の整数計算と検証ロジックによって保証されていることを示す。ホワイトペーパーや仕様書に供給上限を書くだけでは足りず、すべての実行経路でそのルールが破られないことを確認する必要がある。
市場構造への影響
ブロックチェーンの信頼性は、コンセンサスだけで決まるわけではない。多数のバリデーターが同じ取引を正しく合意しても、その取引処理ルール自体に欠陥があれば、誤った状態を全員で正しく承認してしまう可能性がある。
今回の問題はその典型だ。悪意あるPaymentが有効な取引として処理されれば、不正に生成されたXRPを含む台帳でもコンセンサス自体は成立し得た。つまり分散性と通貨供給の完全性は別々に検証する必要がある。
さらに、供給増加を検知するためのinvariantと呼ばれる安全チェックまで同じ計算方法に依存していた。一次処理と二次検証が同じ種類の演算に依存すると、一つの欠陥が双方を同時にすり抜ける可能性がある。
このため今後重要になるのは、安全チェックを単に増やすことではなく、異なる方法で同じ不変条件を確認することだ。XRPLは今回の修正で、Payment側に明示的なオーバーフローチェックを追加するとともに、「XRPが生成されていないこと」を確認する安全チェックを、同様の巻き戻りが起きないより広いカウンターへ変更した。
資金・規制・流動性との関係
もし供給量を超えるXRPが実際に生成されていれば、問題はプロトコル内部だけにとどまらなかった。新しく作られたXRPは通常アカウントへ入り、他のウォレットへ送金したり、取引所へ持ち込んだりできるとXRPLは説明している。
その段階では、どのXRPが正規供給分で、どのXRPが不正生成分かを市場参加者が容易に区別することは難しい。取引所、カストディアン、決済事業者まで巻き込んだ対応が必要になり、場合によっては取引停止や入出金制限、台帳状態をどう扱うかという難しい判断につながり得る。
この深刻度を理由に、今回の修正は通常のamendment手続きを通さず、xrpld 3.4.1へ直接組み込まれた。XRPLでは通常、取引処理ルールの変更はバリデーターの80％超の支持を2週間維持してから有効化する。しかし今回その方式を取れば、修正コードが公開された後も数週間にわたりMainnet上で脆弱性が利用可能な状態が残る。
そのため開発側と関係バリデーターは、バージョン混在によるコンセンサスリスクを受け入れてでも即時適用する方を選んだ。9月25日の3.4.1公開日には、default UNLの80％超のバリデーターが新バージョンへ更新したとしている。
この対応は、緊急時に「分散的なアップグレード手続き」と「供給破壊を防ぐ即時修正」のどちらを優先するかというガバナンス上の問題も示した。XRPL側も、通常手続きを省略するのは極めて重大な脆弱性に限る例外的な判断だったと説明している。
初心者向け補足
整数オーバーフローとは、コンピューターが扱える数値の上限を超えたときに、計算結果が想定外の小さな数字へ戻ってしまう現象だ。今回の場合、大きなXRP金額を多数足し合わせた結果が64ビット整数の上限を超えたことで発生した。
たとえば本来100を支払う必要がある計算が、上限を超えたことで2のような小さな数字として扱われる一方、受取側には個別計算した100相当がそのまま加算されると、差額がどこからも差し引かれず生まれる。実際のXRPLでははるかに大きな整数値と数百のOfferが使われるが、原理はこの不整合にある。
今回の脆弱性は「XRPを発行できる管理者権限が漏れた」という問題ではない。Payment処理の計算ミスによって、台帳上の残高合計が本来のルールを超えて増える可能性があった。
XRPLは公開ネットワーク上で悪用された証拠を確認していないとしている。修正版では、合計値が上限を超える前に処理を失敗させるチェックと、別の方法で総残高変化を確認する防御が追加された。
Web3Timesの視点
今回見るべきなのは「XRPが無限に増やせた」という刺激的な表現ではない。より重要なのは、通貨供給の完全性がどのコード、どの安全チェック、どのアップグレード手続きによって保証されているかだ。
第一の観測点は、同じ欠陥が約10年間残った理由である。問題のPaymentコードは2015年から存在し、その約2年後に追加された「XRPを新規生成させない」安全チェックも同じ種類の未検査整数演算を使っていた。一次処理と防御側が同じ前提を共有した結果、長期間発見されなかった。
第二は監査方法だ。今回の問題は通常の利用では到達しない極端な数値条件で発生した。XRPLは今後、独立監査、公開Attackathon、AIを使ったレッドチーミング、ファジング、形式検証、Bug Bountyを組み合わせ、修正済みとされた問題もリリース候補版で再現テストを行う工程を追加するとしている。
第三はアップグレード体制である。固定供給を破壊し得るバグでは、脆弱性を公開してから通常の投票期間を待つこと自体が攻撃機会になり得る。今回XRPLが10年以上で初めて取引処理の修正を通常のamendment手続き外で投入したことは、緊急対応ルールそのものもプロトコルセキュリティの一部であることを示している。
第四は不変条件の独立性だ。「XRPは勝手に増えない」という最重要ルールを、一つのコードパスだけで保証してはいけない。決済エンジン、台帳全体の残高検査、テスト、監査がそれぞれ異なる方法で同じ条件を確認できれば、一つの実装ミスがすべての防御を同時に突破する確率を下げられる。
暗号資産の通貨供給は経済政策だけで決まるものではない。最終的には整数型、境界値処理、安全チェック、バリデーター更新という低レベルな実装によって守られている。XRPLの今回のバグは、供給上限を掲げるプロトコルにとって最も重要なのが「発行ルールを宣言すること」ではなく、「どの取引経路からもそのルールを破れないことを継続的に証明すること」だと示す事例になった。
