TITLE

Node.js 同梱の Brotli デコーダに脆弱性 CVE-2026-111497 ― 企業が確認すべきこと

投稿日：2026.10.27

Brotliデコーダの何が壊れていたのか ― 「あと少し」の誤認

壊れているのは、ストリーミングデコーダの異常処理です。Brotli のデータには「ブロックの切り替え」という構造があり、本来であれば不正なブロック切り替えは恒久的な形式エラーとして止まるはずでした。CVE-2026-111497では、この不正な切り替えが「入力がさらに必要」という状態として扱われてしまいます。デコーダは「もう少し読めば続きが来る」と判断し、内部に持っている8バイトの小さなバッファへバイトを追加し続けます。

この追加は本来のバッファサイズを超えて進み、範囲外書き込み(out-of-bounds write)になります。影響は、プロセスメモリの破損・クラッシュ・メモリの漏えいで、場合によってはリモートコード実行(RCE)につながる可能性があると公式は説明しています。修正は、Brotli の実装元である google/brotli の該当コミットを Node.js 側に取り込んだものです。現時点で、この脆弱性が実際に悪用されたという報告や公開されたPoCは確認されていません。

対象バージョンと対応版 ― 20.x は蚊帳の外

対象は Node.js 26.x・24.x・22.x です。修正済みバージョンは v22.23.4 / v24.22.1 / v26.12.1 で、この3つへのアップグレードがそのまま対応になります。

Node.js 20.x はこの脆弱性の対象バージョン一覧に含まれていますが、それは「20.x も危険」という意味ではありません。Node.js 20.x は2026年4月30日に既にEOL(サポート終了)を迎えており、今回のセキュリティリリースの対象外、つまりパッチ自体が提供されていません。20.xを使い続けている場合、今回のCVEとは別に、EOLバージョンを使っているという課題がすでにあることになります。

同じ日のセキュリティリリースでは、深刻度Highの脆弱性が他に3件公開されています。dns.resolve*()やdns.reverse()がホスト名に含まれるNUL文字を黙って切り詰めてしまう問題、全角数字で書かれたIPアドレスをtls.checkServerIdentity()がIPとして認識せず証明書照合をすり抜けてしまう問題、先頭に0が付くIPv4表記の解釈がWHATWGのURLルールとOSのリゾルバで食い違う問題です。いずれもネットワーク処理や証明書検証に関わりますが、対応はBrotliデコーダの件と同じバージョンへのアップグレードで済みます。報道(securityonline.info)によれば、今回のリリース全体では合計10件のCVEが修正されたとされています(High4件・Medium3件・Low3件)。

依存監査の「死角」― もう一つの対象

依存ライブラリの脆弱性やフレームワークのサポート期限切れを日次で検知する仕組みを導入している企業は少なくありません。ただし、こうした仕組みの監視対象は、package-lock.jsonやrequirements.txtといったロックファイルに記録されたライブラリの版と、Django・Laravel・Next.jsといったフレームワークのサポート期限に限られていることが多く、言語・ランタイム本体(Node.js自体)の実行バージョンは別管理になっているケースがあります。

依存監査の仕組みが見ている範囲の対比図。パッケージの脆弱性とフレームワークのEOLは監視対象だが、Node.js本体の実行バージョンは対象外であることを示す

つまり、依存ライブラリの監査結果がすべて green であることと、その上で動いているNode.js本体が最新の修正版であることは、別の確認事項です。パッケージの脆弱性スキャンを導入している会社でも、ランタイム本体のバージョンだけは別管理になっていることがあります。CVE-2026-111497はちょうどこの位置にある脆弱性で、npmパッケージの監査だけでは見つかりません。

今日からできる4つの確認

ノートPCの画面に発光するコード行とシールド型のチェックマークアイコンを重ねた、バージョン確認とセキュリティパッチ適用を表すイラスト

本番・CI・開発環境それぞれで node -v を実行し、実際に稼働しているバージョンを確認します。宣言されているバージョン(package.jsonのenginesやDockerfileの指定)と、実際に動いているバージョンが食い違っていることもあるため、稼働中の環境で直接確認します。
確認したバージョンが22.x・24.x・26.xのいずれかに当たるか見ます。20.x系はこの修正の対象外ですが、EOL(2026年4月30日)を既に過ぎているため、別途のアップグレードが必要です。
対象バージョンであれば、ワークアラウンドが示されていないため、修正済みのv22.23.4 / v24.22.1 / v26.12.1のいずれかへアップグレードする以外の対応はありません。
node:zlibでBrotliデータを外部入力に対して展開している処理があるかを洗い出します。ユーザーがアップロードしたファイルの展開や、外部APIから返る圧縮レスポンスの展開がその代表例です。該当する処理がなければ緊急度は下がりますが、対象バージョンを使い続けるリスクは別に残ります。

まとめ

同じ死角を二度作らないために確認しておきたいのは、依存監査の仕組みそのものの監視範囲です。ロックファイルの脆弱性とフレームワークのEOLだけでなく、使っている言語・ランタイム本体のバージョンまで監視対象に入っているかを、一度棚卸ししておくと今回と同じ見落としを防げます。この構造はNode.jsに限った話ではなく、Pythonのインタプリタ本体やPHPのランタイムでも同じことが起こり得ます。