Node.jsの脆弱性【2026年最新】RCE・Next.jsへの影響と対策

はじめに

2026年10月21日、Node.jsで複数の脆弱性に対応するセキュリティアップデートが公開されました。

今回修正された脆弱性は合計10件です。

その中には、悪意のある圧縮データを処理することで、サーバー上で任意のコードが実行される可能性がある脆弱性も含まれています。

「Node.jsを使ってサーバーを開発していないから、自分には関係ないのでは？」と思う方もいるかもしれません。

しかし、Next.jsによるサーバーサイドレンダリング（SSR）やAPI処理など、Node.jsを実行環境として使用するWebアプリケーションでは注意が必要です。

今回は、2026年10月に公表されたNode.jsの脆弱性を中心に、以下を解説します。

Node.jsとは何か
2026年に公表された主な脆弱性
リモートコード実行（RCE）とは何か
具体的にどんなWebアプリケーションが影響を受けるのか
React・Next.jsへの影響
Node.jsのバージョン確認方法と対策

できるだけ実務でイメージできるように、具体例を交えて紹介します。

※本記事は2026年10月24日時点の公式情報をもとにしています。

Node.jsとは？

Node.jsは、JavaScriptをブラウザの外で実行するためのランタイム環境です。

一般的にJavaScriptはブラウザ上で動作するイメージがあると思います。

しかし、Node.jsを使用すると、JavaScriptでWebサーバーやAPIを開発することもできます。

例えば、以下のようなコードです。

import http from "node:http";

const server = http.createServer((req, res) => {
  res.writeHead(200, {
    "Content-Type": "application/json"
  });

  res.end(JSON.stringify({
    message: "Hello World"
  }));
});

server.listen(3000);

このコードを実行すると、ポート3000でHTTPリクエストを受け付けるサーバーが起動します。

Spring Bootで例えるなら、Javaの実行環境でSpring Bootアプリケーションを動かすのと同じように、Node.js上でJavaScriptのサーバーアプリケーションを動かしているイメージです。

ただし、Spring BootやNext.jsはフレームワークであり、Node.jsは実行環境という違いがあります。

2026年10月に公表されたNode.jsの脆弱性10件

2026年10月21日のセキュリティアップデートでは、以下の10件が修正されました。

CVE番号	脆弱性の内容	深刻度
CVE-2026-111497	Brotli解凍処理でメモリ破損・RCEの可能性	High
CVE-2026-105482	DNS解決時のNUL文字によるホスト名切り詰め	High
CVE-2026-105483	全角数字を含むIPアドレスでTLS証明書検証を回避	High
CVE-2026-106069	特殊なIPv4表記によるTLS証明書検証の不備	High
CVE-2026-105481	Keep-Alive接続で不正なレスポンスを受理	Medium
CVE-2026-106072	非標準IPv4表記で不適切な証明書を受理	Medium
CVE-2026-106074	Snapshot利用時にUUIDなどの乱数が重複	Medium
CVE-2026-106070	ZIPファイル検証後に不正なデータを返す	Low
CVE-2026-106071	Permission Modelのファイルアクセス制限回避	Low
CVE-2026-106073	fs.realpathSyncによるアクセス制限回避	Low

※深刻度はNode.js公式の評価です。影響するNode.js系列はCVEごとに異なります。

この中から、特にWebアプリケーション開発者が知っておきたい脆弱性を詳しく見ていきましょう。

① CVE-2026-111497：Brotli解凍処理でリモートコード実行の可能性

今回、最も注目したい脆弱性です。

Brotliとは？

Brotli（ブロトリ）は、データを圧縮するためのアルゴリズムです。

Webアプリケーションでは、HTML・CSS・JavaScriptなどを圧縮し、通信するデータ量を削減する目的で利用されます。

例えば、以下のようなイメージです。

通常のHTTP通信

サーバー
   ↓
大きなレスポンスデータ
   ↓
クライアント

Brotliを利用した場合は、以下のようになります。

サーバー
   ↓
Brotliでデータを圧縮
   ↓
小さな圧縮データを送信
   ↓
クライアント
   ↓
Brotliで解凍
   ↓
元のデータを取得

通信データを小さくできるため、Webアプリケーションの通信効率を改善できます。

Node.jsではnode:zlibを使用して、Brotli形式のデータを圧縮・解凍できます。

どんな脆弱性？

今回の脆弱性は、Node.jsに組み込まれているBrotliの解凍処理に問題があったというものです。

不正な圧縮データが渡されると、内部のバッファ領域を超えてメモリへ書き込むことがあります。

このような問題は、**Out-of-Bounds Write（境界外書き込み）**と呼ばれます。

結果として、以下の問題が発生する可能性があります。

Node.jsプロセスのクラッシュ
プロセスメモリ内の情報漏洩
任意のコード実行（RCE）

RCE（Remote Code Execution）とは、攻撃者が遠隔から対象システム上でコードを実行できる状態になることです。

ただし、脆弱なNode.jsを使っているだけで必ずRCEが成立するわけではありません。

攻撃者が制御するBrotliデータを、脆弱な解凍処理で扱うことが重要な成立条件です。

具体例：圧縮ファイルを取り込むAPI

例えば、外部システムから圧縮ファイルを受け取り、解凍してデータを取り込むAPIがあるとします。

外部システム
    ↓
圧縮データを送信
    ↓
Node.js API
    ↓
Brotliで解凍
    ↓
JSONを解析
    ↓
データベースへ保存

Node.jsでBrotliを解凍するコードは、以下のように書けます。

import { brotliDecompressSync } from "node:zlib";

function decodeData(compressedBuffer) {
  return brotliDecompressSync(compressedBuffer);
}

このコード自体は通常のBrotli解凍処理です。

しかし、compressedBufferに外部から受け取ったデータをそのまま渡す構成では、脆弱なNode.jsを利用している場合に問題となる可能性があります。

正常な圧縮データ
    ↓
Brotliで解凍
    ↓
正常終了

悪意のある圧縮データ
    ↓
脆弱なBrotliで解凍
    ↓
内部のメモリ処理に問題発生
    ↓
クラッシュ・情報漏洩・RCEの可能性

ここで重要なのは、JavaScriptのtry-catchだけではネイティブコード内部のメモリ破損を防げないことです。

入力チェックやデータサイズ制限は必要ですが、根本的な対策は修正版Node.jsを利用することです。

Next.jsでも影響する？

Next.jsをNode.jsランタイムで動作させている場合、影響する可能性があります。

例えば、Next.jsのサーバー側で外部APIからデータを取得するケースです。

async function getExternalData(url) {
  const response = await fetch(url);

  if (!response.ok) {
    throw new Error("データ取得に失敗しました");
  }

  return await response.text();
}

Node.jsのfetch()では、HTTPレスポンスの圧縮データが自動的に展開される場合があります。

そのため、攻撃者が制御できる外部サーバーのBrotliレスポンスを取得する構成では、今回の脆弱性が関係する可能性があります。

ただし、Next.jsでfetchを使用しているだけで、必ず攻撃が成立するわけではありません。

実際の影響は、使用するNode.jsのバージョン、通信先、レスポンスの圧縮形式、利用するライブラリなどによって変わります。

また、fetch()で任意のURLを受け付ける設計では、別途SSRF（Server-Side Request Forgery）への対策も必要です。

影響バージョンと修正版

Node.js系列	影響するバージョン	修正版
Node.js 22	22.23.4未満	22.23.4
Node.js 24	24.22.1未満	24.22.1
Node.js 26	26.12.1未満	26.12.1

※上記は各系列の修正前バージョンを示しています。古いサポート終了系列については、サポート対象への移行が必要です。

② CVE-2026-105482：DNS解決時に意図しない接続先を参照する問題

次はDNSに関係する脆弱性です。

DNSとは？

DNSは、ドメイン名からIPアドレスを調べるための仕組みです。

例えば、

example.com
    ↓ DNSによる名前解決
IPアドレス
    ↓
対象サーバーへ接続

という流れです。

Node.jsではnode:dnsを使用して、DNSの名前解決を実行できます。

どんな脆弱性？

Node.jsのdns.resolve*()やdns.reverse()で、ホスト名にNUL文字（\0）が含まれている場合、名前の途中で切り詰められる問題がありました。

例えば、以下のような文字列です。

attacker.example\0.trusted.example

アプリケーション側では、これを1つのホスト名として扱っているとします。

しかし、脆弱なDNS処理ではNUL文字以降が無視され、実際には次のホスト名が問い合わせられる可能性があります。

attacker.example

つまり、アプリケーションが検証したホスト名と、実際にDNSで解決されるホスト名が一致しないことが問題です。

具体例：外部API連携

例えば、接続可能なドメインを制限するAPIを考えます。

ユーザーからURLを受け取る
    ↓
接続可能なドメインかチェック
    ↓
DNSでIPアドレスを取得
    ↓
外部APIへ通信

ドメイン名のチェックとDNS処理で文字列の解釈が異なると、意図しない接続先を参照してしまう可能性があります。

これは、SSRF対策や接続先制御を考える際にも重要なポイントです。

なお、今回の脆弱性は特定のDNS APIに関係するものであり、すべてのURL検証処理が同じように回避できるわけではありません。

③ CVE-2026-105483・CVE-2026-106069：TLS証明書検証の不備

次はHTTPS通信に関連する脆弱性です。

TLS証明書の検証とは？

HTTPS通信では、通常、サーバーの証明書を検証します。

証明書が信頼できる認証局によって発行されているかだけでなく、接続先のホスト名に対して正しい証明書かどうかも確認します。

例えば、

https://api.example.com

へ接続する場合、api.example.comに対して有効な証明書である必要があります。

どんな脆弱性？

今回、特殊なIPアドレス表記によって、接続先の解釈と証明書検証時の解釈が一致しない問題が発見されました。

例えば、以下のような表記です。

通常の表記
127.0.0.1

特殊な表記
１２７.0.0.1
0127.0.0.1

最初の特殊な例には全角数字が含まれています。

また、先頭に0があるIPv4アドレスは、処理系によって数値の解釈が異なる場合があります。

このような違いによって、本来は受け入れるべきではない証明書を受け入れてしまう可能性がありました。

具体例：外部決済APIへの接続

例えば、Node.jsのバックエンドから外部決済APIへHTTPS通信するシステムがあるとします。

Node.jsアプリケーション
    ↓
HTTPSリクエスト
    ↓
TLS証明書を検証
    ↓
決済APIサーバー

通常は正しい接続先の証明書であることを確認し、安全な通信を確立します。

しかし、証明書検証に不備がある場合、特殊な接続先表記や証明書の条件が揃うことで、不適切な証明書が受け入れられる可能性があります。

この問題は、通信相手の真正性を確認する仕組みに影響します。

なお、CVE-2026-105483はNode.js 24系・26系が対象で、CVE-2026-106069は22系・24系・26系が対象です。

④ CVE-2026-106074：UUIDが重複する可能性

こちらは、個人的に興味深い脆弱性です。

UUIDとは？

UUIDは、重複しにくい識別子を生成する仕組みです。

Webアプリケーションでは、以下のような用途で利用されます。

ファイル識別子
リクエスト識別子
一時的なセッション識別子
データ登録時の識別子

Node.jsでは、以下のように生成できます。

import { randomUUID } from "node:crypto";

const id = randomUUID();

console.log(id);

どんな脆弱性？

Node.jsには、起動時間を短縮するためのStartup Snapshotという仕組みがあります。

今回の脆弱性では、Snapshotの作成中にUUID生成などを実行すると、内部の乱数キャッシュがSnapshotへ保存されてしまう問題がありました。

その結果、同じSnapshotから起動した複数のプロセスが、同じ値を返す可能性があります。

Snapshot作成時
    ↓
UUID生成処理を実行
    ↓
乱数キャッシュもSnapshotへ保存
    ↓
       ┌─────────────┐
       │             │
プロセスA         プロセスB
       │             │
 同じキャッシュを使用
       │             │
 UUIDが重複する可能性

特に識別子の一意性や予測困難性に依存している処理では問題になります。

公式情報では、条件によって最大127個のUUIDや、約1,000個のrandomInt()の値がプロセス間で繰り返される可能性が説明されています。

ただし、通常のNode.jsアプリケーションでrandomUUID()を利用するだけで発生するわけではありません。

Snapshot生成時の処理が関係する脆弱性である点に注意が必要です。

その他、2026年10月に修正された脆弱性

残りの5件も簡単に紹介します。

CVE-2026-105481：Keep-Alive接続のレスポンス混同

HTTPのKeep-Alive接続を再利用する際、本来リクエストを送信する前に届いていた不正なレスポンスを、新しいリクエストの正常なレスポンスとして受け入れる可能性があります。

CVE-2026-106072：非標準IPv4表記による証明書検証の問題

127.1や0x7f.0.0.1など、通常とは異なるIPv4表記を使用すると、条件によってIPアドレス用の証明書検証が適切に行われない可能性があります。

CVE-2026-106070：ZIPファイル処理の不備

Node.js 26系のzlib.ZipFileで、不正なZIPヘッダーを検証した後に、本来読み取るべきではないデータを返す可能性があります。

CVE-2026-106071：ファイルアクセス許可範囲の問題

Node.js 26系のPermission Modelで、ワイルドカードを使用したファイルアクセス許可が、意図した範囲より広く適用される可能性があります。

CVE-2026-106073：fs.realpathSyncのアクセス制限回避

Permission Modelでファイルの読み取りを制限していても、fs.realpathSync()によって制限対象のパスに関する情報を取得できる可能性があります。

2026年には他にもNode.jsの脆弱性が公表されている

Node.jsの脆弱性は、10月だけではありません。

2026年3月、6月、7月にもセキュリティアップデートが公開されています。

公表日	CVE番号	概要
2026/3/24	CVE-2026-21710	特殊なHTTPヘッダーによるDoS
2026/3/24	CVE-2026-21717	V8のハッシュ衝突による性能低下
2026/6/18	CVE-2026-48933	WebCryptoのAES処理によるDoS
2026/7/29	CVE-2026-56846	HTTP/2でメモリ制限を回避するDoS
2026/7/29	CVE-2026-56848	HTTP/2のメモリ解放後アクセス
2026/7/29	CVE-2026-58043	Permission Modelのファイルアクセス制限回避

これらは2026年に公表された脆弱性の一部です。

特に、HTTP/2やTLS、ファイルアクセス制限に関係する問題が繰り返し修正されている点は興味深いと感じます。

また、今回10月に修正された脆弱性の中には、以前の修正が不完全だったものも含まれています。

セキュリティアップデートを適用して終わりではなく、その後に公開される修正情報も継続して確認することが重要です。

React・Next.jsへの影響は？

ここは、ReactやNext.jsを使用する開発者にとって重要なポイントです。

まず、ReactとNext.jsではNode.jsとの関係が異なります。

Reactの場合

Reactを使用したWebアプリケーションでも、ブラウザ上でのみ動作するJavaScriptについては、ユーザーのブラウザが直接Node.jsを実行しているわけではありません。

例えば、Spring BootでAPIを開発し、Reactを静的ファイルとして配信する構成です。

ブラウザ
   ↓
React（ブラウザで実行）
   ↓ HTTP API
Spring Boot
   ↓
データベース

このような構成では、通常、稼働中のSpring Boot APIがNode.jsの今回の脆弱性によって直接影響を受けるわけではありません。

ただし、Reactのビルド処理や開発環境、CI/CDで使用するNode.jsは別途確認が必要です。

Next.jsの場合

Next.jsをNode.jsランタイムで動作させている場合、状況が変わります。

ブラウザ
   ↓
Next.js（Node.jsランタイム）
   ↓
Server Components / Route Handlers
   ↓ HTTP API
Spring Boot
   ↓
データベース

この構成では、Next.jsがサーバー側で動作するため、Node.jsの脆弱性が直接関係する場合があります。

例えば、次のような処理です。

サーバー側で外部APIからデータを取得する
外部から受け取った圧縮データを展開する
DNSを利用して接続先を解決する
HTTPS通信を行う

今回のBrotliの脆弱性では、攻撃者が制御できる圧縮データをサーバー側で解凍する処理が重要な確認対象です。

なお、Next.js自体のバージョンを更新するだけでは、Node.jsランタイムの脆弱性が必ず修正されるわけではありません。

フレームワークと実行環境の両方を管理する必要があります。

Node.jsのバージョンを確認する方法

ここからは、実際の開発環境で確認する方法です。

① Node.jsのバージョン確認

以下のコマンドを実行します。

node -v

例えば、次のように表示されたとします。

v24.22.0

この場合、2026年10月21日のセキュリティ修正版である24.22.1より前のバージョンです。

アップデートを検討する必要があります。

② 修正版へのアップデート

2026年10月21日に公開された修正版は、次のとおりです。

Node.js系列	修正版
Node.js 22 LTS	22.23.4
Node.js 24 LTS	24.22.1
Node.js 26 Current	26.12.1

バージョン管理ツールnvmを利用している場合、例えばNode.js 24系では次のように更新できます。

nvm install 24.22.1
nvm use 24.22.1
node -v

Windowsでは、利用しているNode.js管理ツールによって手順が異なります。

Node.js公式のダウンロードページから更新する方法もあります。

③ Docker環境の確認

Dockerコンテナ内でNext.jsやNode.jsアプリケーションを動作させている場合、Dockerfileも確認しましょう。

例えば、以下のような構成です。

FROM node:24.22.1-alpine

WORKDIR /app

COPY package*.json ./

RUN npm ci

COPY . .

RUN npm run build

CMD ["npm", "start"]

※これはバージョン指定の例です。実際のNext.jsアプリケーションでは、ビルド方式や必要なファイルに合わせてDockerfileを作成してください。

Node.jsのバージョンを更新した場合、Dockerイメージを再ビルドし、新しいコンテナをデプロイする必要があります。

既存のコンテナが自動で更新されるわけではありません。

④ npm auditだけでは不十分

Node.jsを利用するプロジェクトでは、以下のコマンドを実行することもあると思います。

npm audit

これは主にnpmの依存パッケージに含まれる既知の脆弱性を確認するためのコマンドです。

しかし、今回のようなNode.js本体の脆弱性を、npm auditだけですべて検出できるわけではありません。

そのため、以下の両方を確認することが大切です。

# Node.jsランタイムのバージョン
node -v

# npm依存パッケージの脆弱性
npm audit

Node.js本体のバージョンと、アプリケーションが利用する依存ライブラリは別々に管理する必要があります。

実務ではどのような対策が必要？

今回の脆弱性を踏まえて、個人的には以下を意識したいと考えています。

1. Node.jsのLTSを使用する

本番環境では、原則としてサポート対象のLTS系列を利用することをおすすめします。

サポートが終了したNode.jsでは、セキュリティ修正が提供されない場合があります。

2. 外部データを信用しない

今回のBrotliの脆弱性のように、外部から受け取ったデータを処理することで問題が発生する場合があります。

入力データのサイズ制限や形式検証、アクセス制限なども組み合わせて考える必要があります。

ただし、これらは修正版へのアップデートを代替するものではありません。

3. 本番環境と開発環境のバージョンを確認する

ローカル環境では修正版を使用していても、AWS ECSやEC2、Dockerコンテナなどの本番環境では古いNode.jsが動作している場合があります。

実際にアプリケーションを実行している環境のバージョンを確認することが重要です。

4. フレームワーク以外の脆弱性情報も確認する

Next.jsやReactの脆弱性ばかりを確認していると、Node.js本体の問題を見落とす可能性があります。

Webアプリケーションのセキュリティは、フレームワークだけでなく、ランタイムやミドルウェア、依存ライブラリまで含めて考える必要があります。

まとめ

2026年10月21日、Node.jsで10件の脆弱性に対応するセキュリティアップデートが公開されました。

今回、特に注目したいのは以下の4件です。

CVE-2026-111497： Brotli解凍処理によるメモリ破損・RCEの可能性
CVE-2026-105482： DNS解決時のホスト名切り詰め
CVE-2026-105483： 全角数字を含むIPアドレスでのTLS証明書検証不備
CVE-2026-106069： 非標準のIPv4表記によるTLS証明書検証不備

今回の脆弱性は、Node.jsで直接APIを開発している場合だけでなく、Next.jsのサーバー側処理や、Node.jsを利用した外部システム連携でも関係する可能性があります。

Spring Bootをメインに開発している場合でも、フロントエンドにNext.jsを利用しているなら、Node.jsのバージョンを把握しておきたいところです。

まずは、開発環境や本番環境で次のコマンドを実行してみましょう。

node -v

最新の脆弱性情報を確認し、必要に応じてアップデートを適用することが大切です。

参考情報

是非フォローしてください

Follow @https://twitter.com/fuji67600543

最新の情報をお伝えします

はじめに

Node.jsとは？

2026年10月に公表されたNode.jsの脆弱性10件

① CVE-2026-111497：Brotli解凍処理でリモートコード実行の可能性

Brotliとは？

どんな脆弱性？

具体例：圧縮ファイルを取り込むAPI

Next.jsでも影響する？

影響バージョンと修正版

② CVE-2026-105482：DNS解決時に意図しない接続先を参照する問題

DNSとは？

どんな脆弱性？

具体例：外部API連携

③ CVE-2026-105483・CVE-2026-106069：TLS証明書検証の不備

TLS証明書の検証とは？

どんな脆弱性？

具体例：外部決済APIへの接続

④ CVE-2026-106074：UUIDが重複する可能性

UUIDとは？

どんな脆弱性？

その他、2026年10月に修正された脆弱性

CVE-2026-105481：Keep-Alive接続のレスポンス混同

CVE-2026-106072：非標準IPv4表記による証明書検証の問題

CVE-2026-106070：ZIPファイル処理の不備

CVE-2026-106071：ファイルアクセス許可範囲の問題

CVE-2026-106073：fs.realpathSyncのアクセス制限回避

2026年には他にもNode.jsの脆弱性が公表されている

React・Next.jsへの影響は？

Reactの場合

Next.jsの場合

Node.jsのバージョンを確認する方法

① Node.jsのバージョン確認

② 修正版へのアップデート

③ Docker環境の確認

④ npm auditだけでは不十分

実務ではどのような対策が必要？

まとめ

参考情報

類似投稿