Node.jsの脆弱性とは｜影響の確認方法と対応バージョン・アップデート手順【2026年6月最新】

Node.jsの脆弱性とは、JavaScriptランタイムであるNode.js本体（コア）やそれが内蔵するV8エンジン・依存ライブラリに見つかる、攻撃に悪用され得る欠陥のことです。Node.jsプロジェクトはほぼ毎年複数回のセキュリティリリースを出しており、2026年も1月・3月・6月に修正版が公開されました。直近の2026年6月18日のリリースでも最大深刻度「High」の脆弱性が修正されています。重要なのは、どのバージョンに影響するか・自分の環境が対象か・どう更新するかを正しく把握することです。この記事では、Node.jsの脆弱性の基礎から、影響を受けるかの確認方法、2026年6月時点で使うべきバージョン、アップデート手順、これまでの主なCVEまでを最新情報で整理します。

まとめ：最初に確認すべきことと推奨バージョン（2026年6月時点）

Node.jsの脆弱性対策で最初にやるべきことは3つです。第一に、node -vで利用中のバージョンとそのサポート状況を確認します。第二に、サポート対象（Current/LTS）の最新パッチへ更新します。2026年6月時点の推奨は、本番運用なら Active LTS の Node.js 24（最新 v24.18.0）、新機能を追う場合は Current の Node.js 26（最新 v26.4.0）です。第三に、npm auditやGitHubの依存アラートで継続的に脆弱性を監視します。

特に注意が必要なのは Node.js 20 です。2026年4月30日にEOL（サポート終了）を迎えており、以降に見つかった脆弱性の公式修正は提供されません。20系を使い続けている場合は、24系以降への移行を最優先で計画してください。以下では、脆弱性の種類と深刻度の読み方から、影響確認・更新手順・過去のCVEまでを順に解説します。

Node.jsの脆弱性とは｜発生する仕組みと深刻度の読み方

Node.jsの脆弱性は「Node.js本体のコード」だけの問題とは限りません。攻撃面は大きく3層に分かれており、層ごとに修正の出方や対応が変わります。どこに起因する脆弱性かを見分けると、自分が更新すべき対象（Node.js本体か、npmパッケージか）が判断しやすくなります。

コア・V8・依存ライブラリという3つの発生源

1つ目はNode.jsコアの実装に起因するもので、ファイルパス処理（path）、権限モデル（Permission Model）、TLS、HTTP/2などで見つかります。2つ目は内蔵するV8 JavaScriptエンジン由来で、2025年7月のV8ハッシュ関数（rapidhash）変更に伴うHashDoS（CVE-2025-27209）がこの例です。3つ目はNode.jsが同梱する依存ライブラリ（llhttp・nghttp2・OpenSSL・undiciなど）の脆弱性で、2026年6月のリリースではこれらの更新（OpenSSL 3.5.7・nghttp2 1.69.0など）が含まれ、WebCryptoのDoS（CVE-2026-48933）はNode.js 22・24・26の全サポート系統が対象でした。コアとV8と同梱依存はNode.js本体の更新で直りますが、アプリが個別に入れたnpmパッケージの脆弱性はNode.js更新では直らず、別途対応が必要です。

深刻度（Critical/High/Medium/Low）とCVE・CVSSの見方

Node.jsの脆弱性は深刻度をCritical・High・Medium・Lowの4段階で評価します。Highは上から2番目で、任意コード実行に直結するCriticalほどではないものの、情報漏えいやサービス停止（DoS）など重大な被害につながり得るレベルです。個々の脆弱性には「CVE-2026-48933」のようなCVE識別子が付き、深刻度の定量指標としてCVSSスコア（0.0〜10.0）が併記されます。対応の優先度は、深刻度に加えて「その機能を自分が使っているか」「外部からの入力が届くか（到達可能性）」で判断します。たとえばWindows限定の脆弱性はLinux運用なら優先度が下がり、HTTP/2サーバを公開していなければHTTP/2系の緊急度は相対的に低くなります。

自分のNode.jsが脆弱性の影響を受けるか確認する方法

「影響を受けるか」は、利用バージョンの特定と、脆弱性情報との照合の2段階で確認します。どちらもコマンドで素早くチェックできます。

node -v で利用バージョンとサポート状況を確認する

まず利用中のNode.jsバージョンを確認します。

node -v
# 例: v24.18.0

npm ls node
# プロジェクトが要求するエンジンも確認できる

表示された先頭の数字（メジャーバージョン）が20・22・24・25・26のどれかを見ます。20や25のようにEOLを迎えた系統なら、最新の脆弱性修正は届かないため更新対象です。Electronなど内部にNode.jsランタイムを抱えるアプリも、そのアプリ自体の更新が必要になる点に注意してください。

npm audit と公式アドバイザリで脆弱性を照合する

アプリが使うnpmパッケージ側の脆弱性はnpm auditで確認します。実行にはpackage-lock.jsonが必要なため、ない場合は先にロックファイルを作成します。

npm i --package-lock-only
npm audit

# 自動修正を試す（破壊的変更を伴う場合あり）
npm audit fix

Node.js本体の脆弱性はnpm auditでは検出されないため、公式の脆弱性情報も併せて確認します。最も確実なのはNode.js公式サイトのセキュリティ情報（Vulnerabilityブログ）と、アナウンス専用メーリングリスト「nodejs-sec」の購読です。CVE番号が分かっている場合は、その脆弱性が「どの系統のどのバージョン未満に影響するか」を公式リリースノートで照合します。

サポート対象バージョンとEOL・LTSの最新状況【2026年6月】

Node.jsは偶数メジャー（20・22・24・26…）が長期サポート（LTS）対象で、初版から約3年でEOLを迎えます。2026年6月時点の状況は次の通りです。

LTSとCurrentの違いと、どのバージョンを選ぶべきか

Currentは最新機能がいち早く入る系統で、2026年6月時点ではNode.js 26が該当します。LTSは安定性重視で破壊的変更を抑えた系統で、本番運用に向きます。Node.js 26は2026年10月28日にActive LTSへ移行予定です。指針はシンプルで、業務システムやサーバは Active LTS の Node.js 24、最新APIを試す検証環境は Current の Node.js 26、という使い分けが堅実です。新規構築でわざわざEOLの近い系統を選ぶ理由はありません。

EOLバージョンを使い続けるリスク

EOLを迎えたバージョンには公式の修正パッチが提供されません。Node.js公式も「セキュリティリリースが出るとき、EOLバージョンは常に影響を受けている」と明記しています。つまり20系や25系を使い続けることは、既知の修正可能な脆弱性を放置し続けることと同義です。どうしても即時移行できない場合は、OpenJS FoundationのエコシステムサポートプログラムなどEOL後の商用延長サポートを検討できますが、本筋は新しいLTSへの移行です。

脆弱性発覚時のアップデート手順と暫定的な緩和策

セキュリティリリースはパッチ（マイナー/パッチ番号の更新）として提供され、原則としてAPIの互換性は保たれます。とはいえ本番反映前の検証は欠かせません。

nvm・インストーラ・パッケージマネージャ別の更新

バージョン管理にnvmを使っている場合は、最新LTSの取得と切り替えが手早く行えます。

nvm install --lts
nvm use --lts
node -v

公式インストーラ利用時はNode.js公式サイトから新しいインストーラを取得して上書きします。Linuxでディストリのリポジトリ（NodeSource等）を使う場合はパッケージを更新します。いずれも更新後にnode -vで期待のバージョンになっているかを確認します。

Dockerイメージとnpm依存の更新

コンテナ運用では、ベースイメージのタグを修正版（例: 24.18.0）に上げて再ビルドします。latestのような可変タグではなくパッチまで固定したタグを使うと、意図しない更新や未更新を防げます。アプリ側のnpm依存はnpm audit fixや、Renovate・Dependabotによる定期更新で追従します。npmパッケージのサプライチェーン攻撃への備えについては、socket.devによるnpm/PyPIサプライチェーン攻撃の検知も参考になります。

すぐ更新できない場合の暫定緩和策

本番の都合で即時更新が難しい場合は、脆弱性の種類に応じた緩和でリスクを下げます。DoS系（HashDoSやHTTP/2のメモリ枯渇など）には、受け付けるリクエスト・JSONのサイズ上限、レート制限、タイムアウトを設定します。パストラバーサル系には、外部由来のファイルパスに対する検証強化（..やWindowsのデバイス名の遮断）を入れます。前段にWAFを置ける環境なら既知パターンの遮断ルールも有効です。これらはあくまで時間稼ぎであり、最終的には本体パッチの適用が必須です。

2025〜2026年の主なNode.js脆弱性とセキュリティリリース

近年のセキュリティリリースを振り返ると、権限モデル・TLS・HTTP/2・パス処理・暗号処理といったコア機能で繰り返し修正が入っています。主な対応を時系列で整理します。

2025年の主な脆弱性（権限モデル・HashDoS・パストラバーサル）

2025年1月は、試験的なPermission Model機能をWorker経由で回避できるCVE-2025-23083（High）が修正されました。7月は影響が大きく、V8のrapidhash採用に伴うHashDoS（CVE-2025-27209）と、Windowsのデバイス名（CONなど）でパス検証をすり抜けるパストラバーサル（CVE-2025-27210）が同時に対処されています。後者は前に中程度評価だったCVE-2025-23084の修正が不完全だった再発例で、Windowsでファイルを扱うアプリでは特に注意が必要でした。

2026年の越年リリースと最新の6月リリース

2025年12月15日に予定されていたリリースは複数回の延期を経て、2026年1月13日に20.20.0/22.22.0/24.13.0/25.3.0として公開されました。High3件・Medium4件・Low1件の計8件で、symlinkを使った権限モデル回避（CVE-2025-55130）やタイムアウト処理の競合による情報漏えい（CVE-2025-55131）などが含まれます。この延期の経緯は越年して公開されたNode.jsセキュリティリリースと延期の経緯で詳しく解説しています。さらに2026年6月18日には22.23.0/24.17.0/26.3.1が公開され、WebCryptoのAES整数オーバーフローによるDoS（CVE-2026-48933、High）やTLSのunicodeドット処理を突くワイルドカード認証回避（CVE-2026-48618、High）が修正されました。なお、Node.js本体だけでなくnpm側でも深刻な脆弱性は起こり得ます。たとえばCVSS10.0のCVE-2026-40175（Axios）のように、利用ライブラリの脆弱性が事業リスクに直結する事例もあります。

すべてのCVEに即対応しない｜実務での優先順位の付け方

セキュリティリリースのたびに全CVEへ即時対応するのは、現実の運用では必ずしも最適ではありません。むやみな緊急更新はサービス停止やデグレのリスクを伴います。重要なのは「影響度×到達可能性」で優先度を決め、継続的に監視する仕組みを先に作ることです。

npm audit・Dependabot・Renovateで継続監視を組み込む

単発の手動チェックより、CIに監視を組み込むほうが確実です。GitHubのDependabotアラートやRenovateで依存更新を自動提案させ、npm auditをCIのステップに入れて新規脆弱性を検知します。Node.js本体は「nodejs-sec」メーリングリストで通知を受け、四半期に一度は利用バージョンとEOL予定を棚卸しします。これにより、緊急リリースが出た際もすぐ本番反映できる体制が整います。

「即対応すべきもの」と「待てるもの」を分ける判断基準

優先度は次の順で判断すると整理しやすくなります。最優先は、外部からの入力が届く公開サーバで、使っている機能に直撃するHigh以上の脆弱性です。たとえば公開HTTP/2サーバを運用しているなら、6月リリースのHTTP/2系（CVE-2026-48937など）は即対応に値します。一方、使っていない機能や、内部ネットワーク限定・特定OS限定の脆弱性は、定例の更新サイクルにまとめて構いません。EOLバージョンの利用だけは例外で、これは個別CVEの優先度以前の問題として、常に最優先で移行すべき状態です。「とりあえず全部すぐ上げる」でも「気づいたら何年も放置」でもなく、到達可能性に基づく優先度付けと定例更新の組み合わせが、最もコストの低い守り方です。

よくある質問（FAQ）

自分のNode.jsが脆弱性の影響を受けているかは、どう確認すればよいですか？

node -vで利用バージョンを確認し、そのメジャーバージョンが対象かを公式のセキュリティ情報（Vulnerabilityブログ）やCVEのリリースノートと照合します。npmパッケージ側はnpm audit（package-lock.json必須）で確認します。Node.js本体の脆弱性はnpm auditでは出ない点に注意してください。

2026年6月時点で使うべきNode.jsのバージョンはどれですか？

本番運用はActive LTSのNode.js 24（最新 v24.18.0）が無難です。最新機能を使いたい場合はCurrentのNode.js 26（最新 v26.4.0）を選びます。Node.js 26は2026年10月にActive LTSへ移行予定です。いずれも各系統の最新パッチを適用してください。

Node.js 20はまだ使えますか？

Node.js 20は2026年4月30日にEOL（サポート終了）を迎えました。動作はしますが、以降に見つかった脆弱性の公式修正は提供されないため、本番では推奨されません。Node.js 24以降への移行を計画してください。どうしても残す場合は商用の延長サポートの利用を検討します。

npm audit で出た脆弱性は、すべて修正すべきですか？

必ずしも全件を即修正する必要はありません。本番で実際に使うコードパスに到達するか、深刻度はどれくらいかで優先度を判断します。npm audit fixは破壊的変更を含む場合があるため、適用後はテストで挙動を確認します。開発依存のみに影響する低深刻度のものは、定例更新でまとめて対応しても問題ないことが多いです。

Node.js本体の脆弱性とnpmパッケージの脆弱性は何が違いますか？

Node.js本体（コア・V8・同梱依存）の脆弱性はNode.js自体を更新することで直ります。一方、アプリが個別にインストールしたnpmパッケージの脆弱性はNode.jsを更新しても直らず、該当パッケージの更新や差し替えが必要です。前者はnode -vと公式情報、後者はnpm auditで確認する、と覚えておくと整理しやすくなります。

関連記事

• 2025年末から年をまたいでようやく公開された『Node.js』セキュリティリリースと度重なる延期の経緯
• CVSS10.0を記録したCVE-2026-40175がAxios利用企業に迫る深刻リスク
• socket.devとは？npm/PyPIのサプライチェーン攻撃を防ぐ仕組みと料金