bitcoinjs-lib、偽のブロックを通す脆弱性　5.2.1・6.1.8・7.0.2へ

npmのライブラリ「bitcoinjs-lib」の脆弱性について、GitHubの脆弱性データベースは11月11日（日本時間）、開発元の告知を確かめた記録を載せた。Bitcoinのブロックの中身を確かめる処理が、同じ取引を重ねて足したブロックを、正しいブロックとして通してしまう。2.3.0以降の広い版が当たり、ブロックの検証にこのライブラリを使う人は、系統ごとの修正版へ上げる必要がある。

2.3.0以降の3系統が当たる

この記録は、開発元が10月27日（日本時間）に出したbitcoinjs-libのセキュリティの告知を、GitHubが確かめて載せたものだ。告知によると、影響と修正版は次のとおりだ。

• 対象: npmのパッケージ「bitcoinjs-lib」
• 当たる版: 2.3.0から5.2.0まで、6.0.0から6.1.7まで（6.1.0-rc.0を含む）、7.0.0-rc.0から7.0.1まで
• 修正版: 5.2.1、6.1.8、7.0.2
• 中身: ブロックの取引の一覧から計算する値（マークルルート）が、同じ取引を重ねた一覧でも元と同じになる。ブロックを確かめる関数「checkTxRoots」はこれに気づかず、取引の一覧が違うブロックも受け入れる
• CVE番号: CVE-2026-107846
• 深刻度: CVSS 4.0で9.3（GitHubの記録による）
• 弱点の種類: CWE-354（整合性を確かめる値の検証が不十分）

告知は、これをBitcoinの既知の弱点「CVE-2012-2459」と同じ問題だと説明する。本家の実装「Bitcoin Core」は、この形のブロックを拒む仕組みを持つ。bitcoinjs-libには同じ仕組みが無かった。

ブロックの識別子と、採掘の証明（プルーフ・オブ・ワーク）の入った見出しの部分は変わらない。そのため告知は、採掘をしなくても、既にチェーンにあるブロックを書き換えた写しを誰でも流せると書く。当たる検証の関数は2.3.0で「checkMerkleRoot」として入り、今は「checkTxRoots」の名前で提供されている。

まず入っている版を確かめる

告知に、版を確かめるコマンドは載っていない。npmで依存を管理している人は、npmの一般的なコマンドで確かめられる。npmの文書で「入っているパッケージを一覧にする」と説明されたコマンドの「npm ls bitcoinjs-lib」を、プロジェクトの場所で打つと、直接の依存か、別のパッケージを通した依存かを問わず、入っている版が出る。

別のパッケージを通して入る依存は、自分の依存の宣言のファイルを見ても分からない。宣言のファイルを探すだけで済ませず、このコマンドで入っている物を見る。リポジトリが複数あれば、それぞれで打つ。

npmの文書が説明する「npm audit」は、依存を既知の脆弱性の記録と照らして報告する。報告に出た版も、上の一覧の範囲に入るかを照らしておく。

影響の大きさは使い方で変わる。告知は、このライブラリの主な用途は取引の処理で、ブロックの検証はその一部だとしている。当たるのは、ブロックが正しいかを「checkTxRoots」で判断している仕組みだ。

系統ごとの修正版へ上げる

告知は、5.2.1、6.1.8、7.0.2か、同じ系統のより新しい修正版へ上げるよう求めている。npmのパッケージのページによると、修正版は9月7日にnpmで配布が始まった。v5より古い版には同じ系統の修正版が無く、修正のある系統へ移る必要がある。依存の版は、npmの文書にある「npm update」などで上げられる。ただし「npm update」は依存の宣言に書いた版の範囲の中でしか上げないので、系統をまたぐ時は宣言の版を書き換える。別のパッケージを通して入った依存は、そのパッケージが版を固定していれば、そのパッケージの更新が要る。

修正の中身は、マークルルートを計算する途中で、隣り合う同じ値があればブロックの検証を失敗させるものだ。告知に、すぐ更新できない時の回避策は載っていない。上げた後は、もう一度「npm ls bitcoinjs-lib」を打ち、別のパッケージを通した依存も含めて、全ての行が修正版になったかを確かめる。

悪用は確認できていない

告知とGitHubの記録は、実際の悪用に触れていない。米CISAの悪用を確認した脆弱性の一覧（KEV）にも、11月11日の時点で載っていない。悪用は確認できていない。

一方、告知は起こり得る被害を具体的に書く。取引所の入金を数える仕組みや、ブロックの中身を表示するサービス、軽量のウォレット（SPVクライアント）が、この関数で判断していると、同じ入金を2回数え得る。また偽のブロックの識別子を拒む対策を取ると、同じ識別子を持つ正しいブロックまで拒み、チェーンの分断につながり得るという。

SAGUSでは当たらなかった

SAGUSは、開発に使う2台の端末で、bitcoinjs-libを使っていないかを確かめた。開発の作業場所の全てのプロジェクトで、「grep」で依存の宣言のファイルと版を固定するファイルの中身を探し、「find」で入っているパッケージの置き場を探したが、どこにも無かった。「npm ls -g」で見た、npmで全体に入れたパッケージにも無かった。本番のサイトは、どれもこれらのプロジェクトから作っており、当たらなかった。

編集部の見方

編集部は、仮想通貨のブロックを扱うアプリを作る人は、直接の依存に無くても、今日中に依存の一覧を確かめるべきだと考える。修正版は9月に出たが、開発元の告知は10月末、GitHubの脆弱性データベースへの掲載は11月だった。依存の監査の報告を待っていると、対応が遅れる。ただし影響はブロックの検証を「checkTxRoots」に任せている仕組みに限られ、取引の作成と署名だけに使うアプリでは被害の筋が細い。