XRP Ledgerの開発者は、攻撃者がネットワークの1000億枚というハードキャップを超えるXRPを無から生成することを可能にしていた重大なオーバーフローバグを公表した。この脆弱性は、台帳のコアサーバーソフトウェアであるxrpldのバージョン3.4.0以前に影響していた。9月に極秘で修正され、2026年10月9日に公表された。調査では、パブリックネットワークで悪用された証拠は見つかっていない。

バグの仕組み

脆弱性は、xrpldが支払額を集計する方法にあった。1回の支払いが分散型オーダーブック上の複数のオファーから流動性を引き出す際、ソフトウェアは64ビット整数で対象のXRPの合計を管理していた。この合計が整数で保持できる最大値を超えると、実際よりはるかに小さい値にラップアラウンドしていた。この種のオーバーフローエラーは、結果を格納する変数の固定サイズを算術処理が超えてしまうという古典的なソフトウェア欠陥のカテゴリであり、資金を扱うコードでレビュアーが最初に確認するリスクの一つである。

攻撃者はこの隙間を悪用して、存在しないXRPを支出できた可能性がある。膨張した残高が多数のアカウントに分散していたため、台帳の既存の安全確認は不整合を検出できず、帳簿上はバランス取れて見える一方で、実際の供給量が静かに膨らんでいた。

この攻撃の実行コストは驚くほど低かった。開示資料によると、悪用には数百のアカウントによる特別に細工されたオファーが必要で、準備金と手数料はわずか数百XRPで済み、その大半は回収可能だったという。1回のトランザクションで発行され得たXRPの量は、トークンの総供給量全体を超えていた可能性がある。

極秘修正、そして公開開示

脆弱性は2026年9月22日、研究者のCayden Liao氏によってXRPLバグバウンティプログラムを通じて報告された。Rippleの開発部門であるRippleXは問題を確認し、スタンドアロンサーバーで攻撃を再現して、超過分のXRPが後続のトランザクションで支出可能であることを検証した。

報告の3日後、2026年9月25日に緊急リリース xrpld 3.4.1 が出された。この修正は、台帳の通常の改正(アmendメント)プロセスも経由しなかった。通常、ネットワークのルール変更はバリデータの投票手続きを経て初めて有効になるが、このパッチは即座にデプロイされた。

公開開示は10月9日、修正版のリリースから約2週間後に続いた。チームは、このバグに関連して資金の損失、鍵の漏洩、コンセンサスの問題はなかったと報告している。この一連の手順は、攻撃に利用され得る情報が公開される前に運用者がアップグレードする猶予を与えるため、修正を先に公開し詳細を後に公表するソフトウェアセキュリティの標準的な慣行である「協調的脆弱性開示」に沿ったものだ。報告をもたらしたXRPLバグバウンティプログラムも同じ仕組みの一部であり、独立した研究者に脆弱性を非公開で届け出るよう報酬を支払うものである。

10年間潜在していた脆弱性

この欠陥は、支払いエンジンが初めて構築された2015年頃から存在していたとみられ、コードは潜在的なオーバーフローを抱えたまま長年にわたり支払いを処理してきたことになる。チェーンのネイティブ資産を膨張させ得るバグは稀だが、前例がないわけではない。2018年には、Bitcoin Coreの開発者が、同様に攻撃者がネットワークの発行ルール外でビットコインを生成することを可能にし得る欠陥緊急パッチをリリースしている。

XRPホルダーと台帳への意味

XRPホルダーにとって差し当たりの結論は安心できるものだ。バグが悪用された証拠はなく、トークン供給の完全性は維持されているとみられる。この一件は、ハードキャップは最終的にコードによって強制されるものであり、その信頼性はコードに依存するという教訓でもある。

しかし、改正プロセスを経由しないという決定は注目に値する。無制限のXRP発行につながる既知の経路をガバナンス投票を待たせることはできないが、通常の手順を省く緊急パッチはコア開発チームに大きな信頼を置くことになる。今回の場合、ネットワークのセキュリティはバリデータとノード運用者の迅速なアップグレードに依存していた。

依然としてxrpld 3.4.0以前を実行しているノード運用者が、このニュースの最も直接的な対象読者である。修正済みバージョン3.4.1は9月25日から入手可能であり、アップグレードしていない者は、供給を破壊し得ることが公表されたソフトウェアを実行し続けていることになる。

Source: CryptoBriefing