Next.js 2026年11月セキュリティリリースの要点 — 16.4.5 / 15.5.29 への更新と影響条件の見極め方

セキュリティ2026.11.05

2026年11月3日、Next.js のセキュリティリリースが公開されました。対応版は 16.4.5（Active LTS） と 15.5.29（Maintenance LTS） で、修正対象は7件です。結論として、Next.js 15 系・16 系を使っているなら、まずこの2バージョン以上へ上げるのが最短の対応になります。そのうえで、7件のうち自社アプリに実際に当たるのはどれかを切り分けると、緊急度とテスト範囲を判断できます。

まず実行すること

公式ブログが案内しているアップグレードは次のとおりです。

15 系：npm install next@15.5.29
16 系：npm install next@16.4.5

Next.js は Active LTS（16.4）と Maintenance LTS（15.5）の2系統で修正を配っています。16 系に上げられない事情がある場合でも、15.5.29 は用意されているため「メジャーアップグレードが終わらないので放置」という選択は避けられます。なお 16 系向けの修正には Cache Components 関連の4件が含まれ、15 系向けは3件（レスポンス取り回し、画像最適化、Edge の Cookie）です。

7件の内訳と、影響を受ける条件

今回の修正は性質が3つに分かれます。条件が噛み合わないと成立しないものが多く、一律に「全アプリが危険」ではありません。

1. Cache Components とキャッシュの混線（4件）

Cache Components は Next.js 16 で next.config.ts に cacheComponents: true を書いて有効化するオプトイン機能で、use cache ディレクティブによる関数・コンポーネント単位のキャッシュを使えるようにします。この4件はいずれも、この機能を有効にしている場合に限って問題になります。

GHSA-mfr8-8qww-v76h（CVE-2026-119790）：同じ use cache 関数を直接呼び出しつつ unstable_cache() 経由でも呼ぶと、プロセス起動直後のキャッシュ充填レースで root パラメータ（ルートレイアウトのルートパラメータ。ロケールやテナントの区別に使われる）の検査が素通りし、別の値向けのデータが返り得ます。公式ブログでは High 扱いですが、GitHub の勧告では Moderate（CVSS 4.0 で 6.3）と評価されています。影響は 16.3.0 以降です。
GHSA-vc7v-qv4w-wrv8（CVE-2026-119351）：入れ子になった use cache 関数で、内側の root パラメータ依存が記録される前に外側のエントリが保存され、テナント・サイト・ロケールの境界を越えて内容が再利用され得ます。
GHSA-rhh4-g77r-r9qj（CVE-2026-119349）：use cache 関数に渡した異なるバイナリ引数が同一のキャッシュ識別子になり、その引数でユーザーを区別している場合に他人の結果が返る、あるいは自分の結果が他人へ配られる可能性があります。
GHSA-vvgp-ww4w-46vf（CVE-2026-119350）：next start によるセルフホストで Partial Prefetching が無効または未設定のとき、未認証リクエストが共有シェルを汚染し、誤った内容や恒久的な 404 を引き起こし得ます。成立には「ビルド時に生成していない動的パラメータ値」「プリレンダされない2階層以上の深いパラメータ」「ブロッキングのフォールバックシェル」といった特定のルート形状が必要で、ビルド生成済みの値や Partial Prefetching 有効時は報告されたテストでは影響がなかったとされています。

共通するのは「キャッシュキーの取り違え」です。マルチテナント SaaS や多言語サイトのように、root パラメータで見せる情報を分けている構成ほど実害が大きくなります。

2. セルフホスト構成に依存するもの（1件）

GHSA-pc58-hwjq-p385（CVE-2026-119348） は、fetch したレスポンスをそのまま返す Route Handler で、解凍済みのボディを圧縮時のフレーミングヘッダ付きで転送してしまう問題です。HTTP/1.1 のリバースプロキシが同一バックエンド接続でリクエストをパイプライン処理している場合、レスポンスが別のクライアントへ割り当てられる可能性があります。前段のプロキシ挙動が前提なので、すべてのリバースプロキシ構成で起きるわけではありません。

3. 構成に関係なく確認したいもの（2件）

GHSA-f3mh-rxg3-f5g2（CVE-2026-119346）：App Router の Edge Route Handler と Pages Router の Edge API Route で NextResponse.cookies.set() を使うと、内部ヘッダ x-middleware-set-cookie に Cookie が複製されます。このヘッダは同一オリジンの JavaScript から読めるため、HttpOnly 指定のセッショントークンでも読み取られ得ます。勧告が挙げる影響範囲は 16.0.0〜16.4.2 と 15.0.0〜15.5.28 で、15 系・16 系を広くまたぎます。悪用には同一オリジンでスクリプトを実行できる状態が別途必要ですが、XSS があった場合の被害を一段深くする要因になります。
GHSA-7qx7-33qx-rqx2（CVE-2026-119347）：許可済みの取得元から来た画像が AVIF と誤判定され、images.dangerouslyAllowSVG: false を回避して SVG パーサに到達します。画像ソースの許可リスト自体は有効で、この指摘単体で XSS や RCE が成立するわけではありませんが、SVG デコーダの脆弱性やリソース枯渇への露出が増えます。

自社アプリが当たるかを5分で切り分ける

アップグレード前後の優先順位づけには、次の順で確認するのが実務的です。

next.config.ts に cacheComponents: true があるか。無ければ Cache Components 由来の4件は対象外になり、残る3件に絞れます。
有効なら、unstable_cache( と 'use cache' をリポジトリ全体で検索し、同じ関数が両方の経路から呼ばれていないかを見ます。
ルートレイアウトのパラメータ（ロケール／テナント）をキャッシュ対象の関数が読んでいるか。読んでいれば情報漏えいの実害が出やすい構成です。
Blob などバイナリ値を use cache の引数にしてユーザーを識別していないか。
Edge ランタイムのルートで NextResponse.cookies.set() によりセッション Cookie を発行していないか。
セルフホストなら、next start の前段プロキシ構成と、fetch 結果をそのまま返す Route Handler の有無を確認します。

勧告には回避策の記載もあります。たとえば unstable_cache() の中で use cache を呼ばない構成にすれば、GHSA-mfr8-8qww-v76h は完全に回避できるとされています（そもそもレース外ではエラーになる組み合わせです）。ただし回避策は一時しのぎで、恒久対応はパッチ適用です。

ホスティング環境で影響が変わる

同じバージョンでも、実行基盤によって成立しない項目があります。Netlify は自社プラットフォームについて、画像最適化は Netlify Image CDN が処理するため SVG バイパスの影響を受けないこと、リクエストごとに分離された実行環境のため unstable_cache 経由のキャッシュ漏えいに必要な同時実行が起きないこと、レスポンスのフレーミングを基盤側で行うためクロスクライアントの応答混線が起きないことを公表しています。一方で、入れ子 use cache・バイナリ引数・共有シェルのキャッシュ汚染は条件が合えば影響を受け、Edge の Cookie 露出はミドルウェアで設定した Cookie にも及ぶとしています。

ここから言えるのは、自社のホスティング先が公式見解を出していないかを必ず確認する、という実務です。「マネージドだから安全」と一般化せず、ベンダーの告知を根拠に判断範囲を狭めるほうが、検証コストを正しく配分できます。

今回の進め方から学べる運用上の示唆

今回のリリースは、事前告知のうえで予定日に公開される形を取りました。10月には画像最適化の RCE など緊急度の高い修正が別途出ています。つまり Next.js では、計画的なセキュリティリリースと緊急の out-of-band 修正の両方が走ります。運用側の備えとしては、依存更新の自動検知（Dependabot など）に加え、CVE/GHSA 番号で自社の利用バージョンを照合できる状態を作っておくこと、そして「パッチ適用だけで完了か、キャッシュの破棄やセッション再発行まで必要か」を事前に決めておくことが効きます。キャッシュ汚染系の指摘では、更新後に汚染済みエントリを残さないよう再デプロイやキャッシュのパージまで含めて手順化しておくと判断が速くなります。

まとめと次の一手

今日できる対応は明確です。16.4.5 または 15.5.29 へ更新し、上の切り分け手順で当たる項目を特定し、キャッシュのパージとセッション周りの確認まで含めて完了させてください。Cache Components を使うマルチテナント構成や多言語サイトでは、更新後に「別テナント・別ロケールの内容が混ざらないか」の回帰確認までを一連の作業に含めることをおすすめします。

Next.js のバージョンアップ判断や、キャッシュ設計・認証まわりの影響調査に人手が足りない場合は、Web サイト制作とフロントエンド開発を行う chot Inc. のお問い合わせからご相談ください。

出典

この記事に関連するchot Inc.の解説

Webサイトで扱う情報を守るには、日々の運用ルールに加えて、CMSやホスティングの構成から見直すことが有効な場合があります。従来型のCMSとヘッドレスCMSで対策の考え方がどう変わるかはヘッドレスCMSとは｜従来CMSとの違い・メリット・デメリットで、生成AIをWebサイトに組み込む際の注意点は生成AIをWebサイトに組み込む際のセキュリティで解説しています。

この記事をシェア

Next.js 2026年11月セキュリティリリースの要点 — 16.4.5 / 15.5.29 への更新と影響条件の見極め方

まず実行すること