XRPL脆弱性開示レポート：Permission Delegationにおける不正な手数料課金問題

本記事は2025年9月29日投稿のXRPL公式ブログ"Vulnerability Disclosure Report: XRPL Permission Delegation“の和訳です。

この脆弱性開示レポートには、2025年9月15日に報告された Permission Delegation アメンドメントに関する技術的詳細が記載されています。

報告日: 2025年9月15日

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

脆弱性の概要

2025年9月15日、XRPLの Permission Delegation 機能に関するバグが特定されました。 このバグにより、あるアカウントから他の任意のアカウントに対してトランザクション手数料を課金できてしまい、悪用された場合には対象アカウントのXRP残高を抜き取られる恐れがありました。

この機能はメインネットでは有効化されていませんでした。 直ちに、該当アメンドメントへの反対投票を呼びかける対応が取られ、必要な修正を含む新しいアメンドメントを今後のリリースで導入するための後続提案も進められています。

影響

このバグは、アメンドメントの投票フェーズ中に本番環境ではない(non-production)環境で特定されたものです。 該当アメンドメントはメインネットではまだ有効化されていませんでした。

発見後、UNLバリデーターは案内に従って「No」への投票を始め、有効化を阻止しました。 現在のfeaturePermissionDelegationアメンドメントは rippled 2.6.1 以降で無効化される予定であり、これに代わって修正版featurePermissionDelegationV1_1が導入されます。 これにより、本機能の正式リリースのタイムラインは多少後ろ倒しになる可能性があります。

技術的詳細

発見の経緯

2025年9月15日、コミュニティメンバーの tequ さんから、devnet 上でのテスト中に発見したPermission Delegationアメンドメントのバグが報告されました。 Rippleのエンジニアリングチームは速やかに調査を行い、問題を確認しました。 これを受けて、修正対応の開始とXRPLバリデーターコミュニティへの通知のための対応がただちに取られました。

根本原因

XRPLのPermission Delegation機能は、あるアカウントが他のアカウントに対して、自分の代わりに特定のトランザクションを送信する権限など、特定の権限を委譲できるようにするものです。 こうした委譲トランザクションでは、本来、トランザクション手数料が委譲先のアカウントから引き落とされるよう設計されています。

ところが、ある条件下では、トランザクションが正しく署名されていない場合でもこの手数料が引き落とされてしまうため、悪意のあるアクターがこの仕組みを使って他人のアカウントからXRPを抜き取れる可能性がありました。

この挙動が発生するのは、委譲先のアカウントが必要な権限を持っておらず、かつトランザクションが(rippledを介さず)オフラインで署名されている場合に限られます。 このような条件下では、悪意のあるアクターが本仕組みを悪用し、不正に手数料を課金して、委譲先アカウントからXRPを抜き取れてしまう状態でした。

検証プロセスにおいては、署名検証よりも先に権限の確認が行われます。 委譲先アカウントが必要な権限を持っていない場合、署名のチェックが行われる前にtecNO_DELEGATE_PERMISSIONエラーが返されます。tec系のエラーはトランザクション手数料が課されるよう設計されているため、悪意のあるアカウントは、高額な手数料を設定しつつ、署名自体は有効でも権限のないトランザクションを送信できてしまいます。 被害者アカウントが必要な権限を持っていない限り、トランザクションは署名検証の前にtecNO_DELEGATE_PERMISSIONで失敗し、その結果として手数料が被害者アカウントから引き落とされてしまうのです。

この問題は2つの要因に起因します。 以下のいずれかの条件を満たすようにすれば、本脆弱性は防げます。

• エラーの種別:
  • tec系のエラーでは手数料が課金されます。
  • NotTEC系のエラーでは手数料は課金されません。
  • したがって、署名検証より前に返されるエラーは**tec系であってはなりません**。
• チェックの順序:
  • tec系のエラーになり得るバリデーションロジックは、必ず署名検証の後に実行されなければなりません。
  • これにより、署名が検証される前にトランザクション手数料が課金されることがなくなります。

修正対応

• UNLバリデーターに対して、featurePermissionDelegationアメンドメントへの反対(「No」)投票を促し、有効化を阻止するよう呼びかけました。すでに複数のバリデーターが反対票を投じています。
• 2.6.1~rc2リリースおよびそれ以降のすべてのリリースで、本アメンドメントを無効化しました。

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

本件への直接的な対応として:

• エラーコードtecNO_DELEGATE_PERMISSIONをterNO_DELEGATE_PERMISSIONに変更し、署名検証より前に手数料が課金されないようにしました。 (この変更はまだマージされておらず、レビューおよびテストの段階にあります。)

加えて、Rippleのエンジニアリングチームおよび関係者は、同様の脆弱性が将来発生しないよう、より広範なコードベースの見直しも進めています。 計画されている改善には次のものが含まれます。

• 署名検証の前段に位置するバリデーションロジックをリファクタリングし、署名検証より前に返されるエラーが必ずNotTEC系のみとなるようにする。
• 署名が検証される前にトランザクション手数料が引き落とされないことを保証する invariant チェックを追加する。これにより、今後本ルールに違反する機能が出てきた場合でも、問題を早期に検知できるようになります。
• さらに、署名検証の前にtec系のエラーを発生させてはならない旨を明記した、わかりやすいドキュメントとコメントをコードに追加する。

再現手順

1. Delegateフィールドに、Accountフィールドのアカウントを代理して該当トランザクションを送信する権限を持たないアカウントを指定したトランザクションを構築します。
2. RPCレベルでの署名チェックを回避するため、トランザクションをオフラインで署名します。
3. 構築したトランザクションをネットワークへ送信します。

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

• トランザクションは、署名が有効かどうかにかかわらずtecNO_DELEGATE_PERMISSIONで失敗します。
• 署名が無効な場合でも、委譲先(被害者)アカウントからトランザクション手数料が引き落とされます。

注意 RPC経由(オンライン)で署名する場合、無効な署名は早期に検出されてbad_secretで拒否されるため、この攻撃経路は発生しません。

利用可能な修正/パッチ

本問題の修正は、機能アメンドメントの新バージョンPermissionDelegationV1_1として devnet 上で利用可能になります。 修正の詳細はこちらでご確認いただけます。 新しいアメンドメントはPermissionDelegationおよびDelegateV1_1を置き換えるものとなり、これら2つはいずれも非推奨となります。

謝辞

本問題を責任を持って報告してくださった tequ さん、そして問題の確認とアメンドメントのブロックに迅速に対応してくれたUNLバリデーターの皆さんに感謝いたします。 徹底した調査と、コードベースの長期的なセキュリティ強化に取り組んでくれたエンジニアリングチームにも感謝します。

そして、いつものように、XRP Ledgerを稼働させ続け、ネットワークの安全性とセキュリティを守るために尽力されている、世界中のバリデーター・開発者・コントリビューターのコミュニティの皆さんにも感謝を申し上げます。

参考資料

• xrpl.org ドキュメント: https://xrpl.org/docs/concepts/accounts/permission-delegation
• XLS-0074 Account Permissions
• XLS-0074 Permission Delegation

お問い合わせ

詳細情報、または追加の問題を報告される場合は、bugs@xrpl.orgまでチームへご連絡ください。

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