fix-node-vuln

Node.js の脆弱性を修正する（2026 年 10 月 21 日のセキュリティリリース、CVE-2026-111497 を含む）

概要

2026 年 10 月 21 日のセキュリティリリースで修正された 10 件の CVE の影響を受ける Node.js ランタイムを特定し、修正します。うち 4 件は深刻度が高く、Brotli デコーダーの境界外書き込みによる RCE（CVE-2026-111497）と、TLS／DNS のホスト名に関する 3 件の問題（CVE-2026-105482、-105483、-106069）が含まれます。修正済みリリースは 22.23.4、24.22.1、26.12.1 です。Node 20 以前はサポート終了となっており、修正は提供されないため、メジャーバージョンのアップグレードが必要です。まず読み取り専用でインベントリを作成します。編集する前に承認を待ちます。承認された各リポジトリにパッチを適用し、ビルド済みアーティファクトを検証して、対象を絞った PR を作成します。

ユーザーに必要な情報

• スキャンするリポジトリまたは組織。デフォルトでは、ユーザーが指定したリポジトリ、またはエージェントがアクセスできるすべてのリポジトリが対象です。
• 検出されたリポジトリのうち、パッチを適用するものの承認と、サポート終了済みメジャーバージョンのアップグレードを対象に含めるかどうか。
• 対象の検証とビルドの実行に必要な、レジストリおよび CI へのアクセス。

手順

1. クローンする前に、Git ホストのコード検索を使って、アクセス可能なすべてのリポジトリを読み取り専用で検索します（検索機能がない場合（GitHub Enterprise Server やセルフマネージドの GitLab ではよくあります）は、浅いクローンを作成し、rg -n --hidden --glob '!.git' を実行します。バージョンファイルはドットファイルであるためです）。次を確認します。
   • マルチステージビルドを含む、node: などの Node ベースイメージ。
   • .nvmrc、.node-version、.tool-versions、Volta の設定、actions/setup-node／CI イメージ。
   • NodeSource または OS の nodejs パッケージ。
   • Serverless のランタイム設定（Lambda の nodejs22.x、Cloud Functions、Azure Functions）。
   • Node をインストールする Helm／Terraform／Ansible のコード。
   • シグナルとしての engines.node。
   • 対象メジャーバージョンで既知の問題が起きるコード（例：import assertions assert {、binding.gyp／node-gyp によるネイティブアドオン、削除された API）と、アップグレードのリスクをゲートで示せるよう、リポジトリのテストコマンド。
2. 1 つのインベントリ表を作成します。列は、リポジトリ、ファイル:行、シグナル、現在のバージョン、チャネル、固定／フローティング／ダイジェストによるピン留め、本番用かビルド／CI 専用か、判別可能な場合はインターネットへの公開状況、テストカバレッジ（なし、薄い、テストスイート）、確信度です。検索できなかったリポジトリは別に列挙します。
3. 各項目を固定済み、脆弱、EOL、または不明に分類します。ディストリビューションのパッケージとマネージドランタイムについては、上流のバージョン文字列との比較ではなく、ベンダーのパッケージ変更履歴またはアドバイザリを確認します。
4. ここで停止します。表を提示し、どのリポジトリを修正するかユーザーに確認します。メジャーアップグレードで想定されるアプリコードの変更点を列挙し、事前にユーザーの承認を得ます。調査中は何も変更しません。
5. 承認されたリポジトリを、1 つずつ作業します。エージェントがサブエージェントに対応している場合は、リポジトリごとに 1 つ割り当て、同時に最大 5 つまで実行します。編集前に、そのリポジトリのインベントリを再確認します。
6. 各リポジトリについて、パスごとに修正済みの最小のターゲットを選び、編集前にそのターゲットが存在することを確認します。公開ホストにアクセスできない場合は、リポジトリの CI で既に使用しているレジストリまたはパッケージミラー（Artifactory、Nexus、Harbor、またはクラウドレジストリ）で確認します。どちらにもアクセスできない場合は、PR でターゲットを未検証と明記し、CI ビルドで確認します。
   • 固定されたイメージタグ：バリアント（-alpine、-slim、-bookworm など）を維持し、同じメジャーバージョンの修正済みパッチバージョンに更新します。
   • ダイジェストによるピン留め：新しいダイジェストを解決してピン留めします。
   • サポート対象のメジャーバージョン内でのフローティングタグ：タグはそのままにします。--pull --no-cache で再ビルドして再デプロイすることを必須とし、新しいダイジェストを記録します。承認済みのメジャーアップグレードでは、リポジトリのピン留め方式を維持します（フローティングはフローティングのまま、固定は固定のまま）。
   • 新しいイメージはすべて、固定タグも含めてマルチアーキテクチャのインデックスダイジェストを記録します。OS レイヤーは引き続き変化するためです。
   • バージョンファイル：修正済みパッチバージョンを設定し、バージョンを指定するすべてのファイルで一貫させます。
   • フローティングバージョン（22、lts/*）を指定した CI の setup-node：check-latest: true を追加するか、修正済みパッチバージョンにピン留めします。そうしないと、ランナーにキャッシュされた古い Node が使われます。
   • マネージド Serverless ランタイム（例：Lambda の nodejs22.x）：プロバイダーは正確なパッチバージョンを公開しないため、プロバイダーの公開ベースイメージ（例：public.ecr.aws/lambda/nodejs:22）を確認するか、関数から process.version をログに出力します。Lambda の Auto runtime-update モードでは、AWS がインプレースで更新するため、再デプロイは更新を早めるだけです。Function update モードまたは Manual モードでは、再デプロイまたはランタイムバージョンの変更が必要です。
7. engines.node は、新しいバージョンを除外する場合（例：20 から 22 へのアップグレードで 20.x を指定しており、npm ci が EBADENGINE の警告を出す場合）を除き、変更しないでください。これは何もインストールしません。
8. Node 20 以前は別に報告し、22 または 24 LTS へのアップグレード経路を示します。メジャーアップグレードはユーザーの承認を得た場合にのみ実施し、その後、手順 9 のメジャーアップグレード向けチェックを適用します。
9. 変更前後に回帰テストを実施します。
   • ベースライン：編集前に、--pull を指定して現在のイメージをビルドし、そのダイジェストを記録します（これがロールバック先です）。イメージ内で npm ci／pnpm install --frozen-lockfile／yarn install --immutable、ビルドスクリプト（ある場合）、テストを実行します。結果を記録し、既存の失敗がアップグレードのせいにされないようにします。
   • 変更後：ホスト上ではなく、新しい本番イメージ内でインストール、ビルド、テストを繰り返します。そのイメージにテストや開発用依存関係が含まれていない場合（マルチステージ、--omit=dev）、同じベースからテスト／ビルダーステージをビルドするか、テストを本番イメージにマウントします。新たな失敗や非推奨警告を回帰として扱います。
   • ランタイムを比較します。node -p process.versions（V8、OpenSSL、ICU など）と、旧イメージと新イメージのベース OS の差分を確認します。外部への TLS 呼び出し（https、fetch、tls.connect）を行うサービスでは、eMudhra CA の削除と、より厳格な OpenSSL のデフォルト設定に留意します。
   • スモークテスト：本番コマンドでコンテナーを起動し、ヘルスチェック用またはメインのルートにリクエストを送信して、ログにクラッシュや警告がないか確認します。
   • メジャーアップグレード（例：20 から 22）では、NODE_OPTIONS=--pending-deprecation を設定したテストの実行、ソースからのネイティブアドオンの再ビルド（npm rebuild）、該当するリリースノートの破壊的変更の列挙（例：Node 22 では import assertions assert { type: 'json' } が削除され、with に置き換わりました）も行います。
   • 各ステップの出力をログ（ベースライン、変更後、ランタイム差分、スモークテスト）として保存し、PR に添付します。
   • リポジトリにテストがない場合、またはテストがわずかしかない場合は、その旨を目立つように記載し、最小限のスモークテストまたは特性テストを提案します（承認なしにコミットはしません）。
   • ビルド済みの本番イメージまたはランタイム内で node -v を確認します。
   • 回帰が発生した場合は、上記の読み取り専用チェックを完了してから停止し、失敗時の出力とスクラッチコピーで検証済みの最小限の修正案を報告します。ユーザーが判断するまで、バージョン変更はコミットせずに残します。承認なしにアプリコードを変更しません。
10. リポジトリごとに、変更前後の各パス、ダイジェスト、再ビルドが必要なフローティングタグ、ブロックされた項目、EOL 項目、変更前後のテスト結果、ランタイム差分、検証の証拠を記載した、焦点を絞った PR を 1 件作成します。リスクを分類します。同じベースでのパッチ更新は低、メジャーアップグレード、ベース OS の変更、または未テストのリポジトリは高です。テストカバレッジが薄い場合はその旨を記載します。フローティングタグについては、今日時点のダイジェストを提示します。ステージングまたはカナリアを先に実施し、その後ロールバック先となる以前のイメージダイジェスト／バージョンに戻すロールアウト計画を含めます。ロールバック先にも脆弱性があるため、ロールバックは短期間に限ります。
11. リポジトリごとの結果を 1 つの表にまとめます。列は、リポジトリ、PR、パス、変更前 → 変更後、本番用か CI 専用か、テスト、ブロックされた項目、フォローアップです。修正はデプロイ後にのみ有効になることをユーザーに伝えます。

仕様

• 調査は読み取り専用で行い、明示的な承認ゲートで終了します。
• 編集前に、対象がすべて存在することを確認します。
• 各 PR には、ビルド済みの本番アーティファクトから取得した node -v の証拠を含めます。CI 専用のパス、バージョンファイル、管理対象のランタイムについては、入手可能な最善の証拠（インストーラーまたはベースイメージで解決されたバージョン）を提示し、マージ後にユーザーが実行する必要のあるチェックを明記します。
• 完了とは、承認されたデプロイがすべて修正済みと確認されるか、具体的な次の手順を添えてブロック中と報告されている状態です。

アドバイスと参考情報

• Brotli を展開するインターネット向けサービス（HTTP クライアント／サーバー、プロキシ、zlib.createBrotliDecompress）を優先します。また、ユーザー指定のホストに接続する TLS クライアントも優先します。
• このリリースでは、同梱の c-ares、OpenSSL（22/24）、SQLite（22）、Undici、CA 証明書（eMudhra の削除）も更新されます。
• Electron アプリ、ベンダーイメージ、アプライアンスには独自の Node が同梱されています。ベンダーによる更新が必要なものとして挙げてください。
• CI 専用の Node は本番ランタイムより優先度が低いものの、低コストで対応できる場合は同じ PR で修正してください。

禁止事項

• ユーザーがリポジトリを承認する前に編集しないでください。
• イメージタグ、ダイジェスト、パッケージバージョンを推測しないでください。
• 明示的な承認なしに Node のメジャーバージョンをアップグレードしないでください。
• 事前に伝えることなく、ベースディストリビューションやイメージの種類を変更しないでください。