書き手：TapBox運営事務局（運営者情報・編集方針）
XRP Ledgerが「存在しないXRPを生めた」脆弱性を開示 2015年の支払いエンジンに約11年潜伏、9月25日の緊急リリースで修正済み・悪用の形跡なし
XRP Ledgerの開発側が10月9日、xrpld 3.4.1で直した2件の脆弱性の詳細を公開した。1件は支払いエンジンの整数オーバーフローで、総供給量を超えるXRPを作り出して使える状態だった。修正はアメンドメントを待たない9月25日の緊急リリースで配布済み、公開ネットワークでの悪用の形跡は見つかっていない。
XRPLが「無限発行」 バグを修正と開示
XRP Ledgerの開発側が10月9日、xrpld 3.4.1で修正した2件の脆弱性の詳細を公開した。うち1件は支払いエンジンの整数オーバーフローで、総供給量を超えるXRPを作り出し、通常のXRPと区別がつかない形で送金や売買に使える状態だったという。修正は9月25日の緊急リリースですでに配布されている。
開示された中身
1件目は支払いエンジンの整数オーバーフロー。複数の注文（Offer）の金額を64ビット整数で足し合わせる際にオーバーフローのチェックがなく、合計が小さい値に巻き戻る。その結果、買い手が支払う額より売り手が受け取る額のほうが大きくなり、差分がXRPとして生まれてしまう。残高の不整合を検知するはずの内部チェック（インバリアント）も同じように巻き戻るため、素通りしていた。影響を受けるのは 3.4.0 以前。
2件目は Batch（XLS-56）の内部トランザクションのラッパー検証漏れで、fixBatchV1_2 というアメンドメントで対処された。こちらはサーバのバージョン差でコンセンサスがずれる危険があったもので、影響は 3.3.0 と 3.4.0。fixBatchV1_2 はメインネットで10月9日に有効化されている。
- 開示日：2026年10月9日（修正版 xrpld 3.4.1 のリリースは9月25日の緊急リリース）
- 1件目：支払いエンジンの整数オーバーフロー。影響は 3.4.0 以前、深刻度はクリティカル
- 2件目：Batch内部トランザクションのラッパー検証漏れ（fixBatchV1_2）。影響は 3.3.0 と 3.4.0
- もとになったコードは2015年に書かれた支払いエンジン。約11年のあいだ気づかれていなかった
- 報告はXRPLのバグバウンティ経由。9月下旬に届き、数日で緊急リリースが出ている
- 公開ネットワークでの悪用の形跡は見つかっていない。資金の流出や鍵の漏えいも報告されていない
- 1件目の修正はアメンドメントの投票を待たずに適用された（通常の手続きを踏むと、その間ずっと穴が開いたままになるため）
正直、見出しだけ見たときは肝が冷えた。ただ中身を読むと、9月22日ごろに届いた報告に対して25日に緊急リリースが出てる。3日くらいで直して配ってるのよね。しかも悪用の形跡はなし。怖い話ではあるんだけど、出てきた事実としては「踏まれる前に塞いだ」なのよな
スポンサーリンク
Xでの反応
10月10日の日本語圏では、この話題だけで一日のうちに10アカウント以上が投稿していた。報道アカウントの速報に数千〜数万の表示が付き、評価は「対応が速い」と「10年気づかなかったのが問題」できれいに割れている。
「10年気づかなかった」も「3日で直した」も、どっちも本当のことなのよね。片方だけ言うとウソになるやつ。自分はXRPを応援してる側だけど、ここは両方そのまま置いておきたい
これから何を見ればいいか
1件目の修正はアメンドメントを使わずに入ったぶん、ソースコードの公開はまだ先送りになっている。公開されたときに、外部の目でどう評価されるかがひとつ。もうひとつは、同じ系統のインバリアントチェックが他の処理でも巻き戻らないか、追加の検証が出てくるかどうか。どちらも、出てきた事実を見てから判断すればいい話です。
本記事は公開されている情報をもとにした事実の紹介と、それに対するコミュニティの反応の記録です。 特定の暗号資産の売買を推奨するものではなく、投資助言でもありません。 価格や制度は変動します。投資判断はご自身の責任で行ってください。 記事の作り方や、誤りを見つけたときの連絡方法は運営者情報・編集方針をご覧ください。
スポンサーリンク
