XRPL脆弱性開示レポート: Batchアメンドメントにおける不正な内部トランザクション実行

本記事は2026年2月26日投稿のXRPL公式ブログ"Vulnerability Disclosure Report: XRPL Batch Amendment – Unauthorized Inner Transaction Execution“の和訳です。

By XRPL Labs

この脆弱性開示レポートには、2026年2月19日に報告された XRPL Batchアメンドメントのバグに関する技術的詳細が記載されています。

報告日: 2026年2月19日

影響を受けるバージョン: rippled 3.1.0(Batchアメンドメントが有効化されている場合)

脆弱性の概要

2026年2月19日、Pranamya KeshkamatさんとCantina AIは、XRPLのBatchアメンドメントの署名検証ロジックにおける重大な論理的欠陥を発見しました。 このバグにより、攻撃者は被害者アカウントの秘密鍵を持たずに、任意の被害者アカウントを代理して内部トランザクションを実行できてしまい、その結果として無断での資金移動やレジャーステートの改変が可能となる状態でした。 当該アメンドメントは投票フェーズにあり、メインネットではまだ有効化されていなかったため、実際の資金が危険にさらされたわけではありません。 なお、このバグが報告される前から、Batchアメンドメントは、fixBatchInnerSigsアメンドメントを先に有効化する必要があるという慎重な判断のもと、無効化されていました。

UNLバリデーターには、当該アメンドメントへの「No」投票を呼びかける案内がただちに行われました。 緊急リリースのrippled 3.1.1では、BatchおよびfixBatchInnerSigsの両方をサポート対象外として扱うことで、有効化を防いでいます。 修正版の置き換えとなるBatchV1_1はすでに実装済みで、現在レビュー中です。リリース日はまだ決まっていません。

影響

もし本バグが捕捉される前にBatchアメンドメントが有効化されていた場合、攻撃者は以下のような行為を行えた可能性があります。

• 資金の窃取: 被害者アカウントの秘密鍵にアクセスすることなく、内部のPaymentトランザクションを実行して、被害者アカウントの残高をリザーブまで引き出す。
• レジャーステートの改変: 被害者アカウントから、許可なくAccountSet、TrustSet、場合によってはAccountDeleteトランザクションを送信する。
• エコシステムの不安定化: 大規模な悪用が成功した場合、XRPLに対する信頼が大きく損なわれ、より広いエコシステムにも重大な混乱をもたらした可能性がある。

技術的詳細

発見の経緯

Pranamya Keshkamatさんと、Cantina AIが開発した自律型AIセキュリティツールApexが、rippledコードベースの静的解析を通じて本脆弱性を特定し、責任ある開示レポートを提出してくれました。 Rippleのエンジニアリングチームはただちに独立した概念実証 (PoC) と完全なユニットテストでの再現により、報告内容を検証しました。 修正対応は同日の夜から開始されました。

根本原因

Batchアメンドメントが有効化されている場合、バッチ内の内部トランザクションは設計上、署名されません。 認可は、外側のバッチに紐づく署名者リスト(batch signers)によって行われる仕組みになっています。 これらの署名者を検証する関数のループ処理に重大なバグがありました。 レジャー上にまだ存在しないアカウントで、かつ署名鍵が自分自身のアカウントと一致している(これは新規アカウントでよくあるケースです)署名者に遭遇したとき、関数は即座に「成功」と判断してその場で処理を抜けてしまい、残りすべての署名者の検証をまったく行わない状態になっていたのです。

攻撃経路

1. 攻撃者は、3つの内部トランザクションを含むバッチトランザクションを構築します。1つ目は攻撃者が管理する新規アカウント(アカウントB)を作成するトランザクション、2つ目はその新規アカウントからの簡単なトランザクション(これによりアカウントBが必須署名者となります)、3つ目は被害者アカウントから攻撃者への支払いです。
2. 攻撃者は、バッチ署名者のエントリを2つ用意します。1つ目はアカウントB自身の鍵で署名された正当なエントリ、2つ目は被害者アカウントを認可していると偽装しつつ、攻撃者自身の鍵で署名された不正なエントリです。
3. アカウントBは検証時点ではまだ存在していないため、署名者チェックは1つ目のエントリで「成功」として終了し、2つ目のエントリの検証は行われません。
4. その結果、被害者の鍵が一切関与しないまま、被害者からの支払いが実行されてしまいます。

修正対応

• UNLバリデーターに連絡し、Batchアメンドメントへの「No」投票を呼びかけました。
• rippled 3.1.1を2026年2月23日に公開しました。 このリリースでは、BatchおよびfixBatchInnerSigsをサポート対象外として扱うことで、これらがバリデーターの投票を受けたりネットワーク上で有効化されたりすることを防いでいます。 これは即時の緩和措置であり、根本的なロジック修正そのものは含まれていません。
• 早期exitの除去・追加の認可ガード・署名チェック範囲の厳格化を含む完全なロジック修正はすでに実装されており、BatchV1_1アメンドメントとしてリリースされる前に、入念なレビュープロセスを経ているところです。 変更内容のセンシティブさを踏まえ、リリースのタイムラインは設定されていません。

セキュリティ強化のロードマップ

• レビュープロセスの標準ステップとして、AI支援によるコード監査パイプラインを追加する。
• 静的解析の対象範囲を拡張し、署名者を反復処理するループ内での早期成功returnを検出できるようにする。
• 検証時点でまだ存在しないアカウントについて期待される挙動を、コード上に明示的なコメントおよびinvariantアサーションとして文書化する。
• コードベース内で、ループ内に早期成功returnが存在する他のすべての箇所を見直し、同様のパターンが残っていないことを確認する。

再現手順

1. 攻撃者が管理する2つのアカウントに資金を入れ、3つ目はファンドされていない状態のままにします。 ファンドされていないアカウントを生成する支払いトランザクション、そのアカウントからの簡単なトランザクション、そして被害者アカウントから攻撃者への支払いを含むバッチトランザクションを構築します。
2. ファンドされていないアカウントの署名者エントリには、そのアカウント自身のマスターキーで署名し、もう1つの署名者エントリには、被害者アカウントを認可していると偽装しつつ、攻撃者自身の鍵で署名します。
3. 構築したバッチトランザクションをネットワークへ送信します。

修正前の挙動:

• バッチトランザクションは成功します。
• 被害者の鍵が使われていないにもかかわらず、被害者アカウントの残高が支払い金額の分だけ減少します。
• 攻撃者の残高は、純額(バッチ手数料を差し引いた額)の分だけ増加します。

修正後の想定される挙動:

• バッチトランザクションは認可エラーで拒否されます。
• いずれのアカウントの残高も変動しません。

利用可能な修正/パッチ

rippled 3.1.1はすでに公開されています。 修正版のBatchV1_1アメンドメントは、レビュー完了後、今後のリリースに含まれる予定です。リリース日は未定です。

謝辞

責任ある詳細な開示を行ってくださったPranamya KeshkamatさんとCantina AI(自律型セキュリティツールApexが本脆弱性を特定)に感謝いたします。 詳しいバグレポート、概念実証(PoC)、そして修正対応プロセス全体を通じた建設的な協力は、本当に貴重なものでした。

該当アメンドメントに対して迅速に反対投票を行ってくれたUNLバリデーターの皆さん、緊急レビューと緊急リリースに対応してくれたRippleおよびXRPLファウンデーションのエンジニアリングチームの皆さん、そしてXRP Ledgerを安全に保つために尽力されている、より広いバリデーター・開発者・コントリビューターのコミュニティの皆さんにも感謝いたします。

参考資料

• rippled 3.1.1 リリース
• X上のコミュニティ投稿

お問い合わせ

セキュリティに関する問題のご報告は、security@ripple.comまでご連絡ください。

インシデント対応タイムライン