【2026年11月版】Node.jsセキュリティリリース対応：更新先と手順【Windows/nvm未導入】

Node.js の公式サイトに「セキュリティリリース」の告知が出ていました。2026年11月11日、修正版が3系統同時に公開されています。ただ、いざ更新しようとすると壁にぶつかります。世の中の手順の多くが nvm（バージョン管理ツール）を使っている前提で書かれていて、公式サイトからインストーラーで入れただけ、という人が圧倒的に多いからです。

この記事で解決することは次の2つだけです。

• 今回のアナウンスで何が直り、自分が該当するのかが分かる
• nvmを入れていなくても、Windowsで3分で安全に更新できる（戻し方も含む）

【POINT】「nvmを入れないと更新できない」ことはありません。nvmは複数のバージョンを切り替えるための道具であって、更新そのものには不要です。

何がきたのか：2026年11月11日のセキュリティリリースを簡単に

Node.js プロジェクトが、22系列・24系列・26系列のセキュリティ修正版を同時に公開しました。修正内容は脆弱性16件、最高深刻度は HIGH です。公式発表は次の1本だけを見ておけば足ります。

項目	内容
発表日	2026年11月11日
修正版	22.23.5 / 24.22.3 / 26.13.1
修正件数	16件（High 7件 / Medium 6件 / Low 3件）＋同梱部品の更新
同梱部品	llhttp（22・24・26）／undici（24・26）／sqlite（22・24）
公式発表	nodejs.org「Wednesday, November 11, 2026 Security Releases」

ここでいう「系列」とは、node -v 表示で真ん中のドットより前の数字です。v24.19.0 なら 24系列。同じ系列の中で数字が上がっていくので、24.19.0 → 24.22.3 は「同じ24系列の中での更新」になります。

深刻度 High の7件を、専門用語なしで書き直す

CVE	対象	かんたんに言うと
CVE-2026-123864	HTTPS	細工した接続でサーバーのメモリを覗ける。TLSの秘密鍵や、他の人のリクエスト内容が漏れうる
CVE-2026-123874	HTTP/2	ファイル配信の途中で接続を切られると、すでに消えたデータを使って処理を続ける（メモリ破壊）
CVE-2026-123863	HTTP/2	接続の終わらせ方ひとつでサーバーが強制終了する
CVE-2026-123865	HTTP/2	接続後始末が残るため、メモリと「開けるファイルの番号」が枯渇し続ける（放置戻らない）
CVE-2026-123866	HTTP/2	ストリーム処理の終わらせ方で、他の接続のレスポンスを相手へ送ってしまう
CVE-2026-126051	TLS	証明書関連の仕組みを使っているHTTPSサーバーで、遠隔からプロセスを落とせる
CVE-2026-123872	TLS	接続のやり直しでホスト名を変えられ、証明書認証をすり抜けられる

Medium・Low の9件は、1件のHTTP/2メモリ枯渇、altsvc() の1バイト溢出、プロキシの認証情報がエラーログに平文で出る件、証明書の検証すり抜け、HTTP/2のファイル配信キャンセルで落ちる件、--permission モデル関連2件、zlib の例外、が含まれます。詳細な挙動は公式発表に1件ずつ説明が追記されています。

High が7件と聞くと構えがちですが、多くは「HTTP/2やTLSで人の接続を受け付けるサーバー」が主戦場です。ローカルでツールを動かしているだけなら直接的な影響は限定的。それでも更新はしてください。理由は後の「放置リスク」で書きます。

ステップ1：自分の環境を2コマンドで確かめる

更新の前に、いまの環境を2コマンドで把握します。ここで「インストーラーで入れた」ことが分かれば、この後の手順がそのまま使えます。

手順1：バージョンとインストール場所を見る

node -v
npm -v
where.exe node

これで「今いくつなのか」「どこから起動しているのか」が分かります。C:Program Filesnodejsnode.exe と出たら、それは公式インストーラーで入れたNode.jsです。この記事の手順がそのまま使えます。

手順2：脆弱性の有無を公式ツールで見る

Node.js 公式のチェックツールが is-my-node-vulnerable です。インストール不要で、今のバージョンを公式の脆弱性データベースと突き合せてくれます。

npx is-my-node-vulnerable

「このNode.jsには既知の脆弱性があります」と出たら更新対象です。ツール自体がNode.jsで動くので、あまりに古い版だと動かないことがあります。その場合は理由を問わず更新してください。

【画像挿入推奨】ここに node -v と npx is-my-node-vulnerable を実行したターミナルのスクリーンショットを挿入すると理解しやすい

Windowsで「どう入れたか」を確かめておく

更新方法は「どう入れたか」で決まります。設定 → アプリ → インストール済みのアプリに Node.js が並んでいれば、それはインストーラー版です。PowerShellで確認するなら次です。

Get-ItemProperty "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionUninstall*" |
  Where-Object { $_.DisplayName -match "Node" } |
  Select-Object DisplayName, DisplayVersion, UninstallString

実際に私のPC（Windows 11）で実行した結果が次です。UninstallString に MsiExec.exe が入っているのが分かります。これが「MSIで入っている」証拠で、つまり上書きインストールで更新できることを意味します。

DisplayName     : Node.js
DisplayVersion  : 24.19.0
UninstallString : MsiExec.exe /I{89851E15-F7D6-476D-982E-F8F4215E4491}

【CHECK】逆に where.exe node が nvm や fnm、volta のフォルダを指す場合は、そのツール側で更新します。本記事の手順（MSI上書き）を混ぜると環境が二重になるのでやらないでください。

ステップ2：MSIをもう一度実行する（所要3分）

なぜ「アンインストールしなくていいのか」を先に説明します。Node.js のインストーラーは Windows Installer の仕組みで入っていて、新しい版のMSIを実行すると古い版を検出して置き換える設計です。インストール場所（C:Program Filesnodejs）と PATH は同じ場所を使い続けるので、環境変数の作り直しも、npmの再設定も発生しません。

手順1：起動しているNodeを止める

開いているファイルやプロセスが Node を使っていると、ファイルがロックされて差し替えに失敗します。VS Code、開発サーバー、pm2、Node系の常駐サービスを止めてからにします。

手順2：MSIをダウンロードする

公式の dist フォルダから、系列ごとに最新版を1本取ってきます。2026年11月11日時点の 24系列は次のファイルです（約33 MB）。

https://nodejs.org/dist/latest-v24.x/node-v24.22.3-x64.msi     ← 64bit（ほぼ全員これ）
https://nodejs.org/dist/latest-v24.x/node-v24.22.3-arm64.msi   ← ARMのPC

自分のPCがどちらか分からない場合は node -p "process.arch" で確認します。ここが x64 なら上を使う、arm64 なら下を使います。間違えるとインストールが進みません。

手順3：ダウンロードファイルの指紋（SHA-256）を照合する

任意ですが、数秒で終わるので癖つけておく価値があります。ダウンロードしたファイルの指紋を出して、公式が公開している値と比べます。

Get-FileHash .node-v24.22.3-x64.msi -Algorithm SHA256

公式の SHASUMS256.txt にある先頭の英数字16文字と一致すれば本物です。一致しなかった場合は削除して、公式サイトからやり直します。

手順4：MSIを実行して「Upgrade」を選ぶ

MSIをダブルクリックし、UAC（ユーザー アカウント制御）の同意を求められたら「はい」を押します。古い版が入った状態でMSIを実行すると、ウィザードの選択肢は アップグレード（Upgrade） になっています。ここでの 削除（Remove） は選ばないでください。

インストール完了まで1〜2分。このとき npm も一緒に、その版に同梱されている npm へ入れ替わります。

手順5：新しいターミナルで確認する

node -v     # v24.22.3 と出ればOK
npm -v
where.exe node

できれば新しいターミナルで確認してください。MSIの上書きでは PATH が同じ場所を指しているため、多くの場合はそのまま新しい版が表示されます。ただ、開き直っておくと「本当に更新されたのか」の切り分けがしやすくなります。

もう1つ、忘れないでほしいことがあります。すでに起動しているプロセスは、再起動するまで古いNode.jsで動き続けています。開発サーバーや常駐ツールは一度止めないと、更新の意味が通りません。

【CHECK】更新前に DB やサイトのバックアップが必要か、という質問をよく見ます。同じ系列の更新なら不要です。Node.js はアプリ本体のランタイムで、コードやDBには触らないためです。心配な人は node_modules を消して npm install で戻せる状態にしておけば十分です。

更新先はどう選ぶ？24.22.3 / 26.13.1 / 22.23.5

いま使っている系統を選択しましょう。24系列を使っているのであれば 24.22.3 です。
系列（メジャーバージョン）を変えない更新は、壊れる可能性が最も低く、速く終わります。

いま使っている版	今回の更新先	変更の大きさ	サポート終了予定
22.x	22.23.5	同じ系列（ほぼ無傷）	2027年4月30日
24.x（例：24.19.0）	24.22.3	同じ系列（ほぼ無傷）	2028年4月30日
26.x	26.13.1	同じ系列（ほぼ無傷）	2029年4月30日
25.x / 20.x 以前	修正版は出ません	サポート中の系列へ移行	—

系列を上げるのは「あとで」でいい

2026年10月28日に 26系列が LTS（長期サポート）に入ったので、遠からず 26へ移るのが本来の姿です。ただし系列をまたぐと npm の挙動や既定値が変わるため、依存モジュールの作り直しが必要になることがあります。セキュリティ目的なら同系列のマイナーバージョンアップで一旦止めて、必要になったら 26へ移るのが事故の少ない順番です。

nvm・wingetとどこが違うのか（3通り比較）

方法	何をするか	こんな人向き
MSIを再実行（本記事）	新しいMSIをもう一度走らせて差し替える	1つのNode.jsだけ使う人。追加の道具を増やしたくない人
nvm-windows	バージョン管理ツールで切り替える。事前にMSI版の削除が必要	プロジェクトごとに版を変える必要が出てから
winget	コマンド1本で更新。ただし系列は選べないことが多い	コマンド操作に抵抗がない人

winget について、実際に私の環境で確認した結果を残しておきます。

winget list では OpenJS.NodeJS.LTS 24.19.0 がインストール済み、提供版は 26.13.1 と出力されました。
さらに winget show OpenJS.NodeJS.LTS --versions の24系列は 24.22.1 までで、24.22.3 は 2026年11月12日時点で未登録でした。

winget list                       # OpenJS.NodeJS.LTS  24.19.0 → 26.13.1
winget show OpenJS.NodeJS.LTS --versions
# 26.13.1 / 26.13.0 / 24.22.1 / 24.22.0 ...

【POINT】つまり winget upgrade を実行すると 24系列から26系列へまたがって更新されます。今回のように系列を据えて更新したいなら、MSIを直接実行するのが確実です。パッケージ配布の追いつきは数日〜2週間程度ズレることがあるので、セキュリティ更新では「待つ」より自分で取得しに行くほうが早く安全です。

更新のメリットと、あえて触らないデメリット

メリット

• Highの脆弱性7件が閉じる（秘密鍵や他の人のリクエストが漏れうる件を含む）
• Node.jsそのものだけでなく、同梱部品（undici・llhttp・sqlite）の修正も同時に適用される
• サポート終了が近づく22系列では、更新しておくと後年の移行が楽になる
• 「最新を入れておく」だけで、後から原因調査をしなくて済む。これが一番の節約です

デメリット・注意点

• 同じ系列の更新で壊れることは滅多にありませんが、ゼロではない。ネイティブ拡張モジュールを使っていると再ビルドが必要になることがある
• 常駐していたツールは再起動が必要。止めたことを忘れて「動かなくなった」と勘違いしやすい
• 系列をまたぐと npm の既定動作が変わり、ロックファイルの作り直しで差分が大きくなることがある

更新で「変わるもの」「変わらないもの」

変わらない	変わる
PATH（C:Program Files\nodejs）	Node.js のバージョン
グローバルに入れたnpmパッケージ（%APPDATA%\npm）	同梱の npm のバージョン
各プロジェクトの node_modules と package.json	同梱ライブラリ（undici / llhttp / OpenSSL など）
既存のスクリプト・設定ファイル	脆弱性データベース上の評価

「更新で全部やり直し」ではないため、更新前と使用感は変わらないはずです。

戻し方：更新で何か起きたら

Node.js の古い版は nodejs.org/dist に全部残っています。つまり、いつでも好きな版へ戻せます。手順は更新と対称です。

# 1) 設定 → アプリ → Node.js → アンインストール
# 2) 旧版のMSIをダウンロードして実行（例：24.19.0）
https://nodejs.org/dist/v24.19.0/node-v24.19.0-x64.msi

「更新したら特定のツールが動かない」と気づいたときは、まず node -v が本当に変わったか、where.exe node の1行目が期待通りかを確認してください。ここで大半が切り分けられます。直らない場合は上記で1つ戻し、ツールの側が要求するバージョンを調べます。

初心者がつまずきやすい6つポイント

1. 更新したのに node -v が古いまま

MSIの上書きでは PATH が同じ場所を指すので、表示が変わらないときは更新そのものが完了していないことが多いです。インストールが途中で失敗していないか（UACを拒否した、削除（Remove）を選んだ）をまず確認してください。

更新が済んでいるのに古い表示が出る場合は、where.exe node を実行して1行目を見ます。nvm、Visual Studio、WSL などが入れた別の node.exe が PATH の前で拾われているケースがほとんどで、この場合は PATH の並び順を直せば解決します。

2. インストーラーが失敗する（ファイルがロックされている）

VS Code や開発サーバーが起動したままだと、node.exe が使われたままなので差し替えられません。関連アプリを閉じてから再実行します。閉じたつもりでもバックグラウンドに残ることがあるので、タスクマネージャーで node.exe を探すと確実です。

3. MSIが実行できない（x64とarm64の取り違え）

ARM版のWindowsに x64 版を当てるとエラーになります。node -p "process.arch" が arm64 なら -arm64.msi を使います。process.arch が x64 なら -x64.msi です。

4. 後からnvmを入れたい

nvm-windows は「自分の管理下にNodeを置きたい」ツールなので、インストーラー版が残ったままnvmを入れると競合します。入れるなら先にアプリと機能からNode.jsをアンインストールし、以後は nvm install／nvm use で管理します。複数の版を切り替える予定が本当にあるか、まず考えてから決めてください。

5. Docker・VS Code・AIツールの中のNodeは別物

PC本体のNode.jsを更新しても、コンテナイメージや、ツールが同梱しているNode.jsは更新されません。Dockerイメージなら docker compose build --pull や公式イメージの更新で、ローカル開発環境ごと作り直すことになります。

Node.jsそのものを入れたことがない方は、先にこちらの手順記事を用意しています。生成AI系のツール導入で必要になるGitの入れ方も、同じ流れでまとめました。

【初心者向け】Node.jsとは？生成AIツールに必要な理由と正しいインストール手順
【初心者向け】Gitとは？なぜローカルAI導入で必要なのか＆Windowsインストール手順

6. 更新を忘れないための仕組みづくり

いちばん効くのは、アナウンスが来る場所を1つフォローしておくことです。公式ブログの /blog/vulnerability ページ、nodejs-sec メーリングリスト（低 volume）、リリース予定の GitHub。加えて、半年に1回「node -v を見て LTS の表と比べる」などしておけば十分です。

サポート切れ（EOL）の系列は速やかにアップデートしましょう。

よくある質問

Q1. nvmを入れないと更新できないですか？

いいえ。nvmは複数のバージョンを切り替える道具で、更新そのものには不要です。1つのNode.jsを使っているだけなら、MSIを再実行するほうが速くて安全です。nvmが必要になるのは、プロジェクトごとに 22系 と 24系 を使い分けるといった状況になったときに検討しましょう。

Q2. 更新すると作っているサイトやアプリは壊れますか？

同じ系列の中（24.19.0 → 24.22.3 など）であれば、壊れることは基本的にありません。セキュリティ修正とバグ修正が中心で、機能の追加や削除はほぼ起きないからです。リスクが上がるとしたら系列をまたぐときで、この場合は npm install の実行と動作確認を前提に作業します。

Q3. 「24.22.3」と「26.13.1」どちらを入れればいいですか？

いま24系列なら24.22.3です。今回の目的は脆弱性を閉じることなので、系列を変えないほうが安全に終わります。26系列へ移すのは、動作確認の時間を取れるときに別途やるのがおすすめです。

Q4. 更新前にバックアップは必要ですか？戻せますか？

同じ系列の更新なら不要です。壊れたことに気づいたら、アプリと機能からNode.jsを削除して、使っていた版のMSIを実行すれば元に戻ります。古い版も公式の dist に残っています。心配なら node_modules を消して npm install で復元できる状態にしておくと安心です。

Q5. Windows Update やwingetで勝手に更新されませんか？

インストーラーで入れたNode.jsは、Windows Updateでは更新されません。winget を明示的に実行した場合だけ更新されます。つまり既定では誰も更新してくれないので、アナウンスを見て自分で動かす必要があります。ここが「放置されているNode.js」が一番多い理由です。

Q6. 更新しないとどうなりますか？

脆弱性が残ったまま動き続けます。目に見える症状は出ないので、気づいたときに手遅れになりやすい。さらに、その系列のサポートが終わると修正版そのものが届かなくなります。実際に今、サポート切れの系列では修正が提供されません。更新の所要時間3分と、事故が起きたときの調査時間を比べるまでもないはずです。

まとめ：今日やることは3つ

• node -v で系列を確認する（24.19.0 なら 24系列）
• 同じ系列の修正版MSIをダウンロードして実行する（24系列なら 24.22.3）
• 新しいターミナルで node -v を確認し、止めた開発サーバーや常駐ツールを起動し直す

このPCで実際に確認できたのは、①レジストリに Node.js 24.19.0 がMSIとして登録されている ②wingetの24系列は 24.22.1 までで、24.22.3 はまだ来ていない ③公式の dist には node-v24.22.3-x64.msi が既にある——の3点です。だから winget を押して系列をまたぐより、MSIを直接当てるのが最短だと判断できました。

【POINT】更新が終わったら npx is-my-node-vulnerable をもう1回。公式ツールが「OK」と言うかどうかで、自分の目で完了確認ができます。