Next.js 11 月のセキュリティリリース ― 7 件の脆弱性の当たり判定と更新手順

2026 年 11 月 3 日、Next.js の定例のセキュリティリリースが公開されました。修正版は 16.4.5 と 15.5.29 で、直された脆弱性は 7 件です。この記事は、Next.js でサイトやサービスを作って運用しているエンジニアに向けて、自分の担当するアプリがどれに当たるかを判定し、更新の優先度と手順を決められるように整理したものです。内容は 2026 年 11 月 7 日時点の公式ブログと GitHub のセキュリティアドバイザリ（脆弱性の公式の告知）をもとにしています。

今回のリリースの概要

Next.js は 10 月 27 日に「11 月 3 日にセキュリティリリースを出す」と予告し、その日に修正版と 7 件のアドバイザリを公開しました。事前に日付を知らせる「予告つきの定例リリース」なので、更新の計画を立てやすいのが特徴です。

修正版は次の 2 つです。npm の latest タグも 16.4.5 を指しています（16.5 はまだ canary 版のみ）。

npm install next@16.4.5   # 16.x を使っている場合
npm install next@15.5.29  # 15.x を使っている場合

7 件の一覧は次のとおりです。深刻度は GitHub のアドバイザリにある CVSS v4（脆弱性の深刻さを 0〜10 で表す共通の指標）の値です。

自分のアプリが当たるかを判定する

7 件は、どれも「特定の機能を使っているときだけ」影響します。上の表の「主な条件」は、次の 4 つの質問にまとめられます。まずこれに答えると、読むべきアドバイザリが絞れます。

Cache Components を使っているか（1〜4）

next.config に cacheComponents: true があるかを見ます。Cache Components は、use cache という書き方で関数やコンポーネントの結果をキャッシュする仕組みで、16.0.0 で正式な設定になりました。4 件がこの機能に集中しているので、使っている 16.x のアプリは最も急ぐべき対象です。

1〜3 はどれも「キャッシュの見分け方が甘く、別の人向けの結果が返ってしまう」問題です。

• 1 件目：同じ use cache 関数を、直接と unstable_cache() の中からの両方で呼んでいて、その関数がテナント ID のようなルートパラメータを読む場合。キャッシュが空のときに同時にリクエストが来ると、別のテナントの結果が保存され、ほかの利用者にも返り続けます。
• 2 件目：入れ子の use cache で、内側の関数がルートパラメータを読み、すぐ返す値と遅れて届く値を一緒に返し、外側が遅い値を待たずに終わる場合。サイトや言語ごとの内容が、別のサイト・言語のリクエストに返ることがあります。
• 3 件目：use cache 関数にバイナリ（Uint8Array などのバイト列）の引数を渡し、それでユーザーを区別している場合。違う引数が同じキャッシュとして扱われ、ほかのユーザーの結果を受け取ったり、自分の結果を他人に返させたりできます。

マルチテナントの SaaS や、多言語・複数サイトを 1 つのアプリで動かしている案件では、1 と 2 は情報漏えいに直結します。社内向けのツールでも、ユーザーごとのデータを use cache に通しているなら見直す価値があります。

4 件目は条件が細かく、next start でセルフホストしていて、partialPrefetching を設定していないか false にしているアプリが対象です。動的なルートの下にさらに 2 段以上の動的パラメータがあるなど、決まった形のルートで、細工した URL を 1 回送るだけで、共有のページの骨組み（シェル）に誤った内容や 404 が残り続けます。

Edge ランタイムでクッキーを設定しているか（6）

App Router の Route Handler か Pages Router の API ルートで、Edge ランタイムを使い、NextResponse の cookies.set() でクッキーを設定している場合が対象です。内部用の x-middleware-set-cookie ヘッダーに、クッキーの中身がそのまま出てしまいます。Set-Cookie と違い、このヘッダーは同じオリジンの JavaScript から読めるため、HttpOnly を付けたセッションのクッキーでも読まれるおそれがあります。

ただし、悪用には「同じオリジンで攻撃者の JavaScript が動くこと」（XSS など）が必要で、この不具合だけで JavaScript を実行できるわけではありません。公式の再現では、Node.js ランタイムの Route Handler や、cookies().set() で設定したクッキーは影響を受けていません。HttpOnly は「XSS が起きても盗まれない」ための備えなので、その備えが効いていない状態だと考えると重さがわかります。

next start でセルフホストしているか（5）

自前のサーバーやコンテナで next start を動かしている場合です。外部から fetch した Response を加工せずにそのまま返していると、展開済みの本文に圧縮時のヘッダーが付いたまま送られます。HTTP/1.1 でつないだリバースプロキシが、1 本の接続に複数のリクエストを並べて送る（パイプライン化する）設定だと、応答が別のクライアントに割り当てられることがあります。すべてのプロキシ構成で起きるわけではありませんが、自分で構成を把握しきれていないなら、更新で塞ぐのが確実です。

画像最適化を使っているか（7）

next/image の画像最適化を使っている場合です。許可したドメインからの画像でも、細工したファイルが AVIF と誤認され、images.dangerouslyAllowSVG: false をすり抜けて SVG として処理されることがあります。公式は、これだけで XSS やリモートでのコード実行が示されたわけではなく、SVG の解析処理に負荷をかけたり、その解析処理の脆弱性に届いたりする危険が増えるものだと説明しています。また、SVG を扱えるネイティブの画像処理を使っている環境に限られます。ユーザーが投稿した画像の URL を最適化に通しているサイトは、優先度を上げてください。

バージョンごとの対応

公式のサポート方針では、16.x が Active LTS（新機能と修正の両方が入る）、15.x が Maintenance LTS（重要な修正とセキュリティ修正だけが入る）です。15.x は本来 2026 年 10 月 21 日で終わる予定でしたが、セキュリティ修正が 2027 年 1 月 31 日まで延長されています。15.x のまま使っている案件は、今回の更新で一息つけますが、あと 3 か月ほどで修正が来なくなることを前提に、16.x への移行を見積もっておくべきです。

14.x 以前は今回のアドバイザリの対象外ではなく、「調べられていない・直されない」状態です。影響がないと判断する根拠にはならない点に注意してください。

更新の手順と、すぐ更新できないとき

手順

1. 実際に入っているバージョンを確かめます。package.json の指定ではなく、ロックファイルで解決されたものを見ます。

npm ls next

2. 修正版に上げ、ロックファイルごとコミットします。pnpm や yarn を使っている場合も、上げる先のバージョンは同じです。
3. ビルドして再デプロイします。ライブラリを上げただけでは、動いているサーバーは古いままです。
4. Cache Components を使っていたアプリは、汚染されたキャッシュが残っていないかを考えます。1〜4 は「誤った結果が保存され、再検証か削除まで返り続ける」性質なので、更新後に共有のキャッシュ（リモートのキャッシュハンドラーや CDN を含む）を消しておくと安心です。

ホスティング先によっては、Next.js 以外の更新も要ります。たとえば Netlify は、Next.js の更新に加えてアダプター @netlify/plugin-nextjs を 5.16.6 にするよう案内しています。Middleware で設定した HttpOnly のクッキーの件は、アダプターの更新でしか直らないとしています。また、デプロイのプレビューやブランチのデプロイは別々にキャッシュを持つため、それぞれ消すか、不要なものは削除するよう勧めています。Vercel 以外で動かしている場合は、使っているホスティングやアダプターの告知も確かめてください。

すぐ更新できないときの回避策

公式のアドバイザリに回避策が書かれているのは、次の 2 件だけです。ほかの 5 件は「修正版に上げる」以外の手段が示されていません。

• 1 件目：同じ use cache 関数を unstable_cache() の中から呼ぶのをやめる。アドバイザリは、もともとこの入れ子は「サポート外」でエラーになる組み合わせで、避ければ完全な回避策になると書いています。
• 4 件目：next.config で partialPrefetching: true にする。

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
}

export default nextConfig

partialPrefetching は 16.3.0 で入った設定で、cacheComponents が必要です。リンク先の先読みの仕方が変わる（ルートごとに共通の骨組みを 1 つ先読みする）ため、回避策として入れるなら、画面遷移の動きを一通り確かめてください。公式ドキュメントは、次のメジャーリリースでこの 2 つの機能は常に有効になり、設定自体がなくなると予告しています。

まとめ

• 11 月 3 日のリリースで 7 件の脆弱性が直り、修正版は 16.4.5 と 15.5.29。14.x 以前には修正が出ません。
• 当たるかどうかは「Cache Components・Edge ランタイムのクッキー・next start でのセルフホスト・画像最適化」の 4 つで判定できます。Cache Components を使う 16.x のマルチテナントや多言語のアプリが最も急ぐ対象です。
• 更新したら再デプロイし、共有のキャッシュとホスティング側のアダプターも確かめましょう。15.x は 2027 年 1 月 31 日でセキュリティ修正が終わるので、16.x への移行も合わせて計画すると、次の定例リリースにも慌てずに済みます。

参考リンク

• Next.js 公式ブログ：November 2026 Security Release
• Next.js 公式ブログ：Upcoming Next.js November Security Release
• GHSA-mfr8-8qww-v76h（unstable_cache と use cache）
• GHSA-vc7v-qv4w-wrv8（入れ子の use cache）
• GHSA-rhh4-g77r-r9qj（バイナリ引数の use cache）
• GHSA-vvgp-ww4w-46vf（フォールバックシェルの汚染）
• GHSA-pc58-hwjq-p385（応答の取り違え）
• GHSA-f3mh-rxg3-f5g2（Edge のクッキー）
• GHSA-7qx7-33qx-rqx2（SVG のすり抜け）
• Next.js Support Policy
• Next.js ドキュメント：partialPrefetching
• Netlify Changelog：Security Update: Multiple vulnerabilities in Next.js (November 2026)