XRP Ledger、緊急セキュリティ修正で深刻な供給バグに対処
重要ポイント
- •XRP Ledgerの決済エンジンに2015年から存在していた深刻な整数オーバーフローのバグは、特別に細工されたオファを通じて攻撃者が追加の使用可能なXRPを生成できる可能性があり、台帳の1,000億トークンの固定供給ルールを脅かしていました。
- •開発者は、バグ報奨金プログラムを通じてバグが報告されてから3日後に緊急パッチを展開し、10年以上ぶりに意図的に標準的な2週間のバリデータ投票プロセスを回避しました。
- •XRP Ledger Foundationは、実際にXRPが新規発行されたわけではないことを明らかにし、緊急パッチはFoundation、RippleX、開発者、バリデータの共同合意によるものだと述べました。
- •通常の修正プロセスの回避により、XRPの法的分類にも関わる同ネットワークの分散性をめぐる論争が再燃し、Cyber Capitalの共同創設者Justin Bonsのような批評家は、このネットワークの分散性の主張を誤解を招くと非難しました。
- •RippleXは、AIを活用した脆弱性検出、敵対的テスト、形式検証、外部セキュリティ専門家との連携を通じてXRP Ledgerのセキュリティを強化する計画です。

XRP Ledgerの開発者は、ネットワークの固定供給量1,000億トンにもかかわらず、悪意ある第三者が追加の使用可能なXRPを生成する可能性があった深刻なバグに対応し、緊急セキュリティパッチを公開しました。
この修正では、台帳の標準的な2週間のバリデータ投票プロセスが回避されました。開発者は、待機すれば潜在的な攻撃者に脆弱性を悪用する時間を与えていたと主張し、この決定を正当化しています。パッチは、セキュリティ脆弱性の責任ある開示を研究者に報いるバグ報奨金プログラムを通じてバグが報告されてから3日後に、即時適用という形で展開されました。開発者によると、これは10年以上ぶりとなる意図的な修正プロセスの回避でした。
この対応により、XRP Ledgerが深刻な問題にどう対処するのか、そして分散性へのコミットメントについて、幅広い議論が巻き起こっています。
緊急パッチ、バリデータ承認プロセスを回避
XRP Ledgerのプロトコル修正は通常、変更が発効するまでに2週間の期間で80%を超えるバリデータの合意を必要とします。これは、ネットワークのルールに対する変更が広い合意を得たうえで有効化されることを保証するための閾値です。開発者は、セキュリティパッチの投票結果を待っていれば、この抜け穴が悪用される状態のまま残る可能性があったと指摘しています。
日曜日にXRP Ledger開発者がブログで公開した投稿によると、通常の修正プロセスでは、修正が数週間にわたり公開されたままになり、修正が有効化される前にネットワークが危険にさらされる可能性がありました。
緊急パッチによって問題は迅速に解決されましたが、通常のプロセスを回避するという決定は、セキュリティ侵害への対応において開発チームが果たす役割について疑問を投げかけるものとなりました。
Foundation、XRPは新規発行されていないと明言
XRP Ledger Foundationは、修正後の混乱を解する動きを見せました:
The recent XRP Ledger security fix raised a lot of questions and some misconceptions. Let's clear them up. 1. Was any XRP created? No. XRP's supply was fixed at 100 billion when the XRP Ledger launched, and no transaction is allowed to create more. This bug was a way around… — XRP Ledger Foundation (@XRPLF) October 11, 2026
パッチが分散性論争を再燃
緊急対応は、XRP Ledgerが分散型であるかどうかという議論を再燃させました。これはXRPの法的地位の判断における主要な論点の一つです。中核チームがネットワークに対して保持する管理の度合いは、規制当局がデジタル資産をどのように分類すべきかを判断する際に、繰り返し考慮されてきた要素です。
Cyber Capitalの共同創設者であるJustin Bonsは、この緊急アップデートを強く批判し、XRPの分散性をめぐる議論は誤解を招くものだと主張しました:
Selling XRP to retail as "decentralized" is straight-up fraud! 🚩 XRP has been running closed-source code for the last two weeks Tomorrow, this code becomes mandatory & anyone who disagrees will get kicked off the chain! A permissioned node list means validators must obey: 🧵… pic.twitter.com/3nIcRiid8S — Justin Bons (@Justin_Bons) October 8, 2026
投稿の中でBonsは、ネットワークが必須アップデートを前に2週間にわたりクローズドソースのコードで稼働しており、許可制のノードリストが事実上バリデータに従順を求めていると主張しました。
さらなる懸念として、バイナリ配布は実行可能ファイルであるという点があります。基盤となるソースコードが迅速に公開されない場合、独立系開発者が変更内容を分析できる時間は限られます。
XRP Ledger Foundationは、この緊急パッチはコードで発見されたバグの深刻さを踏まえ、Foundation、RippleX、開発者、バリデータによって「共同で合意された」ものだと説明しました。同Foundationは、意思決定プロセスを一方的に指示した者はおらず、運用者は依然として好みのソフトウェアを自由に選択できると強調しています。
バリデータ運用者のXRP Kuwaitも緊急パッチ適用プロセスを支持し、協力は中央集権を意味しないと述べました:
Our Statement on xrpld 3.4.1 At XRP Kuwait, our journey has always been about infrastructure and purpose. Our purpose is decentralization. We pursue that purpose through independently operated infrastructure and responsible participation in the XRP Ledger. Following the… pic.twitter.com/Oo7qClwpgi — XRPKuwait (@XRPKuwait) October 11, 2026
この論争により、緊急パッチにおける透明性と説明責任が再び疑問視されることとなりました。
決済エンジンの整数オーバーフロー
緊急パの背景にあった脆弱性は、XRP Ledgerチームによる開示で詳述されました。脆弱性レポートによると、問題は2015年から存在していた決済エンジンの整数オーバーフローでした。整数オーバーフローは、計算結果がシステムが保持できる最大値を超え、はるかに小さい数値に折り返されるという、長く知られている種類のソフトウェアエラーです。このケースでは、固定された最大値を超える計算がより小さい結果を生み出しました。
攻撃者は、多額のXRPを引き換えに求める数百のオファーを送信することで、このバグを悪用できた可能性がありました。欠陥のある計算の後、攻撃者はその金額を受け取りつつ、買い手は本来必要な金額より少ない支払いで済むため、追加の使用可能なXRPが生じる恐れがありました。
ネットワークのルールはXRPの総供給量をローンチ時に1,000億トークンに固定しているため、追加の使用可能なXRPを生み出す経路はいずれも、資産の希少性を支える固定供給ルールという台帳の中核的な保証を損なうことになっていたでしょう。
この攻撃には特別に細工されたオファーが必要であり、通常の取引過程では発生し得ませんでした。パッチは、この計算エラーがネットワークの供給ルールを回避するために悪用されることを防ぐよう設計されました。
RippleX、セキュリティ施策を拡充
RippleXは、AIを活用した脆弱性検出、敵対的テスト、形式検証、外部セキュリティ専門家との連携を通じて、XRP Ledgerのセキュリティを強化する意向です。
これらの取り組みの目的には、コード内のバグ発見、可能な攻撃のテスト、悪用前に脆弱性を特定することが含まれます。RippleXは、この業務を検出された脆弱性の修正にとどまらず、コードシステム全体のセキュリティを高める取り組みとして位置付けています。
セキュリティと透明性のバランス
緊急修正は、意思決定プロセスの透明性を維持しながらブロックチェーンのセキュリティを保つことの難しさを浮き彫りにしました。潜在的な攻撃から守るための迅速な実装は不可欠ですが、ガバナンスプロセスやソースコードへのアクセスをめぐる課題も提起します。
開発者は、脆弱性の深刻さゆえに標準的な手順を省略する必要があったと主張し、一方でFoundationは、関係者間の調整がバリデータの独立性に影響を与えたわけではないと主張しました。
この出来事は、迅速な対応とネットワークの開放性を両立できる緊急時プロトコルの整備の必要性を示しています。
Source: Tron Weekly