Node.js 脆弱性｜2026年10月セキュリティリリースのBrotli RCEと修正版への上げ方

「Node.js 脆弱性」で調べる人に向けて、2026年10月21日のセキュリティリリースを一次情報で整理する。最重大は Brotli デコーダの境界外書き込みによるリモートコード実行（RCE・High・CVE-2026-111497）で、合わせて10件が修正された。Critical はなく、各系の最高は High だ。やることは一つで、自分の Node.js の版を確かめて修正版に上げる。この記事は、どの版に上げるのか・自分の版の確かめ方・npm audit との役割の違いといった迷いやすい点を、公式の一覧だけを根拠に整理する。なお一般のニュース記事には公式と食い違う CVE 番号が出ているので、番号は公式ページで確認してほしい。

今回は特定サービスの侵害ではなく、Node.js 本体の定例セキュリティリリースだ。依存の鎖がどこで切れるかという全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説にまとめている。

2026年10月のNode.js 脆弱性で直るもの

公表日は2026年10月21日で、各系のリリースは同日以降に順次提供される。公式の発表によると、修正版は3つだ。26.x 系が 26.12.1（Latest Release）、24.x 系が 24.22.1（Latest LTS）、22.x 系が 22.23.4（Maintenance LTS）。Critical はなく、3系いずれも最高は High だった。

注目を集めるのは Brotli の RCE だが、一つの番号に対処する話ではない。同じリリースで TLS やDNSの検証バイパス、暗号の値の反復、権限モデルの穴など、性質の違う10件がまとめて直る。番号ごとに個別対応するのではなく、系の修正版へ一度に上げるのが筋だ。

最重大の CVE-2026-111497 は、Brotli デコーダの境界外書き込みで、公式は「リモートコード実行を許す」と記している。Brotli は Node.js に組み込まれた圧縮方式で、zlib.brotliDecompress などから使われる。攻撃が成り立つ前提は、攻撃者が細工した Brotli 圧縮データを、アプリが展開する経路に流し込めることだ。たとえば外部から受け取った圧縮済みの応答やアップロードを復号する処理が該当しうる。具体的な再現手順やペイロードは公式も公開しておらず、本記事でも扱わない。確実なのは、修正版に上げれば直るという一点だ。

どのNode.js 脆弱性があるか｜深刻度順の一覧

公式ページの表を深刻度順に並べ直したものが下の一覧だ。二次ソースは番号が食い違うため、ここでは公式の表記だけを載せる。

High の4件は、RCE のほかはいずれも「本来はじくべき通信を通してしまう」系だ。TLS のホスト名検証やDNSの名前解決が、全角数字のIPや緩いIP解決といった端のケースで欺かれる。暗号側の Medium では、crypto.randomUUID() や randomInt() の乱数が、起動スナップショットや単一実行可能アプリ（SEA）に焼き込まれると、どのプロセスでも同じ値を返してしまう。Low の3件は、--permission で絞ったはずのファイルアクセスが抜けるもので、権限モデルを使っている環境だけが関係する。性質はバラバラだが、対処は同じ修正版への更新で足りる。

自分のNode.jsは該当するか｜node -v と修正版の比較

判定は難しくない。動いている Node.js 本体の版を出し、その系の修正版と比べるだけだ。

node -v                            # 動いている Node.js 本体の版
node -p "process.versions.node"    # スクリプトからも同じ値が取れる
node -p "process.versions.openssl" # 同梱された OpenSSL の版（依存更新の確認に）

たとえば v22.22.0 と出たなら、22.x 系の修正版 22.23.4 より小さいので対象だ。各系のしきい値は、26 系なら 26.12.1、24 系なら 24.22.1、22 系なら 22.23.4。これ未満なら上げる。サポートの切れた 20 以前などの EOL 系は、修正が出ないため常に対象で、まずサポート対象の系へ移す。

ここで誤解が多いのが npm audit との関係だ。

npm audit   # package-lock.json の依存を調べる。Node.js 本体の CVE は出ない

npm audit はプロジェクトの依存パッケージを npm の勧告データベースと照合する道具で、実際に古い依存を入れた環境で走らせると、その依存の勧告（たとえば lodash のプロトタイプ汚染など）は列挙するが、今回の CVE-2026-* のような Node.js ランタイム本体の番号は一件も出ない。ロックファイルが無いと This command requires an existing lockfile で止まり、そもそも依存を見る前提のコマンドだと分かる。つまり本体の該当は node -v で、依存の該当は npm audit でと役割が分かれている。

もう一点、node -v が答えるのは「このシェルで呼ばれた Node の版」だけで、これだけではホスト全体が安全とは言えない。nvm で複数の版を入れていれば別の版が残っているかもしれないし、which node が指す実体やコンテナ内の版は別に確かめる必要がある。これは脆弱性の判定ではなく、動いている版の確認だと捉えるのが正しい。陽性（修正版以上と出た）でも、同じホストの別プロセスが古い版で動いていれば危険は残るし、陰性（古いと出た）でも、そのプロセスが外部入力を一切 Brotli 展開しないなら Brotli RCE の実害は限定的、という具合に、版の表示だけでは実害の有無までは確定できない。

アップデートの段取り

上げ方は環境ごとに違うが、順番は共通だ。稼働している各環境で版を確かめ、修正版へ上げ、プロセスを再起動する。

バージョン管理ツールを使っているなら、同じ系の修正版を入れて既定に切り替える。

nvm install 22.23.4          # nvm の場合。入れたい系の修正版を指定する
nvm alias default 22.23.4    # 既定を修正版に向ける

Docker で動かしているなら、ベースイメージのタグを修正版に固定し、イメージを作り直してデプロイする。node:22（移動するタグ）でも次の docker build で新しいパッチを拾うが、node:22.23.4 のように固定しておくと、どの版で動いているかが Dockerfile から読める。CI では、ランナーに入っている Node の版（GitHub Actions の setup-node の node-version など）も同じしきい値で見直す。

更新で見落としやすいのが再起動だ。バイナリを入れ替えても、すでに起動しているプロセスはメモリ上の古いコードで動き続ける。pm2・systemd・コンテナのいずれでも、更新後に再起動（またはローリングデプロイ）してから、もう一度 node -v で稼働中の版を確かめる。手順の細部や各OSのインストーラは公式のダウンロードとリリーススケジュールに従ってほしい。

EOLラインと依存の更新（eMudhra の CA 危殆化ほか）

EOL（サポート終了）の系は、セキュリティリリースのたびに常に影響を受ける側に入る。修正が出ないため、node -v が古い系を指しているなら、まずサポート対象の系へ移すのが先だ。

今回のリリースには、Node.js に同梱された依存の更新も含まれる。c-ares・OpenSSL（24/22）・SQLite（22）・Undici（26/24/22）に加え、eMudhra 中間CAの危殆化に対応した CA 証明書（ca-cert）の更新が 26/24/22 に入っている。これは Node.js が同梱するルート証明書の束から、信頼できなくなった中間CAを外すもので、更新しないと問題の証明書チェーンを古い信頼のまま扱い続けることになる。中間CAが失効・危殆化したときに自分のTLS接続がどう影響を受けるかは中間CAの危殆化・失効で自分のサイトの証明書はどうなる？確認手順とeMudhra事例で扱っている。同梱依存の版は node -p "process.versions.openssl" のように確かめられる。

なお、本体の更新と依存パッケージの棚卸しは別の作業だ。アプリが抱える npm 依存の脆弱性をどの順で直すかはnpm audit の結果はどれから直す？依存関係の脆弱性を到達性・EPSS・KEVで仕分ける実践手順に、本体ではなく周辺の層で詰まりやすい話はReact 脆弱性の多くは本体ではない｜XSS・依存・SSR・古い版の4層を実測で整理する付き合い方にまとめた。

参照ソース

・Node.js Security Releases: Wednesday, October 21, 2026（公式） — CVE 一覧・修正版・依存更新（2026-10-21時点）
・nodejs/node Release Schedule（公式） — 各系のサポート状況と EOL