Node.jsが10件の脆弱性を修正：Brotli・TLSの影響と本番ランタイムの確認手順

Node.jsは、JavaScriptをサーバーや開発用のPCで動かす実行環境です。Node.jsの10月21日付セキュリティ告知は、22・24・26系にまたがる10件のCVEを掲載しています。CVEは脆弱性を識別する番号で、10件すべてが全系列に共通するわけではありません。APIサーバー、バックグラウンド処理、CI、Node.jsを同梱する製品まで対象を棚卸しします。

修正版の提供日は2026年10月21日です。22・24系はLTS（長期サポート）、26系は確認時点でCurrentです。この問題の対応のためだけに、22系から26系へ飛び級する必要はありません。運用中の系列に対応する修正版、またはそれ以降の公式な修正を含む版を選びます。各CVEが入り込んだ最初の版は、この告知からは一律に確定できないため記載しません。

サポート終了版は、この表にないから安全ということではありません。Node.jsはセキュリティリリース時にEOL版も影響対象として扱い、サポート中の版の利用を求めています。OSベンダーや製品ベンダーが修正をバックポートしている場合は、上流の番号だけで判断せず、その配布元の勧告とパッケージのリリース番号を確認します。

Brotliはデータを小さくする圧縮方式です。CVE-2026-111497では、細工された圧縮データの展開中に、本来書き込むべき範囲を越えてメモリを書き換える問題が報告されています。Googleが登録したCVEの公式レコードは、停止、情報の露出、任意コード実行の可能性を説明しています。Webを公開しているだけで必ず成立するという意味ではなく、攻撃者が用意したデータが対象のデコーダーへ到達するかが重要です。

CVSSは技術的な深刻さを評価する指標です。9.2はGoogleがBrotliについて登録した値であり、Node.jsが今回の全10件を9.2と採点したわけではありません。Node.jsの告知は最高深刻度をHighとしています。他の9件の数値スコアは確認したNode.js告知では示されていないため、推測して補いません。

Brotli単体にも1.2.1、1.1.1、1.0.10の修正リリースがあります。ただしNode.js 22.23.4のリリースノートでは修正コミットの取り込みが記載されています。Node.jsに組み込まれたBrotliの表示番号だけで修正の有無を決めず、Node.js本体または配布元の修正履歴を根拠にしてください。

本稿が確認した一次資料では、実際の攻撃への利用は確認できていません。「悪用されていない」と断定するものではありません。確認できたCISA KEVのデータは10月21日更新で、後から公開されたCVEの状況を判断するには限界があります。悪用情報を待ってから棚卸しを始める必要はありません。

下表のHigh／Medium／LowはNode.jsの個別CVE見出しに従います。系列は修正前の影響対象を示します。概要しか公表されていない項目について、攻撃に必要な全条件を確認できたとは扱いません。

TLSのホスト名検証は、暗号化された通信の相手が「接続したかった相手」か確かめる処理です。暗号化していても相手の確認に不備があれば問題になります。一方、乱数の問題はrandomUUID()やrandomInt()のキャッシュを起動スナップショットやSEA（単一実行ファイル形式）へ保存する条件です。あらゆる通常起動のNode.jsで乱数が必ず重複すると一般化しません。

Permission ModelはNode.jsがファイルなどへのアクセスを制限する機能です。使っている場合は権限設定を点検しますが、使っていないことはBrotliやTLSの問題まで対象外にする根拠にはなりません。今回の更新にはc-ares、Undici、CA証明書などの依存部品の対応も含まれます。アプリケーションのnpmパッケージだけを更新して完了にしないことが大切です。

権限のある環境で、次のコマンドは起動したNode.jsと組み込み部品の版を表示します。process.versionとprocess.versionsの公式仕様に基づく確認例です。設定やパッケージは変更しません。編集部ではローカルで実行し、3つのキーを持つJSONが返ることを確認しました。修正版の攻撃耐性を試験したものではありません。

稼働プロセスの版は、既存の起動ログや管理機能など、運用手順で確認できる情報を使います。内部情報を返す公開エンドポイントを新設する必要はありません。npm auditはnpm依存関係の点検と分けて扱い、結果だけでNode.js本体の今回の修正が入ったと判断しません。

1. 1サービス名、環境、Node.jsの系列・配布元、責任者を台帳にまとめる。不明な実行環境は対象外ではなく未確認にする。
2. 2対象系列の公式修正版、または配布元が修正を保証するパッケージを選ぶ。外部由来データのBrotli展開やTLS接続がある処理を優先して検証計画に入れる。
3. 3試験環境で、通常の圧縮レスポンス処理、外部APIへのTLS接続、バックグラウンドジョブ、使用している権限制御やSEAの起動を確認する。攻撃データを本番へ送る試験はしない。
4. 4既存の承認された手順で更新・再起動・再デプロイする。コンテナや複数ワーカーは、旧版の稼働個体が残っていないかを確認する。
5. 5実行版、配布元の修正根拠、適用時刻、回帰確認、未確認事項を保存する。ロールバックで脆弱な版へ戻す場合も対応完了の記録を残したままにしない。

すぐに更新できない場合、外部由来の圧縮データを扱う機能を一時停止・制限できるかを担当者が検討します。ただしBrotliへの対処だけではTLSや乱数などの別の問題は直りません。CDNで圧縮を止めても、アプリケーションが外部APIから受け取るデータの展開など、別経路が残る場合があります。暫定策を全10件の修正と同じ扱いにはしません。

一般のサービス利用者は、サーバーのNode.jsを自分で更新する必要はありません。自社で契約するSaaSや同梱製品について、管理者が提供元の告知・対応状況を確認します。今回の告知だけを根拠に、情報漏えいの発生や全利用者のパスワード変更を断定することもできません。

以下は編集部が作成した防御点検用の指示文です。機密値を除いた台帳と公式資料を添え、読み取り専用の確認から始めます。LLMの回答をそのまま修正済みの証明にはせず、担当者が稼働環境と照合してください。

点検指示文をダウンロード。優先順位の決め方は脆弱性のトリアージも参照してください。

確認日：2026年10月23日。公開仕様と公式告知を照合した解説です。版の表示コマンド以外のパッチ適用・脆弱性再現は実施していません。運用の優先順位、台帳、回帰確認の手順は編集上の提案です。