XRPレジャーのコミュニティーブログが9日に公表した報告書によると、リップルの開発部門リップルエックスとXRPレジャー財団は、仮想通貨 XRP を不正に生成できた脆弱性を、9月25日公開のソフトウェア「xrpld」3.4.1で修正した。
この脆弱性は、XRPレジャーで支払いを処理するペイメントエンジンが、1回の支払いで多数のオファー（注文）を消化する際に合計額を上限の確認なしに足し合わせていたことで生じ、現行のエンジンが書かれた2015年から存在していたとみられる。
上限を超えた合計は小さな値に戻る桁あふれ（オーバーフロー）を起こし、各オファーの出し手には全額が支払われた一方、買い手の支払いは桁あふれ後の合計額だけで、差額分のXRPが新たに生まれたという。
3.4.0以前が対象となる問題を受け、3.4.1ではオファーの金額を合計する際に桁あふれを検査する処理を加え、桁あふれが起きる場合はその部分の支払いを失敗扱いにして XRP が生成されないようにした。XRPの新規生成がないかを確認する安全チェックも、同じ方式で合計していたため桁あふれを検知できず、より桁数の多いカウンターに切り替えた。
修正版の公開に先立つ9月22日、バグバウンティ（脆弱性報奨金制度）で報告を受けたリップルエックスは、ローカル環境のサーバーで攻撃を再現し、生成したXRPを後続の支払いで使えることを確認して深刻度を「クリティカル」に引き上げた。
深刻度の背景として、XRPの総供給量は1,000億XRPで固定されており、報告書は、悪用されれば1回の検証済み取引により総供給量を大幅に上回るXRPを作れたと説明した。必要な元手は後に返還される数百XRPの準備金と手数料程度で、公開ネットワークでの悪用の証拠は確認していないという。
取引処理の変更は通常、バリデーター（検証者）の投票による手続き（アメンドメント）を経て適用されるが、今回の修正は同手続きの導入から10年以上で初めて、意図的に手続きを経ずに適用された。
手続きを経なかったのは、xrpldがオープンソースで、修正を公開すれば脆弱性の所在も分かり、手続きが完了するまでの数週間は悪用が可能な状態が続くためで、XRPレジャー財団やリップルエックス、バリデーターらが迅速な修正を優先したという。
一方、手続きを省いたことで、悪用の取引が実行された場合に更新済みと未更新のサーバーで台帳の内容が食い違うおそれがあったが、デフォルトの信頼バリデーターリストに載るバリデーターの80％超が公開当日の25日に3.4.1以降を稼働させた。
このほか、開発チームは、監査やバグバウンティを含め出所を問わず修正済みとした全ての指摘を、リリース候補版で元の問題を再現するテストにかけ、合格した場合のみ完了とする工程をリリース手順に加えていると説明した。
