Node.jsが11/11前後にセキュリティリリース予定｜22・24・26に重大修正、いま準備を

Node.js が、2026年11月11日（水）またはその直後に、22.x・24.x・26.x の3つのリリースラインでセキュリティアップデートを出すと事前告知した。各ラインに少なくとも1件の重大（critical）な問題の修正が含まれるという。ただし現時点で分かっているのはそこまでで、脆弱性の数・CVE・影響コンポーネント・修正版・攻撃手法は未公表だ。だからこの記事の役目は「怖がらせる」ことではなく、公開されたら即適用できるように準備しておくことの後押しにある。あわせて、10月に修正済みの Node2Shell（CVE-2026-111497） と混同しないよう整理する。土台の考え方は サプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説 も参照。

# まず自分の使っているラインを知る
node -v        # 例: v24.22.1 なら 24系

何が告知されたのか——11/11前後に22・24・26へ

事前告知の価値は、攻撃者と防御側の時間差を縮めることにある。修正が公開された瞬間は、差分から脆弱性を逆算されやすい最も危ない瞬間でもあるので、「公開日が近い」と分かっているだけでも、チームは適用の段取りを先に組める。今回告知されたのは次の点だ。

• 対象は Node.js 22.x・24.x・26.x の3ライン。
• 各ラインに 1件以上の重大（critical）修正が含まれる。
• 目標日は 2026-11-11（水）前後。公開期限ではなく目標日。
• 未公表：脆弱性の数、CVE 識別子、影響コンポーネント、修正版の番号、攻撃手法、悪用の有無。

ここで大事なのは、未公表の部分を埋めにいかないことだ。「RCE が可能」「データが盗まれる」「この設定で回避できる」といった具体的な主張は、詳細が出るまでは公開情報の範囲を超える。やるべきは、出てからすぐ動けるようにしておくことである。

混同しない：Node2Shell（CVE-2026-111497）は10月に修正済み

11月の予定とよく一緒に語られるのが、10月に表面化した Node2Shell だ。これは別件で、すでに修正されている。混ぜて数えると「11月のセットに Brotli の既知RCEが含まれる」といった誤解が生まれるので、分けて押さえる。

Node2Shell（CVE-2026-111497）は、Node.js にバンドルされた Brotli デコーダの境界外書き込みだ。GitHub の報告（GHSA-9v8h-qqgm-4m35）では深刻度 Critical とされ、同じ不具合は PyPI の Brotli パッケージや .NET など複数言語の Brotli 実装にも及んだ。デコーダが無効なブロックスイッチを「永続的なエラー」ではなく「入力の要求」として誤って扱い、8バイトの内部バッファを超えてバイトを書き続けてしまう——アプリの動作次第で、クラッシュ・プロセスメモリの漏えい、場合によってはリモートコード実行につながりうる、という内容だ（node:zlib で悪意ある Brotli データを解凍する経路）。

重要なのは、これが 2026-10-21 の v22.23.4 / v24.22.1 / v26.12.1 で修正済みという点だ。GitHub の各リリースには「This is a security release」と (CVE-2026-111497) deps: brotli … の記載があり、同じ10月のリリースでは TLS・DNS・圧縮まわりの個別修正（証明書チェック・名前解決・圧縮データ処理）も入っている。11月の予定セットの『確定した脆弱性』として数えないこと。 すでに10月版へ上げていれば、Node2Shell は対処済みだ。

いま準備すること

詳細が出ていない今できるのは「出た瞬間に動ける状態」を作ることだ。順番はこうなる。

自分の環境を確認する

まず使用ラインを特定する。アプリ本体だけでなく、CI・コンテナ・ビルドイメージの Node も対象だ。

# 実行中のライン
node -v

# CI / コンテナで固定している版（.github/workflows・Dockerfile・.nvmrc 等）
grep -rnE "node-version|FROM node:|nvmrc|^v?[0-9]+" .github .nvmrc Dockerfile 2>/dev/null | grep -iE "node|^\.nvmrc"

# package.json の engines（要求している Node 範囲）
grep -nE "\"node\"" package.json

表示された版が 22 / 24 / 26 のいずれかなら、11/11 の対象になりうる。ただし、この確認でわかるのは「どのラインを使っているか」だけだ。11/11 の詳細はまだ無いので、この結果だけでは安全とは言えないし、重大度を見積もることもできない（判定ではなく「どのラインか」の確認）。あくまで「どのラインの更新を待ち受ければよいか」を切り分けるための確認である。

見落としやすいのは、アプリ本体より CI・コンテナ・サーバーレスなどの実行基盤側の Node だ。FROM node:24-slim のようにベースイメージのタグで固定している場合、そのタグが指す実体が 11/11 以降の修正版に動いても、イメージを引き直す（再ビルドする）まで手元は変わらない。Dockerfile のタグ、.nvmrc、GitHub Actions の node-version、サーバーレス（Lambda 等）のランタイム設定を一つずつ棚卸しし、「どこで版が決まっているか」を先に把握しておくと、修正版が出てからの適用が速い。EOL（サポート終了）の版を使っている場合は、ここで移行の検討も始めたい。依存更新を通知頼みにしないための仕組みは Renovate・Dependabotでサプライチェーン更新に自動追従する が参考になる。

サポート状況と、EOLでも油断できない理由

Node.js は、セキュリティリリース時にサポート終了バージョンにも影響が出ることを警告している。「パッチ一覧に自分のブランチが載っていない＝安全」ではない。むしろ、サポート外のまま使い続ける方がリスクで、公式も最新のサポート対象リリースを使うことを推奨している。

2026-11-05 時点の表記では、26.x が Current（最新）、24.x（Krypton）と 22.x（Jod）が LTS だ。メンテナンス対象のブランチでもセキュリティアップデートは引き続き提供される。各ブランチの EOL（サポート終了日）は動くので、導入計画では公式のリリーススケジュールでサポート状況と終了日を確認してほしい。直近の最優先事項は派手な対策ではなく、どのラインを使っているかを特定し、11/11 のアップデートをテストする準備を整えておくことだ。

影響範囲（現時点で言えること）

• 11月の予定セット：対象は Node.js 22.x・24.x・26.x の各ライン。各ラインに1件以上の重大修正を含むが、影響を受ける具体的な条件・コンポーネント・修正後のバージョンは公開後に確定する（現時点では未公表）。EOL 版も影響しうるため「載っていない＝安全」ではない。
• 別件の Node2Shell（CVE-2026-111497）：影響するのは 22.23.4 / 24.22.1 / 26.12.1 未満で、それ以上で解消済み。node:zlib で信頼できない Brotli データを解凍する経路が条件で、解凍を行わないアプリは露出が小さい。

事前告知の段階で過度に身構える必要はないが、「使用ラインの特定」と「上げられる状態の準備」だけは、詳細が出る前にやっておく価値がある。差分が公開された直後が最も危ないタイミングだからだ。先に Firebase の証明書更新 で触れたのと同じく、「ライブラリやランタイムを上げる」対応は、ユーザーに届くビルドまで反映して初めて完了する点も忘れないでおきたい。

参照ソース

• Node.js v22.23.4 リリース（GitHub・2026-10-21）（「This is a security release」・CVE-2026-111497 の一次記載。24.22.1 / 26.12.1 も同日）
• GHSA-9v8h-qqgm-4m35（Node2Shell・Brotli OOB write・Critical）（CVE-2026-111497 のアドバイザリ）
• Node.js リリーススケジュール（nodejs/Release）（各ラインの LTS/Current・サポート終了日）
• Node.js セキュリティ情報（公式）（11/11 前後の事前告知と、公開後の CVE・修正版。最新は公式で確認）