Next.jsの脆弱性一覧【2026年】GHSA・CVE番号で影響バージョンと修正版を確認する

セキュリティ通知やGitHubのアラートで GHSA-vcvr-r3jv-pc5j のような番号を見かけたとき、知りたいことは3つです。自社のNext.jsは該当するのか。該当するなら何番に上げればよいのか。急ぐ必要があるのか。

この記事は、2026年にNext.jsで公表された脆弱性を番号ごとに一覧にし、この3つをその場で判断できるように整理したものです。番号で検索してたどり着いた方は、一覧表から該当の行を探してください。

先に、要点をまとめます（2026年10月2日更新）。

• いま当てるべき修正版は、16系なら16.3.8、15系なら15.5.27 です。9月30日の定期リリースで7件が修正されました。前日の16.3.7には修正は入っていません。14系以前は公式のサポート対象外で、修正版は原則として提供されません
• 予告されていた9件のうち、Critical 1件とHigh 1件は修正が延期 され、後日のリリースに回っています（10月2日時点で日付は未公表）
• 公表直後の脆弱性は npm audit に出ません。9月22日公表の GHSA-vcvr-r3jv-pc5j はデータベース登録が9月30日で、9月30日公表の7件は10月2日時点で未登録です。公表から数日〜2週間ほどは、公表元を直接確認する必要があります

いま当てるべきNext.jsの修正版は？

2026年10月2日時点では、16系は16.3.8、15系は15.5.27が最新の修正版です。いずれも9月30日の定期リリースで公開されました。

直近の修正版を系列ごとにまとめると、次のとおりです。

9月30日のリリースは、当初「16.3.7と15.5.27」と予告されていましたが、9月29日に不具合修正だけの16.3.7が先に出たため、16系の修正は16.3.8になりました（事前告知の追記）。16.3.7で更新を止めている場合は、16.3.8まで上げる必要があります。7件の条件と判定方法はNext.js 16.3.8・15.5.27の脆弱性7件｜9月30日の修正に自社が該当するか設定で判定するで詳しく扱っています。

15.5.26は、9月22日の臨時リリースで出た版です。この時のRCE（GHSA-vcvr-r3jv-pc5j）は15系には影響せず、15.5.26には関連する堅牢化だけが入っています（Next.js公式の告知）。

15系は2026年10月21日でサポートが終わるため、10月下旬以降に公表された脆弱性には修正版が出ない前提で考えます。移行の判断はNext.js 15のサポート期限は2026年10月21日｜EOLで何が起きるか・16への移行で決めることで整理しています。

2026年に公表された脆弱性の一覧

2026年1月から9月までに、Next.jsのリポジトリでは41件のセキュリティアドバイザリが公表されています。多くは定期リリースでまとめて修正され、8月と9月は臨時のリリースも出ました。

以下は vercel/next.js のSecurity Advisories を2026年10月2日に取得して整理したものです（9月30日公表分の修正版は、アドバイザリの欄が未確定のため リリースノート で確認）。日付はアドバイザリの公開日（UTC）で、深刻度はアドバイザリの表記に合わせています。「内容」の列はアドバイザリの見出しを日本語にしたもので、該当する条件の詳細は各アドバイザリ本文で確認してください。

9月30日：定期リリース（16.3.8 / 15.5.27）

予告では9件でしたが、Critical 1件とHigh 1件は上流の依存関係との調整待ちで延期されました（September 2026 Security Release）。どの設定を使っていると該当するかは、9月30日のリリースの解説にまとめています。

9月22日：臨時リリース（16.3.6 / 15.5.26）

影響するのは、外部から受け取った値をSVGの中身・属性・スタイルに入れて画像を生成している場合です。Edgeランタイムの ImageResponse を使っている場合と、外部の値をSVGに入れていない場合は対象外とされています（GHSA-vcvr-r3jv-pc5j）。OG画像を動的に作るルートで、クエリパラメータの値をそのままタイトルに入れている構成は確認対象です。

8月25日：臨時リリース（16.3.3 / 15.5.24）

GHSA-2xp9-vwfh-vxw4は sharp が内部で使う libheif の脆弱性に由来し、修正版ではAVIFの最適化自体が無効化されています。GHSA-p293-qw3h-jr36は、Pages RouterとApp Routerを併用し、Cache Componentsを使っていないアプリがWindows上で動く場合が対象で、公式ブログでは回避策がないと明記されています（August 2026 Security Release）。

7月21日：定期リリース（16.2.11 / 15.5.21）

この回から、Next.jsは事前に日付を告知する定期リリースの運用を始めています（運用開始の告知、July 2026 Security Release）。9月30日の予告も同じ運用です。

5月6日・7日：定期リリースと追補（16.2.5 / 15.5.16、追補 16.2.6 / 15.5.18）

Middleware / Proxyでの認可チェックを迂回できる件が、5月だけで4件あります（7月にも1件）。ログイン確認をMiddleware（16系ではproxy.ts）だけに任せている構成では、影響の確認を優先します。認可をどこに置くかは社内システムの権限設計をNext.js 16でどう実装するかで扱っています。

4月8日：16.2.3 / 15.5.15

3月16日：16.1.7 / 15.5.13・15.5.14

1月26日：16.1.5 / 15.5.10

表を下からたどると、1月の修正版は16.1.5でした。16系はそこから3月・4月・5月・7月・8月・9月の修正を経て、16.3.8になっています。修正は後の版に引き継がれるので、16.3.8に上げればこの表の16系の修正はすべて入ります。一方で、上げる幅が大きいほど、検証で確かめる挙動の変化も増えます。更新の前に「最後に当てた版」以降の行を見て、自社で使っている機能に関わるものを洗い出しておくと、検証する画面を絞り込めます。

自社が該当するかはどう判定する？

「版の確認」「影響する版との照合」「条件の確認」の3段階で判定します。版だけを見て該当すると決めると、実際には使っていない機能のために急ぎの対応をすることになります。

1. 本番で動いている版を確認する

# プロジェクトのルートで実行
npx next --version
npm ls next

package.json に "next": "^16.3.3" と書いてあっても、実際に入っている版はロックファイルとインストールの時期で変わります。確認するのは「本番環境で実際に動いている版」です。開発会社や保守の委託先に確認するときも、この言い方で伝えると認識がずれにくくなります。

2. 影響する版と照合する

上の一覧の「影響する版」「修正版」の列と照らし合わせます。修正版以上なら、その番号は対応済みです。

3. 条件を確認する

版が範囲に入っていても、条件に当てはまらなければ影響はありません。2026年の一覧に出てくる条件は、おおむね次の種類に分かれます。

条件の判定には、アプリの構成を知っている人の知識が要ります。ここが社内で判断できない場合は、判定を誰に頼むかを先に決めておくほうが、番号を調べ直すより早く片付きます。

npm auditやDependabotだけで気づけるか？

公表からしばらくのあいだは気づけません。npm audit とDependabotが参照するGitHub Advisory Databaseには、Next.jsのリポジトリで公表されたアドバイザリが数日〜2週間ほど遅れて載るためです。

GitHubのAPIで公開日時を比べると、次のようになっていました（2026年10月2日確認）。

実際に、next@16.3.5 だけを依存関係に持つプロジェクトで npm audit を実行すると、9月25日時点では next について何も表示されませんでした。16.3.5はGHSA-vcvr-r3jv-pc5jの影響範囲（16.2.0以上 16.3.6未満）に入っています。データベースに登録された後の10月2日に同じ手順で実行すると、GHSA-vcvr-r3jv-pc5jがcriticalとして表示されました。一方、next@16.3.6 では、9月30日の7件は10月2日時点で何も表示されません。

つまり npm audit の結果が0件でも、直近の公表分は確認できていない可能性があります。この時間差を埋めるには、公表元を直接見ます。

• Next.js公式ブログのセキュリティ告知（定期リリースは事前に日付が告知されます）
• vercel/next.js のSecurity Advisories（リポジトリのReleasesをWatchしておくと、修正版の公開にも気づけます）

手作業での確認を減らしたい場合は、公表元のアドバイザリと、インストール済みの next の版を突き合わせるスクリプトを置いておく方法があります。次の例は、Next.jsのリポジトリのアドバイザリをGitHubのAPIから取得し、同じメジャー系列の修正版より古ければ「要確認」として一覧にします。修正版の欄が 16.3.? のように確定していないアドバイザリは、版を比べずに「要確認」に回します（2026年10月2日に修正）。

// scripts/check-next-advisories.mjs
// 使い方: node scripts/check-next-advisories.mjs [日数(既定90)]
import { createRequire } from "node:module";
import semver from "semver";

const require = createRequire(import.meta.url);
const installed = require("next/package.json").version;
const days = Number(process.argv[2] ?? 90);
const since = Date.now() - days * 24 * 60 * 60 * 1000;

const res = await fetch(
  "https://api.github.com/repos/vercel/next.js/security-advisories?per_page=100",
  { headers: { Accept: "application/vnd.github+json" } },
);
if (!res.ok) throw new Error(`GitHub API ${res.status}`);

const rows = [];
for (const a of await res.json()) {
  if (Date.parse(a.published_at) < since) continue;
  // 修正版の表記は "16.3.6" や "15.5.14, 16.1.7" など。同じメジャー番号の版だけを見る
  const patched = (a.vulnerabilities ?? [])
    .filter((v) => v.package?.name === "next")
    .flatMap((v) => (v.patched_versions ?? "").split(","))
    .map((s) => s.trim())
    .filter((s) => s.startsWith(`${semver.major(installed)}.`));
  // "16.3.?" のように番号が確定していない表記は、semver.coerce で 16.3.0 と解釈され見落とすため別扱いにする
  if (patched.some((s) => !semver.valid(s))) {
    rows.push({ id: a.ghsa_id, cve: a.cve_id ?? "-", severity: a.severity, fixedIn: "未確定（リリースノートで確認）", summary: a.summary });
    continue;
  }
  const target = patched.sort(semver.compare)[0];
  if (target && semver.lt(installed, target)) {
    rows.push({ id: a.ghsa_id, cve: a.cve_id ?? "-", severity: a.severity, fixedIn: target, summary: a.summary });
  }
}

console.log(`next@${installed}（直近${days}日の公開分）: 要確認 ${rows.length} 件`);
if (rows.length) console.table(rows);
console.log("影響の有無は、各アドバイザリの影響バージョンと条件（機能・ランタイム・OS）で最終判断してください。");
process.exitCode = rows.some((r) => r.severity === "critical" || r.severity === "high") ? 1 : 0;

next@16.3.6 の環境で10月2日に実行すると、9月30日の7件が表示されます（6件は修正版「未確定」、GHSA-h694-7cp9-m8p3は16.3.8）。修正版の欄が未確定のアドバイザリは、手元の版が新しくても表示され続けるため、リリースノートで修正版を確認したら対応済みとして扱ってください。修正前のこのスクリプトでは、16.3.? が16.3.0と解釈され、7件中1件しか表示されませんでした。リリースノートから修正済みの番号を拾う方法は、9月30日のリリースの解説で紹介しています。影響する版の範囲を文字列から解釈する代わりに、修正版との比較だけで判定しているのは、アドバイザリごとに範囲の書き方がそろっていないためです。そのため、影響範囲の下限より古い版でも「要確認」に出ることがあります。最終的な判断は、手順3の条件確認で行います。

CIに組み込む場合は、終了コードでHigh以上の有無を返すようにしてあります。GitHub APIは認証なしだと1時間あたりのリクエスト数に上限があるため、日次の定期実行にとどめるか、Authorization ヘッダーにトークンを付けてください。

延期された2件の公表までに何を準備する？

延期されたCritical 1件とHigh 1件は、10月2日時点で日付も中身も公表されていません。準備できるのは「公表されたらすぐ試せる状態」を作ることです。16.3.8の適用、検証環境の用意、作業する人の確保の3つです。

• 16.3.8／15.5.27を先に当てておく：延期分の修正はこれより後の版に入るため、先に今回の更新を済ませておくと、次回は差分の小さい更新で済みます。当てていない回の修正（16.3.3未満なら8月のAVIF最適化の無効化など）の影響も、まとめて確認する必要があります
• 検証環境で主要画面を動かせるようにしておく：ログイン、フォーム送信、画像表示、決済など、止めると困る画面の確認手順を用意します
• 公表後すぐに作業できる人を決めておく：Criticalが含まれるため、条件に当てはまった場合に数日以内に本番へ反映できる段取りが要ります。15系のサポートは10月21日で終わるため、延期分が15系に提供されるかは公表時に確認します

パッチの検知・判定・適用を誰が担うか、内製で回すか保守を委託するかの判断は、Next.jsのCVE対応は誰がやるのかで整理しています。保守契約でどこまでを範囲に含めるかはNext.js保守運用の費用と契約も参考にしてください。

まとめ

• 2026年10月2日時点の最新の修正版は、16系が16.3.8、15系が15.5.27 。9月30日に7件が修正され、Critical 1件とHigh 1件は後日に延期されています
• 2026年は1月から9月までに41件のアドバイザリが公表されています。最新の修正版には過去の修正も含まれるため、更新前に「最後に当てた版」以降の行で、自社が使う機能に関わるものを確認します
• 判定は、版の確認、影響する版との照合、条件（機能・ランタイム・構成・OS）の確認の3段階で行います
• npm audit とDependabotには、公表から数日〜2週間ほど遅れて載ります。直近の公表分は公式ブログとリポジトリのアドバイザリで直接確認します

この一覧は、新しいセキュリティリリースが出たら更新します。

私たちは、Next.jsで開発したシステムの保守として、脆弱性の影響判定から検証、本番への反映までをお手伝いしています。「どの版で動いているか分からない」「この番号に該当するか判断してほしい」という段階からご相談いただけます。15分のカジュアルな相談も受け付けています（要件が固まっていなくても大丈夫です／営業はしません）。

※本記事の脆弱性情報は、2026年10月2日時点の vercel/next.js のSecurity Advisories、Next.js公式ブログ、Next.js Support Policy に基づく整理です。影響範囲や修正版は更新されることがあるため、対応の判断にあたっては各アドバイザリの最新の内容を確認してください。