AIが発見したXRP Ledgerの欠陥、18.45兆XRPを発行できる経路が判明
Veria AIは、暗号資産の供給上限である1,000億XRPを大幅に超える、18.45兆XRPを発行可能にするXRP Ledgerの欠陥を発見したと、研究者らは述べている。
このエクスプロイトは、台帳の決済エンジンにおける不正な算術処理と、同じ誤りを繰り返す安全性チェックを組み合わせたものだった。細工された決済により、買い手にはほとんど請求せずに、数百の売り手アカウントへ残高を付与できる可能性があった。
RippleXはこのエクスプロイトを再現し、重大度をクリティカルに分類したうえで、2026年9月25日にxrpld 3.4.1をリリースした。公式開示によると、調査担当者は、公開ネットワーク上でこの脆弱性が悪用された証拠を確認していない。
この違いは重要だ。これは18兆XRPの窃盗ではなく、理論上の金額が実現可能な市場価値を持っていたわけでもない。XRPを特徴づける供給ルールに違反し得る、信頼に足る経路だった。
この事案は、AI支援型セキュリティをめぐるより大きな期待も試している。AIエージェントは、監査や従来型テストが見落としてきた10年前の欠陥を発見したように見える。しかし、人間の研究者は依然として結果を検証し、非公開での修正を調整し、バリデーターにアップグレードを促す必要があった。
XRP Ledgerの欠陥は公開前に修正された
当面の焦点は、約10年間到達可能な状態にあった脆弱性に対し、緊急対応が成功したことだ。
Veria Labsによると、同社はセキュリティエージェントを、XRP Ledgerで使われるオープンソースのサーバーソフトウェアrippledに向けた。同社は、自社システムが脆弱なコードを特定し、機能するエクスプロイトを開発し、ローカルネットワーク上でテストしたとしている。
同社の技術的な再構成では、AIによる最初の発見は9月21日だったとされる。Veriaによれば、同システムは翌日に動作する概念実証を生成した。
研究者のCayden Liaoは結果をレビューし、9月22日にXRPLのバグ報奨金プログラムを通じて報告した。RippleXのエンジニアは同日、スタンドアロンサーバーとテストフレームワーク内で再現した後、この問題を確認した。
確認は単なる帳簿上の差異の提示にとどまらなかった。RippleXは、新たに作成されたXRPが後続の決済で送金できることを確認し、出力が実際に使用可能であることを立証した。
開発者は9月23日に修正をマージし、2日後にrippled 3.4.1をリリースした。公開開示は、運用者が修正済みソフトウェアを導入する時間を確保した後の10月9日まで待たれた。
Veriaによると、9月25日時点で80％超のバリデーターがこのリリースを実行していた。公式XRPLアカウントも同様に、デフォルトのUnique Node List上のバリデーターの80％超が同日にアップグレードしたと報告している。
Unique Node List、すなわちUNLは、コンセンサスを評価する際にサーバーが信頼するバリデーターを特定する。これらのバリデーターによる迅速な導入は、古いノードが脆弱なトランザクションを受け入れ続けることで生じる危険を低減した。
この対応は、トランザクションの挙動を変更する通常の経路から外れるものだった。XRPLでは一般に、コンセンサスに影響する変更は、バリデーターが有効化前に検討するamendmentsを通じて導入される。
開発者は代わりに、オーバーフロー修正をサーバーリリースに直接組み込んだ。攻撃者が十分な数のバリデーターのアップグレード前に脆弱性をリバースエンジニアリングする可能性を抑えるため、関連するソース変更は一時的に非公開とされた。
この選択は短期間、保守担当者とバリデーター運用者に信頼を集中させた。同時に、公開されたamendmentプロセスが、即座に悪用可能なインフレバグの手引きになることも防いだ。
公式報告書によれば、XRPL Foundation、RippleX、参加バリデーターは、公開エクスプロイトを数週間にわたり利用可能な状態で残すよりも、非公開でのアップグレードの方が安全だと判断した。ネットワークが必要な安全閾値を超えた後、修正は公開された。
Veriaは10月8日、クリティカル区分の最大報奨金である25万ドルを受け取った。この金額は重大度評価を反映するものだが、測定済みの損失と混同すべきではない。
不正に発行されたXRPは確認されず、ユーザー資金の消失も報告されておらず、公開台帳上のトランザクションもこのエクスプロイトに結び付けられていない。緊急対応の対象は、コードが受け入れる内容であって、すでに確認された被害ではなかった。
この結果により、この出来事は過小評価されやすい。しかし、悪用が回避されたからといって、資産の固定供給という前提を無効にし得る欠陥の重要性が下がるわけではない。
XRP Ledgerの欠陥が使用可能なXRPを作り出し得た仕組み
このエクスプロイトが成立したのは、2つの通貨的な安全策がほぼ同じ方法で脆弱な計算を行っていたためだ。
最初の欠陥は、XRP Ledgerに組み込まれた分散型取引所のオファー処理において、決済エンジンに現れた。オファーは、アカウントが台帳のオーダーブックを通じてXRPまたは発行資産を交換することを可能にする。
攻撃者はまず、多数の管理下アカウントを作成し、価値のないトークンを発行する。これらのアカウントは、そのトークンに対して極めて大きなXRP額を要求する数百の人為的なオファーを出すことになる。
Veriaの概念実証では256件のオファーが使われた。各オファーは2^56 dropsをわずかに上回る額を要求しており、1 dropはXRPの100万分の1に相当する。
次に攻撃者は、オファー群全体を消費するよう設計された単一の決済を送信する。決済エンジンは買い手に請求する前に、各オファーに関連するXRP額を合算しなければならない。
この合計は、計算に使われた符号なし64ビット整数の容量を超えていた。整数オーバーフローは、値が許容される最大値を超え、はるかに小さな数値に折り返すときに発生する。
このケースでは、合計が2^64 dropsを超えた。各オファーの所有者は全額を受け取る一方で、オーバーフローにより買い手への合算請求額はわずか256 dropsに見える可能性があった。
これは誤った交換レートより深刻な問題だった。残高に付与されたXRPは、どの送信元アカウントからも供給されていなかった。
その結果は、送信元からの引き落としとトランザクション手数料を考慮する前で、約18,446,744,073,709 XRPとなった。Veriaは、256アカウントにまたがる使用可能な出力を約18.45兆XRPと要約している。
この分散は不可欠だった。XRPLは単一アカウントが保有できるXRPに上限を設けているが、各受取人はその上限を下回る状態にとどまった。
したがって、この攻撃は新規XRPを多数のアカウントに分割することで、1つの安全策を回避した。研究者らによると、付与されたXRPはその後、通常の決済を通じて移動させたり、取引所へ送ったりできた可能性がある。
XRPLには、まさにこの結果を防ぐことを目的としたinvariantもあった。invariantとは、台帳が変更を受け入れる前に真であり続けなければならない、トランザクション後の安全条件である。
XRPNotCreated invariantは、トランザクション全体のXRP残高の純変化を計算する。この計算は、手数料による焼却額を超えるXRPがトランザクションによって作成されたことを示す結果を拒否するはずだった。
しかし、この計算も同じオーバーフローに脆弱な算術処理を使用していた。純変化は通常の手数料焼却に似た値になるまで折り返され、トランザクションの通過を許してしまった。
実質的に、決済エンジンは買い手の支払額を誤って計算した。その後、一見独立した供給量チェックが同じ数学的な失敗を繰り返し、誤った結果を承認した。
この共通した失敗は、重要な設計上の教訓である。バックアップ制御は、監視対象のコンポーネントと同じデータ型、算術挙動、または前提に依存する場合、保護としての効果が限定的になる。
この攻撃は、一般的なトレーダーが偶然に引き起こせるものではなかった。意図的に設定された数百のオファーと、それらをまとめて消費するよう設計された決済が必要だった。
また、アカウントとオファーのリザーブ、ならびにトランザクション手数料のために一定量のXRPも必要だった。脆弱性報告書は必要額を数百XRPと見積もっており、リザーブの大部分は後から回収可能としている。
攻撃者はバリデーターを支配する必要はなかった。準備と署名が完了すれば、エクスプロイトトランザクションは、ほかは通常の決済としてネットワークに入ることになる。
この攻撃は繰り返すこともできた。管理下アカウントの追加グループが同じ構成を再現すれば、さらに18.45兆XRPのバッチを作成できる可能性があった。
修正では、オファー合計コードにオーバーフローチェックが導入された。許容範囲を超える合計は、小さな請求額へ折り返されるのではなく、失敗するようになった。
開発者はまた、供給量invariantで使われるアキュムレーターの幅を拡張した。ほかの残高合計処理経路にも関連する強化が施され、同様の算術処理の共通障害が再び発生する可能性を減らしている。
固定供給により潜在的な被害はシステム全体に及んだ
実際のリスクは18.45兆XRPという非現実的な額面価値ではなく、すでに流通するすべての正当なXRPの信頼性にあった。
XRPは総供給量1,000億トークンで始まった。マイニングやステーキングで生み出されるものではなく、通常のトランザクション手数料によって時間とともに少量ずつ焼却される。
この設計は、ユーザーに単純な通貨的期待を与える。トランザクションはXRPを再分配できても、総供給量を増やしてはならない。
XRP Ledgerの欠陥は、このルールを会計レイヤーで破った。悪用されていれば、新たに作成されたXRPを、他と異なる残高として明示的に区別することなく通常のアカウントへ配置できた可能性がある。
報告された18.45兆XRPの出力は、当初の供給量の約184倍だった。しかし、その量に市場価格を掛け合わせても、経済的被害を示す数値としては誤解を招く。
攻撃者は、攻撃前の価格で数兆XRPを売却できなかっただろう。利用可能な流動性は消失し、取引所は取引を停止する可能性があり、大半のトークンが買い手に届くはるか前に価格は反応する。
より意味のある基準は、Veriaが脆弱性を評価した時点でのXRPの時価総額約940億ドルだった。これは、根底にある希少性の前提が圧力にさらされた価値を表していた。
この数値でさえ、損失額が保証されるという意味ではない。時価総額はネットワーク内に保管された現金と同じではなく、保有者ごとに結果も異なる。
システミックリスクは信頼から生じた。不正な発行は既存保有者を希薄化させ、取引所の流動性を圧迫し、アプリケーションを混乱させ、台帳の会計上の保証に疑問を投げかける可能性があった。
機関投資家や事業者も運用上の不確実性に直面する。取引所は影響を受けた入金を特定する必要が生じる可能性があり、決済事業者は決済を停止し、カストディアンは調査中に出金を制限する可能性がある。
こうした対応は、攻撃者が見出しの金額のごく一部しか取得しなかったとしても、正当なユーザーに損害を与え得る。供給量の障害は、直接関係するアカウントを超えて広がる。
これは非公開リリースを説明する一助となる。保守担当者は、プロトコルだけでなく、取引所、バリデーター、インフラ提供者が対応するための時間も守っていた。
この欠陥は、決済エンジンが書かれた2015年以降、存在していた可能性が高い。Veriaの分析によると、供給量invariantにおける第2の弱点は2017年にさかのぼる。
この時系列は、長期間にわたる稼働だけで安全性が証明されるという考えに疑問を投げかける。ソフトウェアは数十億件のトランザクションを処理しても、通常の活動では決して実行されないエクスプロイト経路を残し続けることがある。
Rippleは3月、XRPLが2012年以降、1億を超えるレジャーと30億件のトランザクションを処理してきたと述べた。これらの数値は広範な利用を示すが、あり得るすべての算術状態を網羅するものではない。
ここで重要だったのは、まれな入力だった。正当なXRP供給量はその閾値を大きく下回っていたため、通常の決済ではオーバーフローに必要な値に近づくことはできなかった。
攻撃者は、多数のオファーにまたがって極端な注文板の値を捏造する必要があった。もっともらしい経済行動を前提とする従来型のテストでは、その組み合わせを検証していなかった可能性がある。
監査もリスクを排除できなかった。Veriaによれば、コードベースは2024年以降、確立された報奨金プログラムと並行して、十数回を超える監査または監査コンテストを受けていた。
これは監査が杜撰だったことを意味しない。監査には時間、対象範囲、インセンティブ上の制約があり、まれな相互作用は個別のコンポーネント間に隠れたままとなり得る。
教訓は、より限定的でありながら実用的だ。成熟した金融コードには、通常のユーザー行動に似たシナリオだけでなく、機械の限界に挑むテストが必要である。
AIセキュリティがバグを発見、人間が封じ込めた
この発見はAI支援型セキュリティを裏付ける一方、対応は自律スキャンがプロトコル防御の一層にすぎない理由を示している。
Veriaは、発見とエクスプロイトの構築の両方を自社のAIセキュリティエージェントによるものだとしている。同社によると、このシステムはrippledを分析し、2つの算術上の弱点を結び付け、動作するローカルの概念実証を構築した。
この説明が重要なのは、この脆弱性がコンポーネントをまたぐ推論を必要としたためだ。支払い処理のオーバーフローだけを見つけても、供給量の不変条件が取引を拒否すれば成功は保証されない。
このエージェントは、不変条件側でも同じオーバーフローが繰り返されることを認識したとされる。そのうえで、単一の取引内で両方の失敗を引き起こす入力を設計した。
Veriaの主張には、意味のある外部的な裏付けがある。RippleXは独自にエクスプロイトを再現し、新たに生成されたXRPが支出可能であることを確認したうえで、報告の深刻度を「major」から「critical」へ引き上げた。
XRPLの公式開示は、エージェントの自律性を完全に評価したものではない。報告と技術的結果は確認しているが、発見にどれほど人間の指示が関わったかを独自に測定してはいない。
AIセキュリティ製品を評価する際、この隔たりは重要だ。成功した発見には、自動コード分析、人間が作成したプロンプト、反復的なレビュー、手作業によるエクスプロイト検証が、さまざまな比率で関与し得る。
それでもこの事案は、ベンチマークのスコア以上の証拠を提供している。確認済みの重大な脆弱性、プロダクションリリース、そして最高額の報奨金支払いにつながったからだ。
Rippleは2026年3月、より広範なAIセキュリティプログラムをすでに発表していた。このプログラムはAI支援テストに加え、専任のレッドチーム、ファジング、形式検証、より厳格なamendmentレビューを組み合わせた。
ファズテストは、予期しない入力や不正な形式の入力をソフトウェアに与え、クラッシュや不正な状態を明らかにする。形式検証は、ソフトウェアが定義された性質を満たすかを検証するために数学的手法を用いる。
これらの手法は異なる失敗モードに対処する。AIはコードを検査して攻撃経路を提案でき、ファザーは入力空間を探索でき、形式手法は重要な不変条件を検証できる。
人間のエンジニアは、発見が到達可能か、その影響が実在するか、合意形成を損なわずに修正する方法は何かをなお判断する。また、分散したオペレーター基盤全体で開示も管理する。
XRP Ledgerの対応は、この役割分担を明確に示している。エージェントが経路を見つけ、Liaoがレビューし、RippleXが管理された環境でエクスプロイトを再現した。
その後、開発者は複数の算術処理経路を変更した。バリデーターの運用者はリリースを導入し、メンテナーは詳細を開示する前に導入状況を監視した。
単一の参加者が結果全体を支配したわけではない。このシステムは、民間のセキュリティ企業、オープンソース開発者、財団、RippleX、独立した運用者の協力に依存していた。
複数の当事者が発見内容を検証したという点で、この協調は強みである。一方で、精査に値するガバナンス上の依存関係でもある。
緊急パッチは、ソースコードレベルの説明が公開される前に配布された。バリデーターは、通常の変更で得られる透明性を受けられないまま、リリースを信頼するか判断する必要があった。
代替案にも固有の危険があった。広範な導入前に正確なオーバーフローの仕組みを公開すれば、未パッチのすべてのバリデーターに対する実行可能な攻撃経路を攻撃者に与えることになる。
これはAIと人間の監査の単純な競争ではなく、中心的なトレードオフである。発見の高速化は、高速で信頼でき、慎重に統治された対応手順の価値を高める。
防御側が古いコードを検査するために役立つ同じツールは、攻撃者が同種のミスを探す助けにもなり得る。RippleXのエンジニア、Mayukha Vadariは開示文書で、AIが脆弱性の発見と悪用をめぐる時間軸を変えると警告した。
したがって、成熟したプログラムに必要なのは、より優れたスキャナーだけではない。訓練された非公開開示手順、明確な深刻度基準、バリデーターとの通信チャネル、測定可能なアップグレード準備態勢も必要となる。
XRP Ledgerの欠陥が証明していないこと
確認されたエクスプロイトは深刻だったが、いくつかの見出し的な解釈は入手可能な証拠を超えている。
第一に、18.45兆XRPが公開台帳に流入したという証拠はない。研究者たちは脆弱性の検証中、管理された環境で出力を作成した。
第二に、Veriaが報告する前に攻撃者がこの経路を知っていたと確立した情報源はない。脆弱なコードの存続年数は露出期間を示すが、敵対者による認知を確認するものではない。
第三に、危険にさらされたとされる940億ドルは、予測損失として扱うべきではない。これは希少性の保証が潜在的な損害に直面した市場を表している。
第四に、この事案はAIシステムが研究の全段階を独力で完了したことを示すものではない。Veriaはエージェントの役割について最も詳細な説明を提示した一方、レビューと開示は人間が行った。
これらの留保は、軽視する意味で発見を理論上のものにするわけではない。RippleXは取引を再現し、後続の支払いによって新しいXRPを使用できることを確認した。
脆弱性はプロダクションコードにも到達していた。同じ3.4.1リリースで修正された別のBatch取引の問題とは異なり、これは有効化前に捕捉された提案機能ではなかった。
これらの事案を混同すると、混乱が生じる。Batchの欠陥は、ラッパーの検証とサーバーバージョン間での不一致の可能性に関するものだった。
このBatch amendmentはメインネットワークでは有効化されていなかった。バリデーターはamendment投票によって修正を扱い、修正版は10月9日に有効化された。
XRPのオーバーフローは異なる経路をたどった。既存の支払いエンジンの挙動に影響し、ノードがバージョン3.4.1を導入した時点で直ちに修正された。
したがって、リリース記録には、露出とガバナンスの履歴が異なる2件のセキュリティ修正が含まれている。主張される新規発行経路を生み出したのは、支払い処理のオーバーフローだけだった。
別の不確実性は、過去の検出に関するものだ。XRPLは公開ネットワーク上で悪用の証拠を発見していないとしているが、読者は「証拠がない」ことと、不在の絶対的な証明を区別すべきである。
このエクスプロイトを使う攻撃者は、異常な残高変動と注文板の活動を生み出すことになる。特に数百件の人為的なオファーが必要だったことを考えると、こうした痕跡は遡及的な分析に役立つはずだ。
しかし、公開開示は完全なフォレンジック手法や、独立監査された台帳履歴の検索を提示していない。その結論は、依然としてメンテナーが報告した発見にとどまる。
ネットワークの迅速なアップグレードも、継続的な検証に値する。default-UNLバリデーターで80％超の導入率は当面の露出を低減したが、他のノードやインフラ提供者は異なるスケジュールに従う。
古いソフトウェアを、開示文だけで安全にすることはできない。rippled 3.4.0以前を運用する事業者には、アップグレードの責任が残る。
最後に、この出来事はAIがブロックチェーン監査を完全なものにしたことを示していない。成熟したコードベースで、AI支援プロセスの一つが重要なバグを一つ見つけたことを示すにとどまる。
次の検証点は再現性だ。セキュリティチームには、同様のシステムが、弱い報告でメンテナーを圧倒することなく、多様で未知の脆弱性を発見できるという証拠が必要である。
また、敵対的な利用も評価する必要がある。防御側の発見高速化は、修正と展開が悪意ある再現を上回れる場合にのみ価値を持つ。
セキュリティモデルが改善したかを示す3つの指標
次の段階は、コード、バリデーターの挙動、独立して再現可能なセキュリティ上の成果を通じて判断されるべきだ。
第一の指標は、rippled 3.4.1以降の継続的な導入である。重大なオーバーフローの修正はソフトウェアの導入時に適用されるため、旧式ノードは依然として最も明確に回避可能なリスクとなる。
公開バリデーターのテレメトリーでは、脆弱なバージョンが重要な合意形成の役割から消えていくことが示されるべきだ。導入が遅ければ、XRPLが緊急時に協調できるという主張は弱まる。
第二の指標は、この特定のパッチを超えた金融上の不変条件に関する技術レビューだ。失敗した供給量チェックは、監視対象であるはずのコンポーネントと算術的な挙動を共有していた。
開発者は、より幅の広いアキュムレーターと明示的なオーバーフロー処理を使い、他の合計値、変換、残高の経路もテストすべきである。別の一般的な保証よりも、独立したレビューのほうが信頼を強化する。
第三の指標は、AI支援テストが責任ある開示のもとで再現可能な発見を生むという証拠だ。確認済みの脆弱性、低い誤検知率、明確な人間の監督は、Veriaのより広範な主張を支持することになる。
扇情的だが未検証の報告が相次げば、その主張は弱まる。また、実行可能な対応策になるまでに、大規模かつ非公開の人間による再構築を要する発見も同様である。
この事案はすでにセキュリティの基準線を変えた。長年の運用、過去の監査、供給量が減少する設計は、機械の限界に起因するエラーがXRPの中核的な金融ルールを脅かすことを防げなかった。
同時に、公開エクスプロイトが現れる前に対応は機能した。研究者が問題を報告し、エンジニアが再現し、バリデーターは数日のうちに緊急修正を導入した。
開発者とインフラ運用者は今、自らの安全チェックが、監督対象のシステムとは異なる形で失敗するかを問うべきだ。同じ前提を重ねただけでは、真の多層防御にはならない。
XRP Ledgerの欠陥を追う読者にとって最も有用な行動は、バージョンの導入状況、独立したコードレビュー、今後の報奨金開示を注視することだ。これらの指標は、これが孤立した修正だったのか、より強固なセキュリティモデルの始まりなのかを明らかにする。
