まだNode.js 20をお使いですか？11月11日のセキュリティリリースではパッチが提供されません

2026年11月11日に予定されているセキュリティリリースにおいて、Node.js 20向けのアップデートは一切提供されません。Node.js 20は2026年4月30日にサポート終了（EOL）を迎えており、今回のセキュリティリリースの対象は26.x、24.x、22.xのみです。最後のパッチは3月24日にビルドされた20.20.2でした。それ以降、20.x向けビルドが提供されないまま33件ものCVEがリリースされています。今週中にNode.js 24または26へ移行してください。

今すぐApidogを試す

これらのCVEは、Node.js 20を除外した過去3回のセキュリティリリースで公表されたものです。そして数日後には4回目のリリースが控えており、その事前告知（pre-announcement）では、サポート対象の全系統において最も深刻な脆弱性の重要度が「HIGH（高）」と評価されています。

11月11日のセキュリティリリースとNode.js 20が対象外となる理由

Node.jsプロジェクトは、2026年11月11日（水）またはその直後に、26.x、24.x、22.xの新規ビルドをリリース予定です。ビルドが正式に公開されるまで、CVEの詳細は非公開となっています。なお、ランタイムのインベントリ確認やパッチ適用当日のコマンドについては、こちらの11月リリースに向けたカウントダウンガイドで解説しているため、本記事では割愛します。

Node.js 20が対象外となっている理由は、プロジェクトによるメンテナンスがすでに終了しているためです。End-of-Life（サポート終了）ページには、「同様の脆弱性がEOLを迎えたリリース系統に影響する場合でも、それらに対して新しいリリースが提供されることはない」とはっきりと記載されています。

さらに、同アドバイザリには見過ごせない一文も記されています。「セキュリティリリースが実施される際、EOL（サポート終了）バージョンは常に影響を受ける」という点です。

Node.js 20が見逃してきた未適用のセキュリティ修正

Node.js 20がEOLを迎えて以降、すでに3回のセキュリティリリースが実施されましたが、いずれも20.x向けビルドはリリースされていません。

これらの修正が及ぶコードは、APIサーバーが日常的に実行し続けている処理そのものです。

• TLSホスト名検証： 6月と10月のリリースでは、異なるホストの証明書が誤って受け入れられてしまう脆弱性が修正されました。
• HTTP/2： 7月の重要度「High」の修正には、ヒープのUse-After-Freeやリモートからのメモリ枯渇につながるバグが含まれています。
• DNS： 10月のリリースでは、dns.resolve*()がNULバイトでホスト名を切り詰めてしまい、許可リスト（アローリスト）の検証をすり抜ける問題が修正されました。
• 圧縮処理： 10月のリリースでは、リモートコード実行（RCE）につながる恐れのあるBrotliデコーダーの範囲外書き込み（Out-of-bounds write）が修正されました。詳細はBrotli RCEの検証記事で解説しています。

このリストを注意深く確認してください。Node.jsプロジェクトはEOLを迎えた系統の評価を行わないため、アドバイザリにはサポート対象のバージョンのみが記載されます。もちろん、これらのバグの一部はNode.js 20には含まれていないコードに起因する場合もあります（例えば10月のCVEの1件は、26.xおよび24.xのみに影響するリグレッションでした）。つまり、Node.js 20における各CVEの正確なステータスは「未修正かつ未評価」なのです。「安全である」と保証してくれた人はいませんし、今後誰も調査してくれません。

さらに状況を深刻にしているのが、脆弱性の連鎖（バグチェーン）です。10月のDNS修正は6月の修正を補完するものであり、7月の修正もまた6月の別の修正を補完するものでした。新しいパッチはいずれも、まだ適用されていない過去のパッチを前提として積み上げられているのです。

「それでもまだ動いているから大丈夫」という誤解

確かに稼働はします。しかし、それこそが問題なのです。

サポート終了（EOL）を迎えたランタイムであっても、突然クラッシュするわけではありません。node -vを実行すればこれまで通りバージョンが表示され、テストも通り、ダッシュボードのアラートも正常（緑色）のままです。しかし、リスクは目に見えないところで確実に顕在化しています。

• パッチそのものが攻撃者への見取り図となる： 修正内容、アドバイザリ、コミット履歴は同時に一般公開されます。そのため、サポート対象バージョンで何が変更されたかを誰でも正確に把握でき、同様のコードがNode.js 20に存在するかどうかを調べることが可能です。
• プラットフォーム上ではデプロイが継続できてしまう： AWS Lambdaでは2026年4月30日にnodejs20.xが非推奨（deprecated）となりましたが、関数の新規作成がブロックされるのは2027年7月29日、関数の更新がブロックされるのは2027年8月31日です。
• パッケージやセキュリティ監査の基準は先へ進む： Node.jsプロジェクトも警告している通り、主要なパッケージは時間の経過とともにEOLとなったバージョンのサポートを順次終了していきます。また、多くの業界標準セキュリティ監査では、メンテナンスされていないランタイムの使用が禁止されています。

移行先の選択：Node.js 22ではなく、24または26を選択すべき理由

最短工数で移行したい場合は今週中にNode.js 24へ移行してください。廃止・削除されたAPIへの対応が可能で、より長期間のサポートを望む場合はNode.js 26を選択しましょう。 Node.js 22は避けるべきです。今回の11月の修正こそ適用されるものの、サポート終了は半年足らずの2027年4月30日であり、来春には再び移行作業に追われることになります。

記載の日付はNode.js公式のリリーススケジュールに基づいています。移行を決定する前に、お使いのプラットフォームの対応状況を確認してください。例えばAWS Lambdaでは、Node.js 26ランタイムはパブリックプレビュー段階にありLambda SLAの対象外となるため、現時点での本番環境向けにはNode.js 24を選択するのがより安全です。

移行手順と主な破壊的変更（ブレーキングチェンジ）

以下の表の内容は、22.0.0、24.0.0、25.0.0、26.0.0の公式リリースノート、およびv22からv24への移行ガイドから抜粋したものです。完全な変更履歴ではなく、APIサービスに影響しやすい項目をまとめたチェックリストです。

特に注意が必要なのがOpenSSLの変更です。自社のコードに手を加えていなくても、連携している古い外部システムとのハンドシェイクが実行時に突然失敗することがあります。

移行作業用のブランチを作成し、.nvmrc、engines、Dockerfile、CIの設定を移行先バージョンに更新します（新規環境の場合はNode.jsインストール手順ガイドを参照）。その後、ネイティブモジュールが再ビルドされるよう依存関係を再インストールし、削除されたAPIをスキャンして公式のcodemodを実行したうえで、非推奨の警告トレースを有効にしてサービスを起動します。

nvm install 24 && nvm use 24 rm -rf node_modules && npm ci grep -rnE "assert \{ *type|createCipher\(|createDecipher\(|url\.parse\(|fs\.[FRWX]_OK|SlowBuffer|createSecurePair|_stream_[a-z]+|module\.register\(" \ --include="*.js" --include="*.mjs" --include="*.ts" --exclude-dir=node_modules . npx codemod run @nodejs/import-assertions-to-attributes npx codemod run @nodejs/crypto-createcipheriv-migration npx codemod run @nodejs/tls-create-secure-pair-to-tls-socket npx codemod run @nodejs/fs-access-mode-constants NODE_OPTIONS="--trace-deprecation" npm start 

codemodの実行結果は必ず手動で確認してください。特にcreateCipherに関しては注意が必要で、生成された新しいコードでは旧APIで暗号化されたデータを復号できません。該当するデータが存在する場合は、データ移行計画を立てる必要があります。

Node.js公式サイトには24から26への移行ガイドがまだ用意されていないため、26への移行時は25.0.0および26.0.0のリリースノートを参照してください。

移行前後でAPIが同じように動作することを検証する

単体テスト（ユニットテスト）だけでは、刷新されたTLSスタックやHTTPクライアントが実際のリクエストトラフィックにどのような影響を与えるかまでは検証できません。2〜3つのメジャーバージョンを一度にスキップする場合、稼働中のサービスに対して移行前後の比較テストを実施することが不可欠であり、コーディングエージェントの活用が適しています。

Apidog CLIを使用すると、Claude Code、Codex、Cursorなどのコーディングエージェントから、ターミナル経由でApidogのテストスイートを実行できます。初回セットアップは以下の通りです。

npm install -g apidog-cli@latest apidog login --with-token <YOUR_TOKEN> npx -y skills add https://apidog.com # pick your agent when prompted 

続いて、エージェントに次のようなプロンプトを指示します。

My service runs on Node.js 20 in staging. Run Apidog test suite <suiteId> in project <projectId> against environment <envId> and save reports to reports/node20. When I redeploy on Node.js 24, run the same suite into reports/node24. List every request whose status, body, or TLS behavior changed. Then read the service logs for deprecation warnings and check each failure against the 22, 24, and 25 release notes: removed APIs, changed defaults, stricter fetch and AbortSignal handling, OpenSSL key size rejections. 

エージェントは移行の前後で同じテストスイートを実行します。

apidog run --test-suite <suiteId> --project <projectId> -e <envId> \ -r cli,junit --out-dir reports/node20 # redeploy the service on the target line, restart it apidog run --test-suite <suiteId> --project <projectId> -e <envId> \ -r cli,junit --out-dir reports/node24 

検証の精度を担保するために、以下の2点に注意してください。

• -kオプションは絶対に使用しないこと： このフラグはSSL検証を無効化してしまうため、検出すべきTLSエラーが見落とされてしまいます。
• サービスが行うアップストリームへの呼び出しも含めてテストすること： OpenSSLによる拒否エラーは、古いパートナーシステムに依存するエンドポイントでのAPIエラーとして現れます。そのため、/healthだけでなく、外部通信を伴うエンドポイントも必ずテストしてください。

移行テストをパスしたら、CI/CDパイプラインにそのテストステップを組み込んだまま維持しましょう。ワークフローの構築手順はApidog CLIのCI/CDガイド、エージェントのセットアップ手順はClaude Code活用ガイドで解説しています。

今週中の移行が難しい場合の対処法

パッチ適用済みビルドの商用サポートを利用する： Node.jsのEOLページでは、OpenJS Ecosystem Sustainability Programを通じて3社のパートナーを紹介しています。HeroDevsはセキュリティパッチを含む「Never-Ending Support」を提供し、TuxCareの「Endless Lifecycle Support」はEOLバージョン向けに修正をバックポートしています。また、NodeSourceはアップグレード評価とサポートを提供しています。ただし、プロジェクト側も述べている通り、これらはあくまで一時的な対症療法に過ぎません。

プロセスへの到達経路を絞り込む： 以下の対策により、前述した脆弱性の影響リスクを低減できます（根本的な問題が解決するわけではありません）。

• 適切にメンテナンスされているリバースプロキシやロードバランサーでTLSおよびHTTP/2を終端させ、プライベートネットワーク経由のNode.jsとはプレーンなHTTP/1.1で通信する。
• インバウンドリクエストおよび取得コンテンツの双方において、信頼できない送信元からのBrotli圧縮データの解凍を停止する。
• 許可リストの検証や外部への発信リクエストを行う前に、NULバイトや非正規化されたIP表記を含むホスト名を拒否する。
• サービスの分離を徹底する：最小権限の認証情報の使用、外部向け通信（エグレス）の制限、パッチ適用済みサービスとのシークレット共有の排除。

リスクを明文化する： 「一時的な対応」のまま放置されないよう、責任者、具体的な移行期日、および代替セキュリティコントロールを文書化して定めておきましょう。

よくある質問（FAQ）

Node.js 20は現在もサポートされていますか？ いいえ、サポートされていません。2026年4月30日にサポート終了（EOL）となりました。最終ビルドは2026年3月24日にリリースされた20.20.2であり、今後新しいビルドが提供されることはありません。

Node.js 20は11月11日に修正される脆弱性の影響を受けますか？ 現在のところCVEの詳細は公開されていないため、どの脆弱性が該当するかを断定することはできません。ただし、アドバイザリにはセキュリティリリースの実施時にEOLバージョンは常に影響を受けると明記されており、プロジェクト側がEOLバージョンを個別に調査・評価することはありません。

代わりにNode.js 22へアップグレードすべきでしょうか？ おすすめしません。バージョン差が最も小さいため移行しやすいように見えますが、2027年4月30日にはサポートが終了します。Node.js 24へ移行すればさらに1年間、Node.js 26へ移行すればさらに2年間のサポート期間を確保できます。

Node.js 24と26のどちらを選ぶべきですか？ 今週中に迅速に移行する必要がある場合や、利用中のプラットフォームがNode.js 26をまだ完全サポートしていない場合は24を選択してください。すべてのシステムを今すぐ十分に再テストできる体制があるなら、2029年4月30日までサポートされる26を選択するのが最適です。

現在Node.js 25を使用していますが、影響はありますか？ はい、該当します。Node.js 25は2026年6月1日にEOLを迎えており、25.9.0が最終ビルドです。11月のセキュリティ修正も提供されないため、メジャーバージョンが1つ先となるNode.js 26への移行を推奨します。