Brotliが悪用確認済みのKEVに追加：Node.js・PHP Windowsの更新と点検

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の公式公開データには、CVE-2026-111497がdateAdded＝2026-10-27として収録されました。KEVは実際の悪用が確認された脆弱性のカタログです。以前の本記事に記載した「参照資料では実悪用を未確認」という状態から、対応の優先度を見直す必要があります。ただし、登録だけで自社やすべてのNode.js・PHP環境が被害に遭ったと判断することはできません。

表は10月28日朝に取得した公式JSONの該当レコードに基づきます。今回の新情報は「悪用確認済みとしての登録」であり、新しいCVEや新しい修正版の発表ではありません。登録には、被害組織、件数、個々の製品で確認された攻撃経路の詳細は掲載されていません。空白を推測で埋めず、提供元の最新勧告と自社の入力経路を照合してください。

以下は編集部の運用上の提案です。外部入力に到達可能で未修正のもの、修正状況が不明なもの、修正の根拠と稼働反映を確認できたものに分けます。インターネットから直接アクセスできるサーバーだけに絞らず、外部APIの応答や取り込みファイルを展開する処理も確認してください。

1. 1未修正・未確認の資産は、担当者と対応期限を決める。外部入力の到達性、権限、業務影響を踏まえ、既存の変更手順で修正を優先する。
2. 2更新完了の証拠は、配布元の修正情報、実際の稼働版、適用時刻、通常データでの回帰確認をそろえる。ZIPの取得やイメージ作成だけで完了にしない。
3. 3過去の確認は別の記録にする。脆弱な状態で稼働していた期間と、保持されているアクセス・アプリ・端末監視のログの期間を照合する。調査前に証拠を削除しない。
4. 4不審なクラッシュや通常と異なる処理があれば、運用担当・セキュリティ担当へ調査を引き継ぐ。それだけで攻撃と断定せず、記録がない期間は未確認として残す。

JVNの勧告は、BrotliのC言語実装を同梱する複数製品にも影響が及ぶとしています。「HTTP2Shell」「Node2Shell」という呼び名も紹介していますが、名前だけでHTTP/2を使う全システムを対象と判断しません。対象の実装があるか、修正されているか、外部のデータを展開する経路があるかを確認します。

範囲はGoogle CNAのCVEレコードとJVNを照合しました。これは上流ライブラリの表であり、製品独自のバージョン番号の表ではありません。バックポートがある配布物はベンダーの修正根拠を優先します。別言語の独立実装まで、Brotliという名前だけで同じ脆弱性があるとは扱いません。

Brotli上流3系の修正リリースは10月21日19:26〜19:27 UTC（日本時間22日4時台）、CVEレコード公開は10月22日13:35 UTC（同日22:35 JST）、JVNの掲載日は10月26日（日本時間）です。10月26日の新情報は国内向け勧告と同梱製品を含めた注意喚起で、Brotli上流の修正版が同日に初めて出たという意味ではありません。

以下は編集部の点検提案です。SBOM（ソフトウェアに含まれる部品の一覧）、配布元の勧告、ビルド記録から、製品名・製品版・Brotliの実装と版・修正根拠・稼働個体を一行ずつ対応付けます。不明な部品は「対象外」ではなく「未確認」とします。

• 共有ライブラリを使う製品では、OSパッケージの修正と、実際にそれを読み込むプロセスを確認する。更新後の再起動要否は提供元の手順に従う。
• Brotliを実行ファイルに組み込む製品では、OS側のライブラリ更新だけで済ませず、製品更新や再ビルド・再配布の要否を提供元に確認する。
• 送信時の圧縮設定と受信時の展開処理を分ける。Webサーバーの圧縮を止めても、外部APIの応答やアップロードを別の部品が展開する経路が残らないか確認する。
• 更新後は承認済みの通常データで回帰確認を行い、稼働版と修正根拠を保存する。攻撃データを本番へ送って安全性を確かめる方法にはしない。

PHP公式の10月26日付発表は、Brotli 1.2.1を含むWindows用パッケージの再配布を案内しています。公式ページの日時は10月26日11:57:45 UTC、日本時間では10月26日20:57:45です。10月27日朝の確認時点で約10時間前の追報で、Brotliの新しいCVEが増えたわけではありません。

末尾の -1 は依存部品を更新したWindowsパッケージの識別です。PHPのソースリリースは同じなので、更新前後で php -v のPHPバージョンが変わらなくても不思議ではありません。逆に、8.5.12と表示されたという理由だけで、このBrotli修正まで入ったとは判断できません。これはPHP本体の別の脆弱性をすべて解消したという告知でもありません。

対象経路としてPHPチームが説明しているのは、cURL拡張を通じてHTTPレスポンスを自動展開する処理です。自動展開はcURLの既定では無効ですが、アプリやHTTPクライアントライブラリが有効にすることがあります。「自分で設定した覚えがない」だけでは対象外にせず、外部API取得やデータ取り込みに使うライブラリの設定を確認します。

libcurlの自動展開オプションでは、空文字列を指定すると、そのビルドが対応する圧縮方式をまとめて要求できます。Brotliだけを明示しているコードを探すと、こうした設定を見落とします。またAccept-Encodingヘッダーを手書きする操作と、自動展開を有効にする操作は同じではありません。HTTPヘッダーの有無だけで安全性を判定しないでください。

1. 1対象のWindows環境ごとに、PHPの系列、配布元、TS／NTS、CPUアーキテクチャ、Webサーバーとの接続方式を記録する。CLIとWeb、定期ジョブを別々に確認する。
2. 2公式ダウンロード画面でWindowsと利用系列を選び、既存の方式に合う再配布版を確認する。画面に対象版がない場合は、同ページのWindows Archivesを確認する。配布ファイル名、取得日時、提供元のハッシュ値や部品表などの根拠を記録する。ハッシュ値が提供されている場合は取得ファイルと照合する。
3. 3配布物のSBOMや提供元の告知でBrotliの修正を確認する。SBOMはソフトウェアの部品表であり、配布物に含まれる依存ライブラリを確認するための資料。
4. 4承認された試験環境で通常のAPI取得・圧縮レスポンス処理を確認し、既存の運用手順で更新する。DLLを一つだけ別の場所から拾って置き換える手順にはしない。
5. 5サービスを所定の手順で再起動・再配備し、起動元と配置先を確認する。取得済みのZIPが修正版でも、古いフォルダーからワーカーが動いていれば対応完了とはしない。

公式Windowsダウンロードは、FastCGIやCLIではNTS、Apacheのモジュールとして使う場合はTSという選び方を説明しています。今回の修正を理由にTS／NTSやCPUの種類まで無計画に変えず、既存構成に合う配布物を選びます。 8.3.36-1と8.2.35-1の配布ファイルは、同ページからリンクされたWindows Archivesでも確認できます。古い未修正版と取り違えず、末尾の-1を含む対象配布物を選んでください。

編集部は8.5.12-1・NTS・x64の公式SPDX部品表を取得し、Brotli 1.2.1の記載を確認しました。これは一つの配布物の部品表を確認した結果です。Windows実機でのインストール、修正の耐性試験、全配布物の実ファイル検査を行ったものではありません。

Linuxのディストリビューション版や、PHPを同梱する製品へ、このWindows用の番号をそのまま当てはめないでください。それぞれの配布元の修正告知・パッケージ番号・Brotliの組み込み方法を確認します。また10月23日付のセッション処理に関するPHP公式案内は別件です。Windowsの依存部品更新を理由に、既存の暫定設定を戻さないでください。

JPCERT/CCの10月26日付注意喚起も、Node.js以外にBunやPython向けBrotliパッケージなどを含めて点検するよう案内しています。今回のPHP追報は、同じ部品の問題が別製品へ及ぶ具体例です。自社が管理する製品ごとに影響を確認し、必要なら既存ログなどで侵害の有無を調査します。ログに異常がないことだけを、未侵害や修正済みの証明にはしません。

緊急度は、Google CNAが公表したBrotliのCVSS v4.0 9.2と、外部データがデコーダーへ到達するかを合わせて判断します。PHPチームがこのWindows再配布版に独自の数値評価を出したとは扱いません。自動展開の停止を検討する場合も、別の取得経路やライブラリの動作が残り得るため、検証を伴う一時的な露出低減として扱い、更新の代わりにしません。

下表の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日。最新追記確認日：10月28日朝（日本時間）。10月27日付のCISA KEV追加を確認し、悪用状況、優先順位、過去の侵害調査との区別、LLM指示文を更新しました。Node.js・Brotliの修正版とPHP Windows再配布版の説明は引き続き掲載しています。版表示コマンドの初回動作確認と公式部品表の確認以外に、実環境の更新・攻撃再現・同梱製品の耐性試験は行っていません。点検・回帰確認の手順は編集上の提案です。