Node.js 20 EOL と 3 月の DoS 脆弱性への対処手順

はじめに

2026 年 4 月 30 日、Node.js 20.x 系列が正式に EOL（End-of-Life）に到達しました。これに先立ち、2026 年 3 月 24 日には複数のセキュリティ脆弱性を修正するためのセキュリティリリースが公開され、合計 9 件の CVE（High 2 件、Medium 5 件、Low 2 件）が修正対象となっています。中でも、プロセスをクラッシュさせるリモート DoS の 2 件（CVE-2026-21710 / CVE-2026-21637）は、TLS 処理および HTTP リクエスト処理という Node.js の中核機能に起因する欠陥で、Web サービスを運用する環境では可用性に直結するリスクです。

この時系列が運用上重要な意味を持つのは、Node.js 20.x で運用を続けてきた環境では、3 月リリースで適用した 20.20.2 が最後のセキュリティパッチとなる点です。今後新たに公開される CVE への 20.x 向けの修正は提供されません。すなわち、3 月の脆弱性対応とあわせて、22.x 以降への移行計画も並行して進めることが推奨される状況にあります。

本記事では、2026 年 3 月の Node.js セキュリティリリースで修正された脆弱性のメカニズム、Node.js 20 EOL に伴うサポート体系の整理、WAF / リバースプロキシを活用した多層防御アプローチ、そして 22.x 以降への安全な移行手順までを、運用担当者目線で整理します。

2026 年 3 月の Node.js セキュリティリリースの概要と影響範囲

今回のセキュリティリリースでは、合計 9 件の CVE（High 2 件、Medium 5 件、Low 2 件）が修正対象となりました。修正版は v25.8.2 / v24.14.1 / v22.22.2 / v20.20.2 として公開されています。

修正された 9 件の CVE 一覧

3 月リリースで修正された CVE を整理すると次の通りです。

CVE-2026-21637 は 1 月リリースの不完全な修正

CVE-2026-21637 については、運用上注意すべき経緯があります。本 CVE は 2026 年 1 月 13 日のセキュリティリリースで Medium 評価として一度修正されたものの、その修正が不完全であったため、3 月リリースで再度 High 評価へ昇格して修正されたという経緯を持ちます。1 月リリースでは PSK / ALPN コールバックの例外処理が対象でしたが、SNI コールバックに同じ問題が残存していたためです。

参考: Tuesday, March 24, 2026 Security Releases
“A flaw in Node.js TLS error handling leaves SNICallback invocations unprotected against synchronous exceptions, while the equivalent ALPN and PSK callbacks were already addressed in CVE-2026-21637. This represents an incomplete fix of that prior vulnerability.”
（Node.js の TLS エラー処理に存在する欠陥により、SNICallback の呼び出しが同期的な例外に対して保護されない状態となっていました。同等の ALPN・PSK コールバックは過去の CVE-2026-21637 で既に対処済みでしたが、本件は先行修正の不完全な対応を表しています。）
https://nodejs.org/en/blog/vulnerability/march-2026-security-releases

すなわち、1 月リリースの 20.20.0 / 22.22.0 / 24.14.0 を適用済みであっても、SNI 経路では脆弱性が残存している状態です。3 月リリースの 20.20.2 / 22.22.2 / 24.14.1 / 25.8.2 への更新が改めて必要となります。

対象となるバージョン（20.x〜25.x）と EOL バージョンへの注意喚起

3 月リリース時点で影響を受けるアクティブなリリースラインは、25.x、24.x、22.x、20.x の 4 つでした。

すでにサポートが終了している EOL バージョンに対しては、公式から次のような警告が出されています。

参考: Tuesday, March 24, 2026 Security Releases
“It’s important to note that End-of-Life versions are always affected when a security release occurs. To ensure your system’s security, please use an up-to-date version as outlined in our Release Schedule.”
（セキュリティリリースが発生した場合、サポート終了（EOL）バージョンは常に影響を受けることに注意することが重要です。システムのセキュリティを確保するために、リリーススケジュールに概説されている最新バージョンを使用してください。）
https://nodejs.org/en/blog/vulnerability/march-2026-security-releases

古いバージョンの Node.js を稼働させ続けている環境は、今回の DoS 攻撃に対してパッチが提供されないため、リスクが高い状態に置かれます。

Node.js 20 EOL と移行先の選定

Node.js 20.x は 2026 年 4 月 30 日に EOL（End-of-Life）に到達しました。以降、20.x 系に対するセキュリティパッチは公式から提供されません。3 月リリースの v20.20.2 が、Node.js コミュニティから提供される 20.x 系の最終的なセキュリティ修正となります。

Node.js のサポート体系（2026 年 5 月時点）

Node.js は偶数メジャーバージョンが LTS（Long-Term Support）、奇数メジャーバージョンが Current として位置付けられる体系を取っています。2026 年 5 月時点のサポート状況は次の通りです。

参考: Node.js – End-Of-Life
“When a version reaches End-Of-Life, it means that it will no longer receive updates, including security patches. This can leave applications running on these versions vulnerable to security issues and bugs that will never be fixed.”
（バージョンが EOL に達すると、セキュリティパッチを含むアップデートを受け取らなくなります。これらのバージョンで動作するアプリケーションは、永久に修正されないセキュリティ問題やバグの影響を受け得ます。）
https://nodejs.org/en/about/eol

移行先の選定: 22.x か 24.x か

20.x からの移行先として、現実的な選択肢は 22.x（Maintenance LTS） と 24.x（Active LTS） の 2 つとなります。

短期間で安全に脱出したい既存システムには 22.x が、中期的に運用を続けるシステムの本格的な移行先には 24.x が適切と整理できます。どちらを選ぶ場合も、コード互換性は概ね保たれていますが、24.x への移行では V8 のメジャーバージョン更新に伴いネイティブモジュールの再ビルドが必要となる点に留意が必要です。

移行時の互換性留意点

20.x → 22.x / 24.x への移行時は、次の観点で互換性を確認することが推奨されます。

ネイティブモジュールの再ビルド

bcrypt、sharp、node-sass などの C++ アドオンを利用しているパッケージは、新しい Node.js バージョン向けに npm rebuild または npm ci でのクリーンインストールが必要

依存パッケージの Node.js バージョン要件

package.json の engines.node フィールドを確認し、22.x / 24.x で動作する版にアップデート

AWS SDK for JavaScript v3 の対応状況

AWS SDK は Node.js 20.x EOL の 8 ヶ月後（2027 年 1 月）にサポートを打ち切る方針を公表しており、20.x のまま運用を続けると SDK 側からも切り離される点に留意

Docker base image の更新

node:20-alpine などのベースイメージを利用している場合、node:22-alpine または node:24-alpine への更新が必要

CI / CD パイプライン

GitHub Actions の actions/setup-node@v4 などで node-version 指定をしている場合、対象バージョンを更新

EOL 後の延長サポート選択肢

業務都合で 20.x のまましばらく運用を続ける必要がある環境では、コミュニティ EOL 後も商用ベンダーから提供される延長サポートを検討する余地があります。

これらは EOL 後も独自にセキュリティパッチをバックポートして提供する商用サービスです。移行作業に時間を要する大規模システムや、コンプライアンス要件で短期移行が困難な環境での選択肢として位置付けられますが、根本的な解決にはならないため、並行して 22.x / 24.x への移行計画を進めることが推奨されます。

2 つの High レベル脆弱性（CVE-2026-21637、CVE-2026-21710）の概要

3 月リリースで特に警戒すべき脆弱性は、以下の 2 件です。

CVE-2026-21637（TLS 処理におけるリモート DoS）

TLS サーバのエラーハンドリングに関する欠陥で、_tls_wrap.js の loadSNI() 関数に try/catch が欠落していることが原因です。SNICallback が予期しない入力に対して同期的な例外をスローした場合、その例外が TLS のエラーハンドラを通過し、Node.js プロセスをクラッシュさせる「Uncaught Exception」として伝播します。

このため、エラーイベントリスナーや上位の例外処理では捕捉できません。Node.js 公式アドバイザリも本件を「TLS の処理経路における Remote DoS」として High 評価で分類しています。

CVE-2026-21710（HTTP リクエスト処理における DoS）

__proto__ という名前の HTTP ヘッダーを含むリクエストを受信した際、アプリケーションが req.headersDistinct プロパティを参照すると、Object.prototype への解決が発生し、配列ではないオブジェクトに対して .push() が呼び出されることで TypeError が発生します。

参考: Tuesday, March 24, 2026 Security Releases
“This exception is thrown synchronously inside a property getter and cannot be intercepted by error event listeners, meaning it cannot be handled without wrapping every req.headersDistinct access in a try/catch.”
（この例外はプロパティゲッター内で同期的にスローされ、エラーイベントリスナーによってインターセプトできないため、すべての req.headersDistinct アクセスを try/catch でラップしない限り処理できません。）
https://nodejs.org/en/blog/vulnerability/march-2026-security-releases

どちらの脆弱性も、攻撃者が細工したリクエストを外部から送信するだけでサーバプロセスを強制終了させられるという点で、サービスの可用性に直結するリスクとなります。

DoS 攻撃のメカニズムとインフラ層を含む多層防御アプローチ

3 月リリースで修正された CVE-2026-21637 / CVE-2026-21710 は、いずれもアプリケーションコード側の例外処理（try/catch など）をすり抜けて Node.js プロセス自体を終了させる構造を持ちます。修正版へのアップグレードが根本対処ですが、アップグレード完了までの期間のリスクをさらに下げるための対策として、インフラ層での多層防御が有効な選択肢となります。

__proto__ ヘッダー攻撃と TLS エラーハンドリング欠陥の手口

CVE-2026-21710 の攻撃を例にとると、__proto__ ヘッダーを含むリクエストが届いた時点では Node.js は正常に動作しますが、アプリケーションが req.headersDistinct を参照した瞬間に、内部でオブジェクトプロトタイプの予期せぬ解決が発生し、TypeError が同期的にスローされてプロセスが停止します。

CVE-2026-21637 の方は TLS の SNI（Server Name Indication）解決時に攻撃者が細工した値を送り込むことで、SNICallback が同期例外をスローし、Node.js プロセスがクラッシュする構造です。いずれもコード側の修正ではプロセスダウンを防げない点が、これらの脆弱性を High 評価としている根拠です。

Nginx / WAF による __proto__ ヘッダーの遮断

修正版へのアップグレードが完了するまでの暫定対処として、前段の Nginx / WAF / リバースプロキシで __proto__ ヘッダーを含むリクエストを破棄する運用が有効です。

Nginx 設定例（http または server ブロック内）

# __proto__ ヘッダーを含むリクエストを 400 で破棄
if ($http___proto__) {
    return 400;
}

Nginx の変数命名規則では、HTTP ヘッダー名のハイフンとアンダースコアは内部的にアンダースコアに変換されるため、$http___proto__ で __proto__ ヘッダーを参照できます。

なお、Nginx はデフォルトで underscores_in_headers off（アンダースコアを含むヘッダーを許可しない設定）となっているケースがあるため、本件のような攻撃ヘッダーが既に弾かれている環境もあります。underscores_in_headers の現在の設定値を確認し、off であれば既に防御が成立している可能性があります。

参考: Nginx Documentation – underscores_in_headers
https://nginx.org/en/docs/http/ngx_http_core_module.html#underscores_in_headers

AWS WAF / Cloudflare WAF でのアプローチ

クラウド WAF を利用している環境では、HTTP ヘッダー名に __proto__ という文字列を含むリクエストをブロックするカスタムルールを追加することで対処できます。各 WAF のルール構文は異なりますが、HTTP Header Name contains __proto__ という条件で Block アクションを設定する形が共通アプローチとなります。

TLS 終端のオフロードによる CVE-2026-21637 のリスク軽減

TLS 処理（CVE-2026-21637）については、Node.js プロセス自体に TLS 終端を担わせるアーキテクチャを見直す方法も効果的です。前段のロードバランサー（ALB / NLB、Nginx、HAProxy 等）で TLS 終端（SSL オフロード）を行い、Node.js は平文 HTTP のみを受け取る構成にすることで、TLS 処理経路を持たない状態となり、本件のような TLS 起因の DoS リスクをネットワーク層で軽減できます。

ただし、TLS 終端のオフロードはセキュリティ責任分界の変更を伴うため、エンドツーエンド暗号化のポリシーや、ALB / NLB の HTTPS 経由でのバックエンド通信などの構成方針との整合を確認した上で適用することが推奨されます。

実稼働環境における Node.js アップデートのベストプラクティス

Node.js のアップデートは、アプリケーションの依存パッケージに影響を与え得るため、計画的な手順を踏むことが推奨されます。本セクションでは、Node.js 20.x から 22.x / 24.x への移行を想定した実務的な手順を整理します。

バージョン管理ツールの選定（nvm / Volta / fnm の比較）

OS の標準パッケージマネージャー（apt / yum 等）で直接 Node.js を上書きするのではなく、専用のバージョン管理ツールを利用する運用が推奨されます。代表的な 3 つのツールの特徴を整理します。

個人開発や既存運用との互換性重視であれば nvm、チーム開発でプロジェクト単位のバージョン固定を強制したい場合は Volta、シェル起動の体感速度を重視するなら fnm が、それぞれの判断基準となります。

nvm を用いた 22.x / 24.x への移行手順

nvm を使って Node.js 22.x へ移行する手順例は次の通りです。

# 利用可能な 22.x のバージョンを確認
$ nvm ls-remote 22

# Node.js 22.x の最新版をインストール
$ nvm install 22.22.2

# インストールしたバージョンへ切替
$ nvm use 22.22.2

# デフォルトバージョンとして設定（新規シェルで自動的に有効化）
$ nvm alias default 22.22.2

# 現在のバージョンを確認
$ node -v
v22.22.2

24.x へ移行する場合は、同じ手順で nvm install 24.14.1 のように指定します。.nvmrc ファイルをリポジトリのルートに配置することで、プロジェクトごとの利用バージョンを明示化できます。

参考: nvm – Node Version Manager
https://github.com/nvm-sh/nvm

パッチ適用前の依存関係確認と検証

3 月のセキュリティリリースには、Node.js 本体の修正だけでなく、内部で利用されている undici などの主要な依存モジュールのアップデートも含まれています。

参考: Tuesday, March 24, 2026 Security Releases
“This security release includes the following dependency updates to address public vulnerabilities: undici（6.24.1, 7.24.4）on 22.x, 24.x, 25.x”
（このセキュリティリリースには、公開された脆弱性に対処するための以下の依存関係の更新が含まれています: 22.x、24.x、25.x での undici（6.24.1、7.24.4））
https://nodejs.org/en/blog/vulnerability/march-2026-security-releases

本番環境へデプロイする前に、ステージング環境で次の手順による検証を行うことが推奨されます。

# 1. 対象バージョンへの切替
$ nvm use 22.22.2

# 2. npm 自体の更新（必要に応じて）
$ npm install -g npm@latest

# 3. node_modules を完全に削除してクリーンインストール
$ rm -rf node_modules package-lock.json
$ npm install

# 4. ネイティブモジュールの再ビルド（C++ アドオンを利用している場合）
$ npm rebuild

# 5. 脆弱性スキャン
$ npm audit

# 6. テストスイートの実行
$ npm test

特にnpm rebuild の実行は、ネイティブモジュール（bcrypt、sharp、canvas 等）を利用している環境では忘れがちな手順で、再ビルド漏れがあると本番デプロイ時に動作不良を起こします。

コンテナ環境での Node.js 更新

Docker / Kubernetes 環境で Node.js を運用している場合、ベースイメージのタグを更新する形で対応できます。

# 変更前
FROM node:20-alpine

# 変更後（Maintenance LTS）
FROM node:22-alpine

# または（Active LTS）
FROM node:24-alpine

CI でビルドキャッシュを利用している場合、--no-cache オプションでクリーンビルドを行うことで、古いベースイメージの残存を排除できます。

脆弱性の影響確認とパフォーマンス監視

3 月リリースには、単一のリクエストによるクラッシュ（CVE-2026-21710）だけでなく、大量のリクエストでリソースを枯渇させる HashDoS やメモリリークの脆弱性も含まれています。

アプリケーションが影響を受ける条件の洗い出し

すべての Node.js アプリケーションが等しくリスクに晒されているわけではありません。自社のコードベースに対しては、次のような観点で影響範囲を洗い出すことが有効です。

req.headersDistinct 参照箇所の検出（CVE-2026-21710）

$ grep -rn "headersDistinct" --include="*.js" --include="*.ts" .

該当ヒットがあれば、その処理経路が CVE-2026-21710 の直接的な悪用対象となります。Express ミドルウェアやサードパーティの HTTP ハンドラ内部で利用されているケースもあるため、依存パッケージのソースコードまで対象に含めて確認することが推奨されます。

TLS の SNI / PSK / ALPN コールバック実装箇所の検出（CVE-2026-21637）

$ grep -rn -E "SNICallback|pskCallback|ALPNCallback" --include="*.js" --include="*.ts" .

TLS 終端を ALB / Nginx などの前段に任せる構成であれば、Node.js 側でこれらのコールバックを実装していないため、CVE-2026-21637 の直接的な影響は低くなります。

JSON.parse() の利用箇所と入力サイズ制限の確認（CVE-2026-21717）

$ grep -rn "JSON.parse" --include="*.js" --include="*.ts" .

参考: Tuesday, March 24, 2026 Security Releases
“The most common trigger is any endpoint that calls JSON.parse() on attacker-controlled input, as JSON parsing automatically internalizes short strings into the affected hash table.”
（最も一般的なトリガーは、攻撃者が制御する入力に対して JSON.parse() を呼び出すエンドポイントです。JSON の解析により、短い文字列が影響を受けるハッシュテーブルに自動的に内部化されるためです。）
https://nodejs.org/en/blog/vulnerability/march-2026-security-releases

JSON.parse() を利用している箇所のうち、特に外部からのリクエストペイロードを直接処理しているエンドポイントが要確認です。Express の express.json({ limit: '...' }) でペイロードサイズ制限を設定していない場合、巨大な JSON が攻撃ベクターとなる可能性があります。

Node.js プロセスの CPU / メモリ異常を検知するための監視設計

DoS 攻撃は予測不可能なタイミングで発生します。HTTP/2 のメモリリーク（CVE-2026-21714）や HashDoS によるパフォーマンス低下を早期に検知するためには、インフラ層でのオブザーバビリティ（可観測性）の確保が有効です。

Datadog、New Relic、Prometheus / Grafana などの APM ツールを活用し、次の指標を監視することが推奨されます。

異常を検知した際に自動的にアラートを発報し、該当コンテナ（Pod）の切り離し / 再起動を行う監視設計を導入することで、パッチ適用前であっても被害の拡大を抑えられます。

Node.js 内蔵の perf_hooks モジュールの monitorEventLoopDelay() API は、Event Loop Lag の取得に有用です。APM ツールを別途導入していない環境では、本 API を使ったカスタム監視を組む選択肢もあります。

まとめ

本記事では、2026 年 3 月の Node.js セキュリティリリースで修正された 9 件の CVE と、4 月 30 日に EOL を迎えた Node.js 20 系への対応について整理しました。

• Node.js 20.x は 2026 年 4 月 30 日に EOL に到達。今後の新規 CVE への 20.x 向け修正は提供されないため、22.x / 24.x への移行が推奨される。
• 3 月リリースで修正された High 評価の DoS 脆弱性 2 件（CVE-2026-21637 / CVE-2026-21710）は、いずれも try/catch を使ったアプリ側の例外処理で防げない構造の Uncaught Exception を引き起こす。
• CVE-2026-21637 は 1 月リリースの不完全な修正であり、1 月の Medium 評価から 3 月の High 評価へ昇格。1 月リリース適用済みでも改めて 20.20.2 / 22.22.2 / 24.14.1 / 25.8.2 への更新が必要
• 暫定対処として Nginx / WAF で __proto__ ヘッダーを 400 で破棄、TLS 終端をオフロードすることでインフラ層での多層防御が成立する。
• 移行先は短期は 22.x（Maintenance LTS）、中期は 24.x（Active LTS）が現実的な選択肢。24.x への移行ではネイティブモジュールの再ビルドに留意
• nvm / Volta / fnm のいずれかのバージョン管理ツールを用いた移行手順と、npm ci ＋ npm rebuild を含むクリーンインストールでの検証フローを実施することで、互換性破壊リスクを低減できる。
• どうしても短期移行が困難な環境では、HeroDevs NES や TuxCare ELS といった延長サポートを検討する余地があるが、根本的な解決には 22.x / 24.x への移行計画が必要

以上、最後までお読みいただきありがとうございました。