Next.js 脆弱性（2026年10月）：影響バージョンと対応方法

2026年10月25日、自分でホスティングしている Next.js サイト7つを監査したところ、6つが脆弱なバージョンのままでした。このポートフォリオも 16.2.10 でした。原因は、10月14日に臨時リリースで修正された Next.js 脆弱性です。深刻なリモートコード実行（RCE）が2件、サービス拒否（DoS）が1件。

この記事では、影響を受けるバージョン、数分でできる確認方法、私が何を変えて何を残したかをまとめます。Instagram と LinkedIn では15個の ID を並べたセキュリティ系リールが出回っていますが、そのうち1つのラベルは誤りです。対応方法に関わるので、そこから始めます。

10月14日の Next.js 脆弱性：修正された内容#

情報源は Next.js 公式の 2026年10月14日付セキュリティアップデート と、そこからリンクされた GitHub Advisory です。修正版は 16.4.1 と 15.5.28。10月25日時点の npm 最新版は 16.4.3 です。

Pages Router で Server Actions がなければ、3つ目は影響しません。1つ目と3つ目に回避策はありません。1つ目について Vercel は、該当する関数がなくてもアップグレードするよう勧めています。私もそうしました。

CVE-2026-96889 は Next.js の CVE ではない#

リールは「Next.js CVE-2026-96889」と書いています。しかしレコードを見ると、これは librsvg の use-after-free（"xml includes have duplicated entities"）で、9月23日に Red Hat が CNA として公開、CVSS v3.1 は 7.8 です。Next.js は、SVG を librsvg で描画する sharp 経由でこれを取り込みます。sharp 側の Advisory は GHSA-wq5f-xc86-pv6w で、0.35.5 未満が対象です。

ラベルの違いが重要なのは、対処が変わるからです。next を更新するか、sharp を 0.35.5 以上にするかのどちらかが緩和策になります。ここに落とし穴があります。next@16.4.3 は sharp ^0.35.5 に依存しますが、next@15.5.28 は ^0.34.3 || ^0.35.5 を許容します。つまり 15.x では、更新後も lockfile が sharp 0.34.x のまま残ることがあります。私の環境で実際にそうなっていたので、sharp は明示的に固定しています。

慌てる前にあと2点。リールの15個の ID はいずれも CISA KEV カタログに入っていません（10月23日版で確認）。CISA ADP の評価でも、悪用状況は1件を除いてすべて「none」で、例外がこの CVE の「poc」です。「Black October」という名前の攻撃キャンペーンがあるわけではなく、nginx、Next.js、GitLab、PHP、Node.js、Java の実在する Advisory が2週間に重なっただけです。残りの一覧は 2026年10月 CVE まとめ で扱っています。

Next.js のバージョンと影響範囲の確認方法#

ここでブラウザに表示されるバージョンは信用していません。lockfile と、動いているコンテナを確認します。

npm ls next sharp                  # pnpm の場合: pnpm why next
npm view next dist-tags            # npm の最新タグ
npm audit --omit=dev               # pnpm の場合: pnpm audit --prod
docker run --rm <image> node -v    # イメージ内の Node バージョン

次に、どの Advisory が自分に当てはまるかを grep で確認します。

grep -rn "use cache" app src       # 1つ目の RCE
grep -rn "use server" app src      # Server Actions の DoS
grep -n dangerouslyAllowSVG next.config.*   # SVG 経路

use cache がなければ1つ目には当たりませんが、更新はしておきます。"use server" がなければ DoS は除外できます。設定に dangerouslyAllowSVG: true があれば、最も注意して見るべき箇所です。

対応方法：Next.js、sharp、zod、Docker の Node#

私が行った順に書きます。

npm install next@16.4.3            # 16.x の場合
npm install next@15.5.28           # 15.x の場合
npm install sharp@^0.35.5          # 明示的に固定

1. Next.js。 16.x は 16.4.3、15.x は 15.5.28 へ。9月の更新を飛ばしていた場合は、以前の Advisory も思い出してください。Windows サーバーでの RCE（CVE-2026-75604、15.5.24 と 16.3.3 で修正）、AVIF を使う Image Optimization の RCE（同じバージョン）、next/og ImageResponse の RCE（CVE-2026-94545、16.3.6 で修正）です。現行版へ一気に上げればすべて含まれます。
2. sharp。 上記の理由で ^0.35.5 に固定します。以前の sharp Advisory（libvips の GHSA-f88m-g3jw-g9cj、libheif の GHSA-rgj7-g3m4-5g8c）も同じ固定でカバーされます。
3. zod。 lockfile を触ったついでに zod 4.x を 4.6.6 以上へ。GHSA-mrhx-c7xc-m3w5 は、制約付きの巨大なコレクションによるメモリ枯渇です。
4. Docker の Node。 10月21日に Node.js 22.23.4、24.22.1、26.12.1 が公開されました（公式記事）。重大度 High が4件で、Brotli デコーダの境界外書き込み、dns.resolve* が NUL 文字で名前を切り詰める問題、TLS のホスト名検証バイパス2件です。動いているコンテナは自動では更新されません。イメージの再ビルドが必要です。
5. SVG。 next/image に SVG を一切通していないなら、images.dangerouslyAllowSVG を false に戻します。

Docker では2回つまずきました。ポートフォリオのベースイメージは、古い node:22 ビルドに digest で固定されていました。digest 固定はセキュリティパッチも含めてすべてを凍結しますが、私には更新の仕組みがありませんでした。別のサイトは 2026年4月にサポートが終わった node:20 のままで、修正は一切出ません。浮動タグの node:22-slim も安全とは言えません。ビルドホストのキャッシュから取られることがあり、再ビルドしても新しいパッチが入らないことがあるからです。確実なのは、AWS ミラーの明示的なタグです。

FROM public.ecr.aws/docker/library/node:22.23.4-slim AS base

バリアント（slim や alpine）は今使っているものを選んでください。ビルド後に docker run --rm <image> node -v が v22.23.4 を返せば確認完了です。自分でホストするものすべてに同じ考え方が当てはまります。セルフホストについては ClewWiki のセルフホスト記事 でも触れました。

私の7サイトで見つかったこと#

構成は、1台のサーバー上の Docker で7つの Next.js サイトを動かし、Dokploy でデプロイ、前段に Traefik を置いています。サーバーに nginx、PHP、Java、GitLab はないため、10月のリストの大半は無関係でした。

一番気に入らなかったのは、ポートフォリオの next.config.js です。images.dangerouslyAllowSVG: true がサンドボックス CSP つきで有効になっていましたが、プロジェクト全体で next/image に SVG を渡したことは一度もありませんでした。SVG の脆弱性へ通じる道を、メリットゼロで開けていたことになります。無効にしました。

残っているもの#

更新後に npm audit に残る high は、ビルド時のみのものです。workbox と next-pwa の依存チェーン、そして next 内部の postcss。これらは Docker イメージをビルドしている間だけ動き、サーバープロセスでは動かないため、実行時に攻撃者が到達する経路はありません。次の依存更新サイクルまで残しており、クリーンな結果を装わずにそう書いておきます。もう1つ正直に言うと、ポートフォリオ自体は zod 3 のままで、zod の修正は 4.6.6 にしかありません。2つのスキーマが検証するのは長さ上限つきの短い文字列で、コレクションではないため、メモリ枯渇の脆弱性が膨らむ余地はありません。zod 4 への移行はやることリストに入れてあります。このバッチの RCE 経路は7サイトとも塞がっています。

自分のスタック外には手を付けていません。nginx 1.30.6 / 1.31.7、PHP 8.5.12 と同系列、GitLab、Java にはそれぞれ独自の修正があり、詳細は上にリンクしたまとめにあります。

チェックリスト#

1. npm ls next sharp で next が 16.4.1 以上（現行は 16.4.3）または 15.5.28、sharp が 0.35.5 以上。
2. npm audit --omit=dev に critical がない。
3. next/image で SVG を配信しないなら dangerouslyAllowSVG は無効。
4. zod が 4.6.6 以上。
5. Dockerfile は明示的な node:22.23.4-* タグで、古い digest や node:20 ではない。
6. イメージを再ビルドし、中の node -v が一致する。
7. デプロイ後、実際に新しいビルドがトラフィックを受けている（キャッシュではない）。

10分しかないなら、1、3、5を。2つの深刻な RCE と、私自身の digest 固定が凍結していたパッチをカバーできます。