XRP Ledger財団は、巧妙に構築されたペイメントを通じて攻撃者が使用可能なXRPを作成できた可能性のある脆弱性に対し、開発者とバリデータがどのように対応したかを説明した。財団は、この欠陥を通じてXRPは一切作成されておらず、公開ネットワーク上で悪用された証拠もないと述べた。

10月11日の声明は、脆弱性の技術的仕組みを繰り返すのではなく、対応に焦点を当てたものだった。バグの初期の説明はCoindooのレポートで確認できる。財団の技術開示レポートはXRP Ledgerのウェブサイトで公開されている。

公開台帳データが供給量の主張を裏付け

XRPは固定供給量1000億枚で開始され、取引手数料は時間とともに消却される。財団によると、現在存在するのは約998.6億XRPである。

技術開示レポートは、この脆弱性が公開ネットワーク上で悪用された証拠はチームによって見つからなかったと述べている。この主張は、XRP Ledgerの検証済み取引履歴およびアカウント残高と照らし合わせて評価でき、これらはエクスプローラーやその他のデータサービスを通じて独立した検証のために公開されている。

「これについて私たちを信頼する必要はありません」と財団は述べた。新しいXRPはアカウント残高に表示されるためであり、XRP Ledgerには隠された残高領域は存在しない。財団は台帳を継続的に監視し、ネットワークの歴史全体を通じて供給量を検証してきたと述べ、他のコミュニティメンバーも独自の確認を行ったとしている。

公開記録では、開示前のすべての非公開のやり取りを明らかにすることや、ネットワークに提出されなかった攻撃の意図を証明することはできない。しかし、検証済みの取引、目に見える残高変動、記録された供給量を示すことはできる。この情報は、大量のXRPが秘密裏に発行されネットワーク上に隠されたままになったという主張に反論する根拠となる。

技術開示に先立って修正がリリースされた理由

XRP Ledgerの標準的なガバナプロセスでは、取引ルールの変更は修正案(アメンドメント)を通じて導入される。修正案が有効化されるには、バリデータが2週間にわたり80%超の支持を維持する必要がある。このプロセスにより、運用者にはアップグレードの時間が与えられ、ネットワークは同じ時点で変更を採用できる。

オーバーフロー修正は、この脆弱性が現実のリスクとみなされていたため、異なる経路を辿った。開示レポートによると、古いサーバーが保護される前に正確な欠陥を示すコードを公開すると、攻撃経路が特定されやすくなる可能性があった。そのため、バージョン3.4.1は通常の公開修正案プロセスを待たず、各サーバーがアップグレードする際に保護を適用した。

財団はXへの投稿でこの説明を要約している:

The recent XRP Ledger security fix raised a lot of questions and some misconceptions. Let's clear them up.

1. Was any XRP created?

No. XRP's supply was fixed at 100 billion when the XRP Ledger launched, and no transaction is allowed to create more. This bug was a way around that rule, and 3.4.1 fixed it 2 weeks ago.

You don't need to trust us on this. All ledger data is public, and explorers and data sites read it every day. New XRP would show up in account balances for everyone to see. There is no hidden place for XRP on the XRP Ledger, every balance is public.

We monitor the XRP Ledger 24/7 and have verified the supply throughout the history of the ledger. Others in the community verified this too, and anyone can do the same.

Transaction fees are destroyed, so the supply is deflationary. About 99.986 billion XRP exist today.

1. How did this go unnoticed, and what's next?

No normal payment comes anywhere near triggering it. It took hundreds of deliberately constructed operations.

AI makes bugs like this faster to find, for the bad guys and the good guys.

Together with RippleX and the community, we will ensure the XRP Ledger is protected against such vulnerabilities. This means radically applying Formal Verification and AI adversarial testing, collaborating closely with security researchers, and strengthening the bug bounty program.

You'll hear a lot more about this as we progress.

1. XRP Ledger decentralization at the core of this.

A public fix shows attackers where the bug is, and AI makes that fast. With a normal amendment vote, the fix would have been public for weeks before it took effect, risking network security.

As a reaction to this, the XRPL community came together, and among them the XRP Ledger Foundation, RippleX, core devs and validators formed a social consensus and agreed on a path forward that involves shipping the fix directly. Patching a live network is never trivial, so the plan was also designed to minimize disruption for everyone running on it.

We shared the build with the default UNL validators, using the contact details each one publishes in its xrp-ledger.toml file. Public binaries followed the same day, September 25.

No single party could make that call alone. Every validator and node operator chooses what software to run, and 3.4.1 only became required through a normal amendment vote with more than 80% validator support for two weeks. Protocol changes still go through amendments.

Big thanks to Cayden Liao and Veria AI for finding and reporting this responsibly, to the XRPL core developers for building and testing the fix, and to every node operator who upgraded so quickly, especially the validators.

Full report:

— XRP Ledger Foundation (@XRPLF) October 11, 2026

財団は、直接のソフトウェアリリースを通常のガバナンスに代わるものではなく例外的な対応と位置づけた。レポートによると、これは修正案システムが導入されてから10年以上経って初となる、取引処理への意図的な直接変更であった。今後のプロトコル変更については、引き続きバリデータの支持による修正案が必要であるとしている。

バリデータはソフトウェアインストールの決定権を保持

財団は、9月25日に公開バイナリをリリースする前に、デフォルトUNLバリデータの運用者に修正済みビルを共有したと述べた。運用者は新しいバージョンを実行するかどうかを自ら判断した。財団もRippleXも、独立して運用されるサーバー群にアップグレードを強制することはできなかった。

このため、修正済みサーバーと未修正サーバーが特殊なペイメント経路について異なるルールに従う短期間が生じた。XRPLのレポートによると、この期間中に悪用が試みられた場合、バージョン間で見解が食い違い、検証プロセスが混乱する可能性があった。チームは、より長い公開有効化期間中に安価かつ取り返しのつかない可能性のあるインフレ攻撃を放置するより、このリスクの方が望ましいと判断した。

対応はXRP Ledger財団、RippleX、コア開発者、バリデータの間で調整されたが、単独の組織が決定を下せるわけではなかった。すべてのバリデータとノード運用者が実行するソフトウェアを選択する一方、プロトコル変更を必須にする仕組みとして修正案システムが維持される。

開示がユーザーと運用者に意味するもの

レポートは、XRP保有者に資金の移動やウォレットの交換を指示しなかった。ノード運用者については、XRPLはネットワークとの同期を維持するため、サーバーでxrpldバージョン3.4.1以降を実行すべきであると述べた。実務上、明示された対応措置は、XRP保有者に求められるウォレット上の操作ではなく、台帳インフラを維持するソフトウェアに関するものであった。

財団はまた、通常のペイメントではこの脆弱性を引き起こすことはほど遠いとも述べた。悪用には何百もの意図的に構築された操作が必要であった。さらに、人工知能は攻撃者と防御者の双方にとって脆弱性をより速く発見することを可能にするとしている。

計画されているセキュリティ対策

財団は、形式的検証とAI敵対的テストの活用を拡大し、外部のセキュリティ研究者とより緊密に連携し、バグ報奨金プログラムを強化する計画であると述べた。これらの対策によって重大な問題が再び発生しないことが保証されるわけではないが、脆弱性が本番リリース前に特定される可能性を高めることを目的としている。

技術開示レポートは、リリース管理の措置についても記している。修正済みとされたセキュリティ上の所見は、パッチを含むリリース候補に対して再テストされ、所見を完了とする前に当初報告された問題が再現されるべきであるとしている。このプロセスにより、外部の研究者が今後のリリースを評価する際の明確な基準が提供される。

この脆弱性は、XRPの固定供給量を維持するために設計されたルールにおける重大な弱点を露呈させた。今回の対応は、バグ報奨金レポート、迅速なバリデータのアップグレード、その後の技術開示、セキュリティ実践の強化へのコミットメントからなる公開記録を残した。これらのコミットメントが今後のリリース手順の日常的な一部となるかどうかが、このインシデントの長期的な意義を決めることになる。

本記事は情報提供のみを目的としており、投資助言を構成するものではありません。ソフトウェアリリースおよびセキュリティ開示の詳細は、さらなる技術情報が入手可能になり次第、変更される場合があります。

出:Coindoo。