Node.jsがBrotliのRCEなどを修正｜CIと本番のランタイムを更新する

Node.jsプロジェクトは2026年10月21日、22・24・26系のセキュリティ更新を公開しました。修正版は22.23.4、24.22.1、26.12.1です。Brotliデコーダーの境界外書き込みによるリモートコード実行（RCE）や、DNS・TLSの検証、乱数キャッシュ、Permission Modelに関する修正が含まれます。公式告知が示す今回の最高深刻度はHighです。

Node.jsをWebサーバーとして使う環境だけでなく、外部データを取得するバッチ、SSRの実行環境、CIのビルドイメージ、開発端末も棚卸しの対象になります。ただし、Node.jsが入っているすべての環境で同じ攻撃経路が成立するとは限りません。利用しているAPIと外部入力の到達経路を確認しながら、まず現在の系列に対応する修正版へ更新してください。

本稿は2026年10月22日にNode.js公式セキュリティ告知（2026年10月21日）と各配布ページを直接確認したニュースです。更新は予定段階ではなく、すでに公開されています。確認した資料では実環境での悪用状況と各問題のCVSS数値を確定できなかったため、悪用中・未悪用の断定や数値の補完は行っていません。以下の更新順序と試験例は本サイトからの運用提案です。

22・24・26系で更新先を確認する

現在の系列	今回の修正版	公開時の位置付け
22.x	22.23.4	LTS
24.x	24.22.1	LTS
26.x	26.12.1	Current

各系列の配布物と変更はNode.js 22.23.4リリースノート、Node.js 24.22.1リリースノート、Node.js 26.12.1リリースノートで確認できます。安全対策のために、22系のサービスを検証なしで26系へ飛ばす必要がある、という意味ではありません。対応する修正版を適用する作業と、メジャー系列を移行する作業は分けて計画します。

一方、サポートが終了した系列は今回の三つの配布先に含まれません。公式のNode.js公式リリース系列とサポート状況では20系もEOLとされています。古いランタイムを継続利用している場合は、OSや委託先が修正を提供しているかを確認し、サポート中の系列への移行を進めます。配布元がバックポートしている環境では、上流の版番号だけでなくパッケージの修正履歴を根拠に適用を判断します。

BrotliのRCEは解凍する経路を先に点検する

CVE-2026-111497はNode.jsのBrotliデコーダーにおける境界外書き込みで、公式告知はRCEにつながる問題と説明しています。対象は22・24・26系です。公開資料から攻撃の詳細条件をすべて確定できるわけではないため、「Webサーバーを起動しているだけで必ず侵入される」などと広げて解釈しないことが大切です。

点検では、外部の圧縮データをNode.js自身が解凍する場所を探します。Node.js Zlib公式ドキュメントはBrotliの圧縮・解凍APIを提供し、HTTP応答のContent-Encodingに応じてBrotli解凍へ接続する例も示しています。外部サイトの取得、データ同期、アーカイブ処理など、画面から見えない経路も調べてください。

実務上は、解凍を直接呼ぶコードだけでなく、HTTPクライアントやフレームワークが内部で呼ぶ処理も確認します。フロントのCDNやリバースプロキシが圧縮を扱っていることと、Node.js側に解凍処理がないことは同じではありません。アプリの依存ライブラリー、設定、入力形式から到達経路を追います。

更新までに必要な暫定対応として、対象経路への外部入力や不要な圧縮形式を制限できるかは検討できます。ただし、それは自社の経路を狭める措置であり、今回の複数の問題を一括して修正する方法ではありません。特定ヘッダーの除去だけで全環境が安全になったと判断せず、ランタイム更新を完了させます。

DNSとTLSは外向き通信の検証も必要

CVE-2026-105482はNUL文字を含む名前をdns.resolveが切り詰める問題です。TLSでは、全角数字で書かれたIPアドレスに関するCVE-2026-105483が24・26系に、IPアドレスとして緩く解釈されるホスト名に関するCVE-2026-106069が22・24・26系に影響します。非正規のIPv4ホスト名に対する証明書検証のCVE-2026-106072も修正対象です。

これらは受信側のポートだけを調べても把握できません。Node.jsから決済、在庫、ストレージ、Webhook送信先などへ接続する処理を洗い出します。入力されたホスト名の形式、URL解析、DNS解決、証明書の名前確認を同じ前提で扱えているかを点検する必要があります。

更新後の試験では、通常のDNS名と正規のIP表記への接続が継続できることに加え、証明書と宛先が一致しない通信を拒否することを確認します。検証の失敗を回避するためにrejectUnauthorizedを無効化したり、証明書検証を常時成功させたりすると、更新の目的を損ないます。自社のテスト用証明書と隔離した環境で、成功と拒否を両方確かめます。

乱数を使う配布物は再生成まで確認する

CVE-2026-106074は、crypto.randomUUID()とrandomInt()のエントロピーキャッシュがユーザーランドの起動スナップショットやSingle Executable Applications（SEA）へ保存され、各プロセスで同じ値を繰り返す問題です。対象は22・24・26系です。通常のすべての乱数呼び出しが必ず同じ値になる、という説明ではありません。

スナップショットやSEAを配布しているチームは、ビルド用Node.jsを更新した後、成果物を作り直し、複数プロセスで起動して生成値を比較する試験を追加します。ビルドマシンだけを更新し、過去に生成した実行ファイルを配り続けると、再生成の確認が抜けます。成果物に埋め込まれたランタイムと生成条件を対応付けて管理してください。

もし自社で値の重複を確認したなら、その用途も調べます。単なる表示用IDなのか、認証や招待、復旧などの判断に関係する値なのかで対応は変わります。必要に応じて重複排除、再発行、失効を検討しますが、すべてのサービスで同じ影響が出たと推定して一律に認証情報を作り直すのではなく、実装と記録を確認します。

Permission Modelの修正と隔離の限界

今回の更新には、26系のワイルドカード検索によるファイルシステム権限の過剰付与（CVE-2026-106071）と、22・24・26系のfs.realpathSyncに関する回避（CVE-2026-106073）も含まれます。許可パスを使って動作を制限しているバッチやツールでは、更新後も許可すべき操作と拒否すべき操作をテストしてください。

Node.js Permissions公式ドキュメントは、Permission Modelが信頼したコードの意図しない資源アクセスを抑える仕組みであり、悪意あるコードに対する安全性を保証しないと明記しています。未知のコードを実行するサービスでは、OSの実行ユーザー、ファイルのマウント、ネットワーク、資格情報の分離も必要です。修正の適用を、任意コードを同一プロセスで安全に実行できる保証へ読み替えないようにします。

ほかにも、送信前に書かれた応答をKeep-aliveソケットが処理するCVE-2026-105481と、26系のZipFileで無効なZIPヘッダーを検証した後のデータに関するCVE-2026-106070が告知されています。直接使っていないと判断した機能があっても、依存ライブラリーを含めた確認が終わるまでは更新対象から外さない運用が現実的です。

本番とCIで実際に動くNode.jsをそろえる

最初に、サービス名、配置場所、Node.jsの系列、実行ファイルのパス、管理者を一覧にします。SSR、API、定期実行、キューワーカー、CI、開発用コンテナ、開発端末を分けます。一台に複数の版がある場合、管理者のシェルとsystemdやプロセスマネージャーが別の実行ファイルを使っていないかも確認します。

node --version
node -p 'JSON.stringify({node:process.version,execPath:process.execPath,versions:process.versions},null,2)'

これは自社環境でランタイム情報を確認する例です。Node.js Process公式ドキュメントによると、process.versionsはNode.jsと依存コンポーネントの版を返します。ただし、管理シェルでこのコマンドが成功しただけでは本番プロセスの更新を証明できません。実際のコンテナやサービスの起動時にも記録し、全レプリカの情報を確認します。診断結果を外部公開する必要はありません。

コンテナではベースイメージを更新して再ビルドし、新しいイメージの識別子を確認して再デプロイします。長時間動くワーカーも置き換え、旧コンテナが待機系や別リージョンに残っていないかを調べます。CIではジョブごとのセットアップ指定とキャッシュを点検し、ビルド用と実行用が異なるマルチステージ構成では両方を確認します。

npmパッケージの更新やnpm auditだけで、Node.js本体に同梱されたBrotli、証明書、OpenSSLなどの修正が適用されたとは判断できません。今回はc-ares、Undiciなども含むランタイム側の更新です。Node.jsの配布元、コンテナベース、マネージドサービスの更新方法に沿って作業し、ライブラリーのロックファイルとは別に適用を記録します。

更新完了は再起動と拒否系試験まで

• 現在の系列に対応する修正版をステージングへ適用し、通常のAPI・SSR・バッチの回帰試験を行う
• 圧縮データの取得・解凍、外向きTLS接続、許可パスと禁止パス、スナップショット配布物を利用範囲に合わせて検証する
• 段階的に本番へ展開し、全プロセス・コンテナを新しいランタイムで起動し直す
• 稼働中の版、イメージ識別子、対象数、確認日時を残し、待機系とCIを含めて更新漏れを照合する
• 起動失敗、TLSエラー、解凍エラー、処理遅延を監視し、異常があれば担当者が調査できる記録を残す

ロールバックが必要なときも、脆弱な旧版へ戻したまま公開を続けることを既定にしないでください。機能の停止や入力経路の制限を含めた一時対応と、修正版での復旧手順を同時に用意します。パッケージが更新されたこと、プロセスが新しく起動したこと、業務が動くことの三つを、それぞれ確認して完了とします。

関連記事

• コマンドインジェクションを防ぐ実装｜シェルを外した後も確認する引数と権限（外部処理に与える権限と資源上限の設計）
• AIが追加したnpmパッケージは安全？依存関係とCIを守るサプライチェーン対策