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

Node.jsの脆弱性とは、JavaScriptランタイムであるNode.js本体（コア）や、内蔵するV8エンジン、同梱する依存ライブラリに見つかる、攻撃に悪用されうる欠陥のことです。Node.jsプロジェクトは2026年に1月・3月・6月・7月の4回セキュリティリリースを出し、10月21日には5回目となるセキュリティリリースで26系・24系・22系の脆弱性10件（High 4件）を修正しました。この記事では、脆弱性の発生源と深刻度の読み方、自分の環境が対象かを公式ツールで判定する方法、2026年10月22日時点で使うべきバージョン、更新の手順、npmパッケージ側の対策、これまでの主なCVEまでを整理します。

まとめ：10月21日の修正版26.12.1・24.22.1・22.23.4と20系・25系からの移行

最初にやることは、npx is-my-node-vulnerable か node -v で版を確かめ、同じラインの最新パッチか、サポート期間内かを判定することです。10月21日のセキュリティリリース後の各ラインの最新は、26系が26.12.1、24系が24.22.1、22系が22.23.4です。1つ前の26.12.0・24.22.0・22.23.3はHigh 4件を含む10件が未修正なので、この3つの版へ上げてください。

サポートの区分も10月に動いています。24系は10月20日にMaintenance LTS（重大なバグ修正とセキュリティ修正が中心）へ移り、26系は10月28日にLTSへ入る予定です。2026年4月30日にサポートが終わった20系と、6月1日に終わった25系には10月の修正も届きません。npmパッケージ側の脆弱性は、Node.js本体とは別に npm audit やDependabotで監視します。

2026年10月21日のセキュリティリリースで直った10件と各ラインの修正版

Node.jsプロジェクトは10月14日の予告どおり、2026年10月21日にOctober 2026 Security Releasesを公開しました。修正版は26系が26.12.1、24系が24.22.1、22系が22.23.4です（dist/index.jsonで3つともsecurityフラグ付き）。修正された脆弱性は10件で、深刻度はHigh 4件・Medium 3件・Low 3件です。

最も危険なのはCVE-2026-111497です。不正なBrotliデータを展開すると範囲外書き込みが起き、リモートからのコード実行につながりうると説明されています。圧縮されたリクエストや外部サーバーの応答を展開するアプリは、到達可能と考えて先に更新します。Python・.NET・Linuxパッケージを含むBrotliの影響確認は、Brotli 脆弱性の解説記事にまとめています。TLSの2件は、IPアドレスを宛先にした接続で、本来一致しない証明書が受け入れられる問題です。社内APIやIoT機器へIP指定で接続している構成が当てはまります。

CVE-2026-106074は、ユーザーランドのスタートアップスナップショットやSEA（単一実行ファイル）にcrypto.randomUUID()とrandomInt()のキャッシュが保存され、どのプロセスも同じ値を繰り返す問題です。SEAで配布しているツールは、修正版のNode.jsで作り直さない限り直りません。依存ライブラリもc-ares・Undici・OpenSSL（24・22系）・SQLite（22系）が更新され、eMudhraの中間CA侵害を受けたCA証明書の更新も入っています。

告知は「セキュリティリリースが出るとき、EOLのバージョンは常に影響を受けている」と書いています。20系・25系は今回の10件の一覧に載っていないだけで、安全という意味ではありません。7月のリリースは2回延期されましたが、今回は予告した日に公開されました。

Node.jsの脆弱性が生まれる3つの発生源と深刻度・CVSSの読み方

Node.jsの脆弱性は「Node.js本体のコード」だけの問題とは限りません。どこに起因するかで、更新すべき対象（Node.js本体か、npmパッケージか）が変わります。

コア・V8・同梱依存ライブラリの3層と本体更新で直る範囲の違い

1つ目はNode.jsコアの実装に起因するもので、ファイルパス処理、権限モデル（Permission Model）、TLS、HTTP/2で繰り返し見つかっています。2つ目は内蔵するV8エンジン由来で、V8の文字列ハッシュ（rapidhash）で定数に乱数の種が入っていなかったHashDoSのCVE-2025-27209（24系のみ）や、整数に見える文字列のハッシュが予測できた2026年3月のCVE-2026-21717が例です。3つ目は同梱の依存ライブラリ（llhttp・nghttp2・OpenSSL・undiciなど）で、2026年6月のリリースではOpenSSL 3.5.7やnghttp2 1.69.0への更新が含まれました。

この3層はどれもNode.js本体の更新で直ります。一方、アプリが個別に入れたnpmパッケージの脆弱性はNode.jsを更新しても直りません。AxiosのCVE-2026-40175のように、利用ライブラリ側の脆弱性が当初CVSS 10.0と公表され、のちに公式アドバイザリで4.8へ見直された例もあります。経緯と対応はCVE-2026-40175（Axios）の事業リスクで扱っています。

告知の深刻度Critical〜LowとNVDのCVSSが食い違う理由

Node.jsの告知は、深刻度をCritical・High・Medium・Lowの4段階で示します。これはNode.jsプロジェクトの評価で、NVDが付けるCVSSの基本値とは一致しないことがあります。たとえば2026年1月のCVE-2026-21636は、告知ではMediumでしたが、NVDのCVSS 3.1は10.0でした。同じCVEに、CVE番号を割り当てたHackerOneはCVSS 3.0で5.8を付けており、評価する主体によっても数字は変わります。CVSSの読み方はCVSSv3の計算式とスコアの目安で解説しています。

対応の優先度は、深刻度の数字だけで決めません。「その機能を使っているか」「外部からの入力が届くか」で判断します。Windows限定の脆弱性はLinux運用なら優先度が下がり、権限モデル（--permission）の穴は、そのフラグを使っていない環境には関係しません。

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

確認は、版の特定と、公式データとの照合の2段階です。どちらもコマンドで済みます。

node -vとnpm pkg get enginesで実行中の版と要求版を確認

# 実行中の Node.js の版
node -v

# プロジェクトが要求する Node.js の版（package.json の engines）
npm pkg get engines

要求エンジンの確認に npm ls node を挙げる解説がありますが、これは依存パッケージを表示するコマンドで、engines は出ません。Electronなど内部にNode.jsを抱えるアプリは、そのアプリ自体の更新が必要です。組み込まれたNode.jsの版は、メインプロセスまたはpreloadで process.versions.node を表示すると確かめられます。既定の設定では、ページ側の開発者ツールからNode.jsのAPIを直接参照できません。サーバーに入っているNode.jsを上げても、アプリが抱える版は変わりません。

公式のis-my-node-vulnerableで既知のCVEに当たるかを判定

いちばん手早いのは、Node.jsのセキュリティチームが作った is-my-node-vulnerable です。実行中の版（process.version）を、Node.js Security WGが管理する脆弱性データベースと照らし、該当するCVEと修正版を一覧にします。

npx is-my-node-vulnerable

2026年10月20日に、手元のv26.5.0で1.6.1を実行すると、7月29日の26.5.1で直った10件のCVEが「Patched versions: ^22.23.2 || ^24.18.1 || ^26.5.1」の形で表示され、終了コードは1でした。7月の11件のうちCVE-2026-56846は22系・24系だけが対象なので、26系では10件になります。同じデータベースで判定する関数 isNodeVulnerable() では、24.18.0と、EOLの20.20.2・25.9.0は脆弱、24.22.0・26.12.0・22.23.3は脆弱でないという結果でした。EOLの版は、新しい修正が追跡されないため脆弱として扱われます。

終了コードが1になるので、CIの1ステップに入れれば未修正の版でビルドを止められます。GitHub Actionsでは nodejs/is-my-node-vulnerable@v1 に node-version を渡す形でも使えます。上の判定結果は10月21日の修正公開より前のものです。公開後は24.22.0・26.12.0・22.23.3も未修正の版にあたるので、判定に使うデータベースが更新されているかを確かめてから結果を読みます。

dist/index.jsonとschedule.jsonで未適用の修正とEOLを判定

同じラインの最新版とサポート終了日も一緒に見たいときは、nodejs.orgの配布一覧（dist/index.json）と、nodejs/Releaseのschedule.jsonを直接読みます。配布一覧の各版にある security の真偽値が、セキュリティリリースかどうかを示します。外部パッケージは使わず、Node.js 18以降で動くスクリプトです。

// 実行中の Node.js が「同じラインの最新版か」「サポート期間内か」を公式データで確かめる（Node.js 18 以降）
const [index, schedule] = await Promise.all([
  fetch("https://nodejs.org/dist/index.json").then((r) => r.json()),
  fetch("https://raw.githubusercontent.com/nodejs/Release/main/schedule.json").then((r) => r.json()),
]);
const major = process.versions.node.split(".")[0];
const line = schedule[`v${major}`];
const latest = index.find((r) => r.version.startsWith(`v${major}.`));
const newerSecurity = index.filter((r) => r.version.startsWith(`v${major}.`) && r.security
  && r.date > (index.find((x) => x.version === process.version)?.date ?? "0"));
const today = new Date().toISOString().slice(0, 10);
console.log(`実行中: ${process.version} / 同じラインの最新: ${latest?.version}（${latest?.date}）`);
console.log(`サポート終了日: ${line?.end ?? "不明"}${line && line.end < today ? "（終了済み：別ラインへ移行）" : ""}`);
console.log(newerSecurity.length
  ? `未適用のセキュリティリリース: ${newerSecurity.map((r) => r.version).join(", ")}`
  : "未適用のセキュリティリリース: なし");

check.mjs として保存し、node check.mjs で実行します。2026年10月20日にv26.5.0で実行した結果です。

実行中: v26.5.0 / 同じラインの最新: v26.12.0（2026-10-14）
サポート終了日: 2029-04-30
未適用のセキュリティリリース: v26.5.1

このスクリプトはNode.js本体だけを見ます。npmパッケージ側は、後半の npm audit の章で扱います。

サポート対象バージョンとLTS移行の日程【2026年10月22日時点】

2026年10月22日時点の各ラインの状況です。最新版は10月21日のセキュリティリリースで出た修正版です。

10月のLTS移行を踏まえた24系と26系の選択基準

24系は10月20日にMaintenance LTSへ移り、修正は重大なバグとセキュリティ問題が中心になります。ただし、後続ラインへの移行を支援する新機能などが例外的に追加される場合があります。セキュリティ修正は2028年4月30日まで続くので、既存の本番環境は24系のままで問題ありません。10月28日以降に新規構築を始めるなら、LTSに入る26系を第一候補にしてよい時期です。26系の変更点はNode.js 26の新機能とLTSスケジュールにまとめています。22系は2027年4月30日まで修正が出るため、依存製品の都合で上げられない既存環境の継続先として使えます。

EOLの20系・25系を使い続けるリスクと商用延長サポート3社

20系と25系は、3月24日の20.20.2と3月31日の25.9.0が最後で、6月・7月の修正も10月の修正も届きません。is-my-node-vulnerableでも脆弱と判定されます。即時移行できない場合は、nodejs.orgのEOLページが、OpenJS FoundationのEcosystem Sustainability Programの提携先としてHeroDevs・NodeSource・TuxCareの3社を挙げています。同ページも商用サポートは一時的な手段と位置づけており、本筋は新しいLTSへの移行です。

Node.js 27からの年1回リリースとAlpha版の扱い

Node.jsは27系からリリースの仕組みが変わります。2026年3月10日の発表によると、メジャーリリースは年2回から年1回（4月）になり、奇数・偶数の区別をやめてすべての版がLTSになります。各版は10月から3月までのAlpha、4月から10月までのCurrent、30か月のLTSを経て、最初のCurrentリリースから36か月でEOLです。schedule.jsonでは、27系のAlphaが2026年10月28日、27.0.0が2027年4月22日、EOLが2030年4月30日の予定です。

理由の1つとして、発表は4〜5本のリリースラインに並行してセキュリティ修正を出す負担を挙げています。同時に修正するラインが減るため、セキュリティリリースで「どのラインに当てるか」を考える場面は少なくなります。Alpha版（27.0.0-alpha.1 の形式）は互換性を壊す変更を含むので本番には使わず、ライブラリの作者がCIで先行して試す用途です。

脆弱性が見つかったときのアップデート手順と更新までの暫定緩和策

セキュリティリリースは同じメジャーライン内の更新として出ますが、2026年6月の24.17.0のようにマイナーバージョンが上がる回もあり、重大な修正では互換性に影響する変更もあり得ます。リリースノートで変更内容を確かめ、本番反映前の動作確認は省かないでください。

nvmによる同一ラインの最新版への更新とDockerイメージの版指定

# nvm（macOS・Linux）：24 系の最新へ
nvm install 24
nvm use 24
node -v

# Docker：パッチ番号まで固定したタグへ上げて再ビルド
# FROM node:24.22.0-bookworm-slim

Dockerは node:24 や latest のような可変タグではなく、24.22.0-bookworm-slim のようにパッチ番号まで書いたタグを使うと、どの版で動いているかが明確になります（10月20日にDocker Hubで実在を確認）。ただし同じタグでもイメージが再ビルドされて中身が変わることがあり、タグを書いただけでは修正版への更新漏れも防げません。再現性が必要ならイメージのダイジェストも固定し、Dependabotなどの更新通知と定期的な再ビルドを組み合わせます。10月21日の修正版のように新しいパッチが出たら、タグの数字をその版へ書き換えて再ビルドします。公式インストーラの場合はnodejs.orgから新しいインストーラを取得して上書きし、いずれも更新後に node -v で版を確かめます。続いてサービスの起動先を新しい実行ファイルへ切り替え、プロセスを再起動または再デプロイし、稼働中アプリの process.version でも反映を確認します。

すぐ更新できない場合のDoS・パス処理系への暫定緩和策

DoS系（HashDoSやHTTP/2のメモリ枯渇など）には、受け付けるリクエストやJSONのサイズ上限、レート制限、タイムアウトを設定します。パストラバーサル系には、外部由来のファイルパスの検証（.. やWindowsのデバイス名の遮断）を足します。前段のWAFで既知の攻撃パターンを止める方法もありますが、どれも時間稼ぎです。

npmパッケージの脆弱性：2025年のShai-Huludとnpm auditでの確認

Node.jsのセキュリティ対策は、本体の更新だけでは終わりません。2025年には、npmのパッケージそのものを汚染する攻撃が相次ぎました。

2025年9月と11月のShai-Huludとnpmトークンの変更

GitHubは2025年9月14日に、乗っ取ったメンテナーのアカウントから人気パッケージへ悪性のpostinstallスクリプトを仕込み、自己増殖するワーム「Shai-Hulud」の通報を受けました。CISAの9月23日の注意喚起によると、汚染されたパッケージは500を超え、GitHubの個人アクセストークンやAWS・Google Cloud・AzureのAPIキーを盗み出していました。CISAは、package-lock.jsonで入れ子の依存まで該当パッケージを調べること、当時の対応として、依存を2025年9月16日より前に公開された安全性を確認済みの版へ固定すること、開発者の認証情報をすぐに入れ替えることを勧めています。11月25日にはニュージーランドの国家サイバーセキュリティセンターが、500近いパッケージを汚染した改良版（Shai-Hulud 2.0）を報告しました。

npm側の対策も進みました。2025年11月5日の変更で、権限を絞れない従来型の「classic token」は新規発行ができなくなり、書き込み権限のあるgranular tokenは2FA必須が既定、有効期限は最長90日になりました。classic tokenは当初2025年11月19日に廃止予定でしたが、GitHubは2025年12月9日に既存トークンをすべて失効させたと発表しました。パッケージを公開する側は、CIからはトークンを持たない trusted publishing に切り替えるのが安全です。

npm auditによる依存の監査とnpm ci・ignore-scriptsによるスクリプト実行制御

依存の既知の脆弱性は npm audit で確かめます。既定では package-lock.json または npm-shrinkwrap.json が必要です。--no-package-lock でも実行できますが、依存ツリーが再解決されるため結果の再現性に注意が必要です。npm 11.17.0で、lodash 4.17.20を本番依存、minimist 1.2.5を開発依存に入れたプロジェクトを試した結果は次のとおりでした。

# 開発依存も含めて high 以上があれば失敗（終了コード 1）
npm audit --audit-level=high
# → 2 vulnerabilities (1 high, 1 critical)

# 本番依存だけを見る（開発依存の minimist は除外される）
npm audit --omit=dev
# → 1 high severity vulnerability

# 本番依存で critical があるときだけ失敗させる（この例では終了コード 0）
npm audit --omit=dev --audit-level=critical

# レジストリの署名を検証する（悪性コードの有無を保証する検査ではない）
npm audit signatures
# → 2 packages have verified registry signatures

CIでは --omit=dev と --audit-level の組み合わせで、ビルドを止める基準を決めます。npm audit fix --force は、package.jsonで指定した範囲を超えて版を上げます。この例ではlodashを4.18.1へ上げると表示されたので、適用後はテストで挙動を確かめてください。

Shai-Huludはインストール時のスクリプトで動いたため、CIでは npm ci --ignore-scripts でスクリプトの実行を止める方法も効きます。ただし、ネイティブアドオンなどインストール時のスクリプトが必要な依存は動かなくなるので、どの依存が必要とするかを先に洗い出します。依存の定期更新はDependabotのdependabot.yml設定、悪性パッケージの検知はsocket.devによるnpm・PyPIの攻撃検知、ロックファイル全体の走査はOSV-Scannerの使い方で扱っています。

2025〜2026年の主なNode.jsセキュリティリリースと修正内容の推移

権限モデル・TLS・HTTP/2・パス処理・暗号処理といったコア機能で、修正が繰り返し入っています。

表の修正版は代表の2ラインです。各回の全ラインは、2026年3月が20.20.2・22.22.2・24.14.1・25.8.2、6月が22.23.0・24.17.0・26.3.1、7月が22.23.2・24.18.1・26.5.1、10月が22.23.4・24.22.1・26.12.1でした。

2025年の権限モデル回避・HashDoS・Windowsパストラバーサル

2025年1月は、試験的な権限モデルをWorker経由で回避できるCVE-2025-23083（High）が修正されました。7月はV8のrapidhashに伴うHashDoS（CVE-2025-27209、24系のみ）と、Windowsのデバイス名（CON・PRN・AUXなど）でパス検証をすり抜けるCVE-2025-27210が同時に対処されています。後者はCVE-2025-23084の修正が不完全だった再発例で、Windowsでファイルを扱うアプリでは特に注意が要りました。

2026年1月の越年リリースから7月までの4回の修正内容と再修正の経緯

2025年12月15日予定だったリリースは4度の延期を経て2026年1月13日に公開され、8件が修正されました。経緯は2026年1月のNode.jsセキュリティリリースの記録で詳しく扱っています。3月24日のリリースでは、1月に直したはずのCVE-2026-21637（TLSコールバックの例外でプロセスが落ちる）の修正漏れが、同じ番号のHighとして再修正されました。同じ回には、req.headersDistinct に __proto__ という名前のヘッダーを送るとプロセスが落ちるCVE-2026-21710（High）も含まれます。

6月18日にはWebCryptoのAES処理の整数オーバーフローによるDoS（CVE-2026-48933）と、TLSのワイルドカード証明書の照合をすり抜けるCVE-2026-48618（ともにHigh）が直っています。7月29日のリリースは、HTTP/2で保持されたヘッダーが maxSessionMemory の上限を回避するCVE-2026-56846、HTTP/2の再入でヒープのuse-after-freeが起きるCVE-2026-56848、権限モデルのパス照合で許可範囲外のファイルに触れるCVE-2026-58043の3件のHighを修正しました。6月に直したTLSセッション再利用の問題（CVE-2026-48934）も、7月にCVE-2026-58040として修正漏れが見つかっています。

すべてのCVEに即対応しないための影響度と到達可能性の判断基準

セキュリティリリースのたびに全CVEへ夜間の緊急更新をかけると、デグレや停止のリスクが積み上がります。影響度と到達可能性で優先度を分け、定例の更新と組み合わせます。

即対応すべきものと定例更新に回してよいものの分け方

最優先は、外部からの入力が届く公開サーバーで、使っている機能に直撃するHigh以上の脆弱性です。HTTP/2を公開しているサーバーなら、7月のCVE-2026-56848（22・24・26系）と56846（22・24系）は即対応に値しました。一方、対象機能を使っていない、対象OSではないなど、攻撃条件が成立しないことを確認できた場合は、定例更新にまとめる判断ができます。社内ネットワーク限定でも、攻撃者が到達できる場合は前倒しで対応します。権限モデルの3件のように --permission を使っていなければ届かないものも、定例で足ります。EOLの20系と25系だけは例外で、個別CVEの優先度を議論する前に移行を最優先にすべき状態です。

公開サーバー・社内バッチ・開発端末で分ける更新周期と管理台帳の記録項目

Node.jsが動いている場所ごとに更新の周期を分けると、運用の負担が読めるようになります。運用ルールの例として、インターネットに公開しているAPIやWebサーバーは、High以上を含むセキュリティリリースを1週間以内に適用する目標を置きます。ただし、悪用が確認されている場合や攻撃が容易な場合は、適用または暫定緩和を前倒しします。社内ネットワークだけで動くバッチや管理画面は、攻撃条件と業務影響を確認し、緊急性が低い場合に月次の定例更新へ載せます。

見落とされやすいのが開発端末とCIです。ビルド用のコンテナや開発者のPCが20系のまま残っていると、そこで作った成果物の検証が古いランタイム前提になります。CIのベースイメージは本番と同じパッチ番号に固定し、本番を上げるときに同じ変更で一緒に上げてください。台帳には「対象サーバー・サービス名・実行ファイルまたはイメージ・Node.jsの完全なバージョン・更新日・担当者」を残すと、次のリリースで対象を絞り込む時間が短くなります。

どのサーバーにどの版のNode.jsが残っているか分からない、外部公開しているAPIがHTTP/2の脆弱性に当たるかを確かめたい、という場合は、一創の脆弱性診断・セキュリティ診断で、公開環境の棚卸しから診断まで支援しています。

よくある質問

Node.jsの脆弱性対応で寄せられやすい質問に答えます。

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

npx is-my-node-vulnerable を実行するのが手早い方法です。実行中の版に当たるCVEと修正版が表示され、該当があれば終了コードが1になります。同じラインの最新版やサポート終了日も知りたいときは、本文のスクリプトでdist/index.jsonとschedule.jsonを読みます。npmパッケージ側は npm audit で確認します。

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

10月21日のセキュリティリリース後の最新は、24系が24.22.1、26系が26.12.1、22系が22.23.4です。High 4件を含む10件が直っているので、この版へ上げてください。既存の本番環境は24系、10月28日以降の新規構築はLTSに入る26系が候補です。

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

動作はしますが、2026年4月30日にサポートが終わりました。最後の版は3月24日の20.20.2で、6月・7月・10月のセキュリティ修正は提供されません。is-my-node-vulnerableでも脆弱と判定されます。本番では24系か26系へ移行し、即時移行できない場合は商用の延長サポートを検討します。

Node.jsは安全に使えるランタイムですか？

既知の脆弱性への基本対策は、サポート期間内の版を修正版へ更新し続けることです。2026年は10月21日までに5回のセキュリティリリースが公開されています。そのうえで、アプリの入力検証、認証・権限設定、依存パッケージの管理もあわせて行います。危険なのは、EOLの版を使い続けることと、npmの依存を監視しないことです。

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

Node.js本体（コア・V8・同梱依存）の脆弱性は、Node.js自体を更新すれば直ります。アプリが個別に入れたnpmパッケージの脆弱性はNode.jsを更新しても直らず、そのパッケージの更新や差し替えが必要です。前者はis-my-node-vulnerableと公式告知、後者は npm audit で確認する、と分けて覚えると整理しやすくなります。

関連記事

• Node.js 20.20.0/22.22.0/24.13.0/25.3.0 セキュリティリリース｜全8CVEと4度の延期の記録
• Node.js 26の新機能と破壊的変更・LTS移行日｜24からの移行手順【26.11.1対応】
• Node.jsとは？仕組み・版の選び方・標準機能で動かす手順を実装目線で解説
• npmとは？CLIとレジストリの役割・package.jsonとv12の変更点を解説
• Snykとは？CLIでの脆弱性スキャンとCI組み込み・料金の実額を実装視点で解説