Bitcoin Coreは2026年11月、3件のセキュリティ脆弱性の詳細を公開しました。修正はすでに約1年前に出荷されています。3件のうち最も深刻なものは「高(High)」に格付けされており、チェーン再編成後にマイニングノードが有効なブロックテンプレートを作成できなくなる可能性がありました。

Bitcoin CoreはBitcoinプロトコルのリファレンス実装です。ネットワーク上のノードはこのオープンソースソフトウェアを使用してトランザクションやブロックを検証・中継し、マイナーやマイニングプールは、保留中のトランザクションを一時保持するネットワークの待機領域であるmempool内の未確認トランザクションからブロックテンプレートを組み立てるために使用しています。

同プロジェクトの方針として、脆弱性の公開は遅れて行われます。まず修正がリリースとして出荷され、技術的な説明は影響を受けるバージョンが古くなった後で初めて公開されます。これらの脆弱性の修正は、2025年10月にリリースされたバージョン30.0、29.2、28.3に取り込まれました。アドバイザリにはCVE-2025-62861、CVE-2025-62859、CVE-2025-62860という、公開されたソフトウェア脆弱性をカタログ化する標準識別子が付与されています。CVE-2025-62861は「高(High)」、残りの2件は「中(Medium)」に格付けされています。これに伴い、プロジェクトは最後の脆弱なリリースシリーズである29.xラインのサポート終了からわずか14日後にアドバイザリを公開しました。全文は公式開示およびプロジェクトのセキュリティアドバイザリ索引で確認できます。

再編成がマイニングノードを停止させる仕組み

高深刻度の脆弱性CVE-2025-62861は、バージョン28.0から28.2および29.0から29.1に影響します。Niklas Goegge氏が2025年9月に報告しました。この欠陥は、TRUC(Topologically Restricted Until Confirmationの略)としても知られ、v3トランザクションとも呼ばれる仕組みに起因します。このmempoolポリシーは、未確認トランザクションが互いに依存する方法に厳しい制限を課すものであり、主な目的は、Lightning Networkなどのレイヤー2プロトコルが後から手数料を引き上げられるよう支援することです。バージョン28.0では「sibling eviction」と呼ばれる追加ルールが導入されました。新しいトランザクションはTRUC親トランザクションに第2の子を追加しようとすることができ、十分な手数料を支払えば既存の子を置き換えます。

このバグは再編成(略して「reorg」)の際に表面化しました。再編成とは、ネットワークが直近に追加されたブロックを別のチェーンに置き換えるイベントです。Bitcoin Coreはまず、切断されたブロックからトランザクションをフラグbypass_limits=true付きでmempoolに戻します。しかし、sibling evictionの分岐はこのフラグを尊重せず、実行されてしまいました。その結果、このルールは子孫トランザクションがmempoolに残ったまま、あるトランザクションを排除し、mempoolにはもはや存在しない出力を使用するトランザクションが残りました。その後ノードが新しいブロックテンプレートを作成しようとするたびに、有効性チェックが失敗しました。

影響を受けたマイナーは、ノードを再起動した後にのみ有効なテンプレートを再び生成できるようになりました。再起動によりmempoolが一貫した状態で再読み込みされるためです。それでも、CVE-2025-62861のアドバイザリはアップデート以外の回避策を挙げていません。Greg Sanders氏がPR #33504で修正を提供し、プロジェクトは2025年10月にこれをメインブランチにマージし、28.x、29.x、30.xラインにバックポートしました。この脆弱性はテンプレート作成にのみ影響しました。TRUCはmempoolルールでありコンセンサスルールではないため、このバグはコンセンサスに影響しませんでした。TRUCのようなmempoolルールは各ノードが自身の保留トランザクションに適用するローカルポリシーであり、共有チェーン上で全ノードが強制するコンセンサスルールとは異なります。

ブロック中継とTorピアに影響する2件の中深刻度の脆弱性

CVE-2025-62859は、バージョン29.2未満および30.0未満に影響します。Eugene Siegel氏が早くも2025年4月にこの脆弱性を報告していました。これは、ノードが互いに新しいブロックを伝えるために使用する短縮形式であるコンパクトブロックの処理に存在します。影響を受けるバージョンは、witness malleation(目撃データの事後変更を指す用語)のチェックを行う前に、当該ブロックのダウンロード状態をクリアしていました。チェックが失敗した場合、ノードはGETDATA経由で同じピアからデータを再要求し、タイムアウトは10分間——Bitcoinブロックの平均間隔にほぼ相当します。したがって、コンパクトブロックを先にアナウンスした悪意あるピアは、被害者のブロック処理を最大10分遅らせることができました。さらに、攻撃者は-blocksonlyモードや、ノードが優先ブロックアナウンスのために依存する少数のピアである3つの高帯域幅ピアをすべて制御している場合、攻撃を無制限に繰り返すことができました。2025年6月にマージされたPR #32646がこのバグを修正しました。

2件目の中深刻度の脆弱性CVE-2025-62860は、バージョン28.3、29.2、30.0未満に影響します。Martin Zumsande氏とAntoine Poinsot氏が2025年9月、Goegge氏が高深刻度の脆弱性を報告する2週間前に報告しました。Bitcoin Coreでは、インバウンドTor接続はTorデーモン——匿名ネットワークからのトラフィックを転送するローカルサービス——のIPアドレスで表示されます。そのアドレスが-whitelistで許可されたIP範囲内に該当する場合、すべてのインバウンドTorピアがホワイトリスト権限を受け取っていました。これらの権限は、DoS制限およびプライバシー漏洩に対する保護を解除します。

アドバイザリによれば、到達可能な「数千」のメインネットノードが、すべてのインバウンドTor接続にこれらの権限を付与していました。多くの場合、Bitcoin CoreをTorデーモンとバンドルして出荷するプロバイダーがこのオプションを設定していました。対照的に、このオプションの非デフォルト設定を使用していないノードは、この脆弱性の影響を一切受けませんでした。PR #33395以降、Bitcoin Coreはホワイトリスト権限を割り当てる際にインバウンドTorピアを考慮しなくなりました。

プロジェクトは両方の脆弱性を「中(Medium)」に格付けしています。ブロック処理の遅延は一時的なものであり、攻撃者が自由に繰り返せるのは特定の構成の場合に限られ、一方のTor脆弱性はデフォルトから外れた構成を必要としました。

修正から開示まで1年を要した理由

Bitcoin Coreは意図的に修正と開示を分離しています。修正はまず通常のリリースで出荷され、その時点でプロジェクトは脆弱性を説明しません。詳細は、影響を受けるバージョンが古くなるかサポート終了に達した後に続きます。これにより運用者にはアップデートの時間が与えられます。

今回の3件のアドバイザリでは、報告は2025年4月から9月の間に届き、修正は2025年6月から10月の間にコードに取り込まれました。そしてBitcoin Core 30.0、29.2、28.3が2025年10月に修正付きで出荷されました。開示の時期はサポート終了によって決まりました。最後の脆弱なバージョンラインである29.xのサポートは2026年10月27日に終了し、アドバイザリは14日後の2026年11月10日に公開されました。

プロジェクトのアドバイザリ索引は「重大(Critical)」「高(High)」「中(Medium)」「低(Low)」の4段階の深刻度レベルを使用しています。3件すべてのアドバイザリは中間のレベルに位置しています。CVE-2025-62859の期間が際立っています。Siegel氏は2025年4月に脆弱性を報告し、プロジェクトは2025年6月に修正をマージしましたが、詳細が公になったのは報告から18ヶ月強経過してからでした。

この脆弱性がマイナーとノード運用者にとって意味するもの

高深刻度の脆弱性は主にマイナーとマイニングプールに影響しました。再編成を経てブロックテンプレートを作成する必要が生じたノードのみがこのバグを引き起こしました。対照的に、2件の中深刻度の脆弱性は通常のノードにも影響しましたが、それぞれ特定のネットワーク状況または構成を必要としました。

バージョン30.0と29.2は3つのバグすべてを修正し、28.3はそのうち2つを修正しています。しかし2026年10月末以降、30.x以降のバージョンのみがサポート対象です。したがって、29.x以前を実行している人は、バックポートがあってもサポート外のソフトウェアを使用していることになります。

アドバイザリにはいくつかの未解決の疑問が残されています。たとえば、攻撃者が高深刻度バグを引き起こす再編成トポロジを意図的に作成できるかは不明です。また、アドバイザリは3つの脆弱性のいずれかが実際に悪用されたかどうかについても言及しておらず、Tor脆弱性の影響を受けたノードの正確な数もありません。ただし、記録が示しているのは、プロジェクトが3つのバグすべてを開示の約1年前に修正し出荷していたということです。