2026.10.23

【2026年版】古いNode.jsからLTS（24・26）へのバージョンアップ手順｜10月の脆弱性とつまずきやすい変更

soflan ・読了 7分

はじめに

この記事では、サポートの終わった古い Node.js（14・16・18・20 など）で動いているアプリを、LTS の 24・26 に上げる手順をまとめました。

まず：2026 年 10 月の Node.js のセキュリティ更新

2026 年 10 月 21 日、Node.js のセキュリティ更新が出ました。修正は 10 件で、そのうち 4 件が深刻度「高」です。

CVE	深刻度	内容
CVE-2026-111497	高	Brotli の展開処理の不具合で、外からプログラムを動かされるおそれ
CVE-2026-105483・106069	高	TLS の証明書のホスト名の確認をすり抜けられる
CVE-2026-105482	高	`dns.resolve` が NUL 文字を含む名前を途中で切ってしまう
ほか 6 件	中・低	乱数が毎回同じになる（起動スナップショット）など

いちばん深刻なのは、Brotli（圧縮の形式）の展開処理の不具合です。攻撃者が用意したデータを展開すると、メモリの中身が漏れたり、外からプログラムを動かされたりするおそれがあります。HTTP の圧縮されたレスポンスなどを扱うアプリは要注意です。

修正版は 22.23.4・24.22.1・26.12.1 です。

サポートの終わったバージョンには修正が出ない

Node.js の公式は「サポートの終わったバージョンは、セキュリティ更新が出るたびに必ず影響を受ける」としています。18・20 などには修正版が出ないので、使い続けている場合は上げるしかありません。

バージョン	状態（10 月 23 日時点）	サポートの期限
26	10 月 28 日から LTS	2029 年 4 月 30 日
24	LTS	2028 年 4 月 30 日
22	LTS（メンテナンス）	2027 年 4 月 30 日
20	終了	2026 年 4 月 30 日に終了
18 以前	終了	18 は 2025 年 4 月 30 日に終了

今から上げるなら 24 か 26

今から上げるなら 24（2028 年 4 月末まで）が無難です。使っているライブラリやホスティング先が対応していれば、10 月 28 日に LTS になる 26（2029 年 4 月末まで）にすると、次の更新までの期間を長くとれます。

なお、Node.js は 27 からリリースの仕組みが変わり、新しいバージョンは年 1 回（10 月）、すべてのバージョンが LTS になる予定です。

バージョンアップの流れ

どこで Node.js のバージョンが決まっているか洗い出す
手元で新しい Node.js に切り替えて、依存パッケージを更新する
ビルドとテストを通す：つまずきやすいところは次の章
CI・Docker・本番サーバーのバージョンをそろえて切り替える

1. バージョンが書かれている場所

Node.js のバージョンは、思ったよりあちこちに書かれています。全部そろえないと「手元では動くのに本番で動かない」が起きます。

.nvmrc・.node-version（バージョン管理ツールの設定）
package.json の engines
Dockerfile の FROM node:...
CI の設定（GitHub Actions の node-version など）
ホスティング先の設定（サーバーレスの実行環境、PaaS の設定など）

2. 新しい Node.js に切り替えて、依存パッケージを更新する

bash

# nvm を使っている場合
nvm install 24
nvm use 24
node -v

# 古いパッケージの一覧と、脆弱性のあるパッケージの確認
npm outdated
npm audit

# node_modules とロックファイルを作り直す（ネイティブモジュールも新しい Node.js 用にビルドし直される）
rm -rf node_modules
npm install

依存パッケージは、まとめて最新にすると原因を切り分けにくくなります。フレームワーク（Next.js・Express・NestJS など）とビルドツールから順に上げましょう。

つまずきやすいところ

npm 7 以降：ERESOLVE（peerDependencies の衝突）

Node.js 14 まで付いていた npm 6 から、npm 7 以降に変わると、peerDependencies を自動で入れるようになりました。古いプロジェクトでは、バージョンの食い違いで npm install が ERESOLVE で止まることがあります。

bash

# とりあえず npm 6 と同じ動きで入れる（応急処置）
npm install --legacy-peer-deps

応急処置なので、エラーに出ているパッケージを、お互いに対応するバージョンに上げるのが本来の直し方です。ロックファイル（package-lock.json）の形式も変わるので、更新したものをコミットしましょう。

Node.js 17 以降：ERR_OSSL_EVP_UNSUPPORTED（OpenSSL 3）

Node.js 17 から OpenSSL 3 になり、古い暗号のしくみ（MD4 など）が既定で使えなくなりました。webpack 4 など古いビルドツールで、ビルドが ERR_OSSL_EVP_UNSUPPORTED で止まります。

bash

# 応急処置（古い暗号を一時的に使えるようにする）
NODE_OPTIONS=--openssl-legacy-provider npm run build

これも応急処置です。webpack 5 や Vite など、新しいビルドツールに上げて直しましょう（Create React App で作ったプロジェクトは、Vite などへの移行が必要になることが多いです）。

Node.js 18 以降：古い Linux で動かない

Node.js 18 以降の公式のバイナリは、glibc 2.28 以上が必要です。CentOS 7 や Amazon Linux 2 など古い Linux では、そのままでは動きません。OS ごと新しくするか、Docker で動かすことを考えましょう。

ネイティブモジュール：node-sass など

C++ で書かれたモジュール（bcrypt・sharp・sqlite3 など）は、Node.js のバージョンごとにビルドし直しが必要です。npm rebuild か、node_modules を消して入れ直します
node-sass は開発が終わっていて、新しい Node.js では動きません。sass（Dart Sass）に置き換えます。多くの場合、package.json の名前を変えるだけで動きます
ネイティブモジュールのビルドに Python やビルドツールが要ることもあります。エラーに出ているモジュールを、最新版（ビルド済みのファイルが配られている版）に上げるのが近道です

新しい Node.js：JSON の import の書き方

JavaScript

// 古い書き方（import assertions）。新しい Node.js ではエラーになる
import data from './data.json' assert { type: 'json' }

// 新しい書き方（import attributes）
import data from './data.json' with { type: 'json' }

ほかにも、22 からは ES モジュールを require() で読み込めるようになるなど、新しいバージョンで便利になったところもあります。

本番を切り替えるときの注意

Docker のベースイメージは node:24-bookworm-slim のように、バージョンと OS をはっきり書く（node:latest は使わない）
CI と本番を同じバージョンにする：.nvmrc を 1 か所に決めて、CI もそれを読むようにすると、ずれにくい
ログを見る：非推奨の警告（DeprecationWarning）も出るので、次のバージョンアップの準備に使える
切り戻しの手順を用意する：古いイメージやバージョンにすぐ戻せるようにしてから切り替える