XRP Ledgerのオーバーフローバグにより、1回のトランザクションで既存の総供給量を超えるXRPを発行できた可能性がありました。Rippleの開発部門であるRippleXとXRPL Foundationは、2015年頃から存在していたとみられるこの欠陥を2026年9月下旬に開示・修正しました。悪用された証拠はありません。

破られかねなかった供給上限

XRP LedgerはXRPの基盤となる分散型ブロックチェーンです。組み込みのオーダーブックを通じて送金と取引を処理し、ペイメントエンジンはそこに置かれたオファーと支払いを照合するコンポーネントです。総供給量はローンチ時点で1,000億XRPでした。マイニングやインフレは存在せず、バーンされたトランザクション手数料のみが供給量をわずかに減少させます。この固定された上限は、「いかなるトランザクションもXRPを生成してはならない」というレジャーレベルの不変条件に依存しており、まさにこの保証こそがオーバーフローバグによって脅かされました。

xrpldサーバーソフトウェアのバージョン3.4.1は9月25日にリリースされ、開示レポートはその14日後に公表されました。それに先立ち、Default Unique Node List（UNL）上のバリデータの80%超がすでにアップグレード済みでした。このバグはxrpld 3.4.0およびそれ以前のすべてのバージョンに影響していました。バグを報告したVeria Labsの試算では、1回の悪用トランザクションで約18兆XRPが生成された可能性があるとしています。

オーバーフローがどのようにXRPを無から生成できたか

ペイメントエンジンは、オーダーブック内で払いが消費したすべてのオファーの金額を合計する際、オーバーフローチェックのない64ビット整数加算を使用していました。合計が十分に大きくなると、値は小さな数値に折り返されました。各オファーの所有者は全額の支払いを受け取り、一方でレジャーは買い手に折り返された金額のみを引き落としていたはずです。その差額が新しいXRPとして出現することになります。

本来、2つの安全装置がこれを防ぐはずでした。しかし、「いかなるトランザクションもXRPを生成してはならない」とする不変条件自体が同じオーバーフローする算術を使用しており、さらにアカウントごとの残高チェックは総供給量を超えた場合にのみ発動する仕組みでした。そのため、生成されたXRPは多くのアカウントに分散して着金していたことになります。

攻撃では、攻撃者は数百のアカウントを設定し、それぞれが少量のトークンと引き換えに膨大な量のXRPのオファーを出します。1回の支払いですべてのオファーを消費でき、関与するすべてのアカウントを攻撃者自身のものにできます。コストは回収可能なリザーブとして数百XRPと手数料のみで済むため、攻撃者に大きな初期残高は不要でした。

とはいえ、オーバーフローが偶然に引き起こされることはありませんでした。通常の支払いでは必要な合計額に達することはなく、実際のトレーダーがそのような価格をつけることはないためです。レポートはまた、いずれのパブリックネットワークでも悪用の証拠は確認されていないと述べています。Veria LabsのCayden Liao氏は、この悪用がそれぞれ単独では低重要度と評価される2つのバグを連結したものだと述べ、これが早期に発見されなかった理由だと推測しています。

バグ報奨金プログラムを通じた報告

Cayden Liao氏とVeria AIは9月22日に、ネットワークのバグ報奨金プログラムを通じてこの脆弱性を報告し、当初「Major」と評価しました。RippleXは攻撃を再現して評価を「critical」に引き上げ、その後修正を非公開で開発しました。1日後、修正はバージョン3.4.1のリリースブランチに取り込まれ、リリース候補版3.4.1-rc1として出荷されました。以降、ペイメントエンジンはオファー金額を合計する際にオーバーフローをチェックし、オーバーフローが発生した場合はその支払い部分が失敗します。

発見の経緯について詳細を提供しているのはVeria Labsのみです。同社によると、AIエージェントがバグを発見し、実際に機能するエクスプロイトを構築したといいます。一方、開示レポートには報告者としてLiao氏とVeria AIのみが記載されています。約18兆XRPという数字もLiao氏の試算によるもので、総供給量の184倍に相当します。Veriaは上限額の25万米ドルの報奨金を受け取ったと述べていますが、レポートは金額を明記していません。このようなプログラムは、責ある開示への報酬として主要ブロックチェーンネットワーク全体で標準的な仕組みです。

レポートによると、このバグは2015年のペイメントエンジン開発時からコードに存在していた可能性が高く、約10年間気づかれないままでした。この事例は、欠陥をより速く露呈させるAI支援による脆弱性探索というより広いトレンドに合致しており、RippleXの開発者たちも同様の見解を示しています。

アメンドメントを経ない修正

XRP Ledgerのルール変更は通常、いわゆるアメンドメントを通じて行われ、2週間の期間にわたり80%超の信頼されたバリデータの支持を必要とします。しかし今回の修正は、各サーバーがアップグレードするにつれ即座に発効しました。レポートはこれを、アメンドメント制度の導入以降、トランザクション処理における初の意図的なこの種の変更としています。リリース日の時点で、Default UNLバリデータの80%超がすでにバージョン3.4.1以降を実行していました。

RippleXはこの決定を時間的猶予のなさによって正当化しています。通常のオープンソースリリースでは、修正が発効する数週間前に攻撃者へバグの所在を示すことになったためです。XRPL Foundationのメンバー、RippleX、およびXRPLバリデータは事前に協議し、このリスクが迅速な対応を正当化すると合意しました。彼らの見解では、この措置が正当化されるのは最も深刻なバグのみであり、その他の変更は引き続きアメンドメントを通じて行われます。

「AIは状況を変えました。重大なバグパッチを日常的な公開リリースプロセスに忍び込ませることはできません。即座に発見され、リバースエンジニアリングされてしまいます。」 — Mayukha Vadari、RippleX

一方、チームは3.4.1のソースコードをGitHubで公開したのは、バイナリから約2週間後でした。Cyber Capitalの創業者Justin Bons氏はX上で、XRPが2週間クローズドソースのコードで運用されていたことを批判しました。開示を遅らせるサイレントパッチはソフトウェアセキュリティでは一般的な手法ですが、ガバナンス志向の分散型ネットワークでは依然として議論を呼ぶ手法です。

バッチ機能の2つ目のバグ

バージョン3.4.1では、バッチ機能（XLS-56）の2つ目のバグも修正されました。これはxrpld 3.3.0と3.4.0に影響していました。バッチは最大8つの内部トランザクションを保持でき、仕様ではそれぞれがRawTransactionというフィールドに格納される必要がありますが、サーバーはこれを検証していませんでした。その結果、恒久的に不正な形式となったレジャーエリが発生し、インデクサー、エクスプローラー、SDKを混乱させる可能性がありました。

より深刻だったのはコンセンサスに関わる変種です。ソフトウェアバージョンが混在している環境では、細工されたトランザクションが1回のトランザクション手数料のコストでバリデーションを停止させ得ましたが、攻撃者がオンチェーンで得るものは何もありませんでした。ただし、BatchV1_1がメインネットで有効化されていなかったため、メインネットへの影響はありませんでした。

この発見はSherlock Attackathonで初めて表面化し、当初は「low」と評価されていました。9月18日、XRPL FoundationのDenis Angell氏は、以前の修正が不完全だったことを確認しました。4日後、Mayukha Vadari氏がコンセンサスリスクを特定しました。その後、Rippleとバリデータ運営者のVetはBatchV1_1への投票を取り消しました。このアメンドメントは元々9月29日に発効予定でした。一方リリースではfixBatchV1_2の2週間の発効プロセスが開始され、10月9日以降、両アメンドメントはメインネットで有効になっています。

強化されるレビュープロセス

これを受け、RippleXはレビュープロセスを変更しています。今後、修正済みとされたすべてのセキュリティ脆弱性は、リリース候補版に対する新たなテストを経ることになります。テストが元のバグを再現し、候補版がパスした場合にのみ修正完了とされます。レポートが列挙する追加の安全装置には、公開のアタックソンやAI支援によるレッドチーミングが含まれます。

旧バージョンは「amendment-blocked」とみなされ、同期を維持できなくなります。そのため運営者はサーバーをxrpld 3.4.1以降へアップグレードする必要があります。次に重大な脆弱性が発見された際に、この確保された迅速な経路と通常のアメンドメントのどちらが用いられるかは、レポートが述べるようにこの手法が例外であり続けるかを示すことになるでしょう。

出典：XRPL vulnerability disclosure report via Crypto Valley Journal