Next.js 16.4.5・15.5.29の脆弱性7件｜use cacheと自前サーバー運用の該当条件を設定で確かめる

11月3日（米国時間）に、Next.jsの16.4.5と15.5.29が公開されました。10月27日の事前告知どおり、Mediumの脆弱性7件を直すリリースです。Criticalが2件あった10月14日の回と比べると深刻度は下がりますが、7件のうち4件は use cache（Cache Components）、2件はVercel以外のサーバーで動かす構成が条件で、どちらも16系のアプリでは珍しくない使い方です。

この記事では、7件を「使っている機能」と「動かし方」で分け、自社のアプリが該当するかをコードと設定から確かめる手順をまとめます。前回の16.4.1・15.5.28の3件を当てたあと、続けて上げるべきかを判断したい保守担当の方に向けた内容です。

先に、要点をまとめます（2026年11月8日確認）。

• 修正版は 16系が16.4.5、15系が15.5.29 です。16系は7件すべて、15系は3件が対象です。16.3系の修正版は出ていないため、16.3系で動いている場合も16.4.5へ上げます
• 4件は use cache を使う16系のアプリが条件です。残りの3件は、Vercel以外の自前サーバーで動かす構成（2件）と、EdgeランタイムでCookieを設定するルート（1件）が条件で、15系も対象に入ります
• 11月8日の時点で、7件はGitHub Advisory Databaseに載っておらず、next@16.4.4 で npm audit を実行しても何も表示されません。公表元のアドバイザリで直接確認します

11月3日に修正された7件は何？

7件ともアドバイザリ上の深刻度はMedium（Moderate）で、認証なしのリモートコード実行は含まれていません。キャッシュの取り違えによる情報の漏えい・汚染が4件、応答が別の利用者に届く問題が1件、Cookieの値の露出が1件、画像最適化の制限の回避が1件です。

Next.js公式の告知と各アドバイザリを、影響する版と修正版で並べると次のとおりです。CVSSはアドバイザリに記載されたv4の値です。

深刻度の表記には1か所ずれがあります。アドバイザリとリリースノートでは7件ともModerate（Medium）ですが、公式ブログの本文ではGHSA-mfr8-8qww-v76hだけが「High Severity」と書かれています（11月8日確認）。root paramでテナント（顧客企業）ごとにデータを分けているアプリでは他社のデータが返り得る、という説明が付いているためと読めます。社内で優先度を付けるときは、この1件を高い方に合わせて扱うと判断がぶれません。

16.4.4から16.4.5までのコミットは、この7件の修正と版番号の更新だけでした（GitHubの比較画面で確認）。機能の変更は入っていないため、16.4.4から上げる場合の確認は修正が入った箇所に絞れます。

自社のアプリは、どれに当てはまる？

「use cache を使っているか」「Vercel以外のサーバーで動かしているか」「EdgeランタイムでCookieを設定しているか」の3つで、確認すべき番号が絞れます。どれにも当てはまらなければ、急ぎの対応は要りません。

use cache を使っている場合（4件・16系のみ）

4件はいずれも、キャッシュした結果が本来とは別の利用者・別の値に返る問題です。攻撃者が任意の内容を差し込めるものではなく、アプリ自身が作った内容が取り違えられます。それでも、顧客ごと・テナントごと・言語ごとにデータを分けてキャッシュしているアプリでは、他の顧客のデータが見える形になり得ます。

• GHSA-rhh4-g77r-r9qj：use cache の関数の引数に Uint8Array や Blob を渡している場合。利用者を区別する値をバイナリで渡していると、別の利用者に結果が返ります
• GHSA-vvgp-ww4w-46vf：16.4系で cacheComponents: true にし、partialPrefetching を設定していない（または false）状態で、next start で配信している場合。ルートの形にも条件があり、generateStaticParams で事前生成する動的ルートにビルド時に生成していない値でアクセスされ、その下に事前生成しない動的な値が2段以上ある構成が対象です。公式の回避策は next.config で partialPrefetching: true にすることです
• GHSA-vc7v-qv4w-wrv8：外側の use cache の中で別の use cache を呼び、内側が next/root-params で値を読んでいる場合。9月30日に同じ型の問題が修正されましたが、その修正では防げない経路が残っていました
• GHSA-mfr8-8qww-v76h：同じ use cache の関数を、描画中に直接呼ぶ箇所と unstable_cache() の中から呼ぶ箇所の両方がある場合。プロセスの起動直後に処理が重なったときだけ起きます。公式は、unstable_cache() の中から呼ばない形に直せば回避できるとしています

Cache Componentsを有効にしていないアプリや、use cache をまだ使っていないアプリは、この4件の条件に入りません。16.4で推奨になった設定をこれから有効にする予定なら、16.4.5に上げてから進めます。有効にするときの手順はNext.js 16.4の変更点、キャッシュの分け方の考え方はuse cacheの設計にまとめています。

Vercel以外のサーバーで動かしている場合（2件・15系も対象）

公式は、次の2件の条件に「セルフホスト」を挙げています。AWSのECSやGoogle CloudのCloud Runのように、自社で管理するサーバーで next start を動かしている構成です。Vercelで動かしている場合の扱いは告知に書かれていないため、版を上げる前提で考えます。

• GHSA-pc58-hwjq-p385：Route Handlerや fetch のキャッシュで、外部から取得した応答を加工せずにそのまま返している場合。そのアプリが、HTTP/1.1でリクエストを続けて送る（パイプライン化する）リバースプロキシの後ろにあると、応答が別の利用者に届くことがあります。公式は、すべてのリバースプロキシの構成に当てはまるわけではないとしています。プロキシの設定が分からない場合は、該当するコードがあるかを先に確認します
• GHSA-7qx7-33qx-rqx2：images.remotePatterns で許可した外部の画像を最適化している場合。許可した取得元に攻撃者が画像を置けると、AVIFと誤判定させてSVGの処理まで進めることができます。公式は、この件だけではクロスサイトスクリプティングやリモートコード実行は示されておらず、SVGの解析処理の負荷や不具合にさらされる範囲が広がる問題だと説明しています

GHSA-7qx7-33qx-rqx2で効いてくるのは、remotePatterns で許可している範囲の広さです。社外の人がファイルを置けるストレージ（利用者のアップロード先や、バケット名まで指定していないクラウドストレージのURLなど）を許可している場合は、許可の範囲を自社の保存先だけに絞れるかも見直します。ECSで動かすときの構成全体はAWS ECS×Next.jsの構成で整理しています。

EdgeランタイムでCookieを設定している場合（1件・15系も対象）

GHSA-f3mh-rxg3-f5g2 は、export const runtime = 'edge' を指定したApp RouterのRoute Handler、またはPages RouterのEdge API Routeで、NextResponse の cookies.set() を使ってCookieを設定している場合が対象です。応答に内部用の x-middleware-set-cookie ヘッダーが付き、そこにCookieの値が入ります。Set-Cookie と違い、このヘッダーは同じオリジンのJavaScriptから読めるため、HttpOnlyにしたセッションのCookieでも値が見えます。

悪用するには、同じオリジンで攻撃者のJavaScriptが動いている必要があります。この件だけでJavaScriptを実行させられるわけではありません。公式の再現では、Node.jsランタイムのRoute Handlerと、cookies().set() で設定するルートは影響を受けませんでした。ログインやセッション発行をEdgeランタイムのルートで行っている場合は、優先して上げます。

確認には、どのコマンドを使う？

プロジェクトのルートで次の検索を実行すると、当たりを付けられます。ヒットした箇所を、上の条件と1つずつ照らし合わせます。

# 動いている版（package.json ではなく、実際に入っている版）
npm ls next

# use cache を使う4件
grep -n "cacheComponents\|partialPrefetching" next.config.*
grep -rln "'use cache'\|\"use cache\"" app src
grep -rn "unstable_cache" app src
grep -rn "next/root-params" app src

# Edge ランタイムで Cookie を設定する1件
grep -rln "runtime = ['\"]edge" app pages src
grep -rn "cookies.set(" app pages src

# 自前運用の2件
grep -rnE "return (await )?fetch\(" app src
grep -n "remotePatterns\|domains\|dangerouslyAllowSVG" next.config.*

app や src のどちらかがないプロジェクトでは、存在するディレクトリだけを指定します。検索の結果は手がかりで、該当の最終判断はアドバイザリの条件で行います。たとえば fetch の結果を変数に入れてから返しているコードは、上の検索ではヒットしません。

Edgeランタイムのルートがある場合は、本番の応答に内部用のヘッダーが付いているかも確かめられます。Cookieを設定する操作（ログインなど）のリクエストを送り、応答ヘッダーを見ます。

curl -s -D - -o /dev/null -X POST https://example.com/api/login | grep -i "^x-middleware-set-cookie"

URLとメソッドは、自社でCookieを設定しているルートに置き換えてください。16.4.5または15.5.29に上げたあとは、このヘッダーが応答から消えます。

16.3系や15系で動いている場合は、どの版に上げる？

16系は16.4.5、15系は15.5.29です。16.3系の修正版は今回も出ていないため、16.3系で動いているアプリは16.4.5へ上げます。14系以前は公式のサポート対象外で、修正版はありません。

16.3系から上げる場合は、16.4.0の変更を含む移行になります。どこで止まりやすいかは16.4.1・15.5.28の解説の「16.3系で運用している場合」の節で扱っています。15系のサポートは2027年1月31日まで延長されているため、それまでに出る修正は15系にも出る前提で考えられます（Next.js Support Policy）。16系への移行の判断はNext.js 15のサポート期限の記事で整理しています。

npm auditやDependabotで検知できる？

11月8日の時点では検知できません。7件はNext.jsのリポジトリで公表されていますが、npm audit とDependabotが参照するGitHub Advisory Databaseにはまだ載っていないためです。

11月8日（日本時間）に、next@16.4.4 だけを依存関係に持つプロジェクトで npm audit を実行すると、脆弱性は0件と表示されました。16.4.4は7件すべての影響範囲に入っています。GitHubのAPIでも、7件の番号はGitHub Advisory Databaseからは見つからず、Next.jsのリポジトリのアドバイザリとしてだけ取得できました。

これまでの公表分は、データベースへの登録まで次の日数がかかっています（Next.jsの脆弱性一覧の調べ）。

npm audit が0件でも、公表から1週間ほどは直近の分が含まれていない可能性があります。この間は、Next.js公式ブログとvercel/next.js のSecurity Advisoriesを直接確認します。アドバイザリと手元の版を突き合わせるスクリプトの例は、脆弱性一覧の記事に載せています。

更新後には、どこを確認する？

修正が入った箇所、つまり use cache を使うページ、Edgeランタイムでの Cookie の設定、外部画像の表示、外部の応答をそのまま返すルートを確認します。

npm install next@16.4.5   # 16系
npm install next@15.5.29  # 15系
npm ls next               # 入った版を確認する

eslint-config-next を使っている場合は、next と同じ版にそろえます。

パッチの検知から本番への反映までを誰が担うか、内製で回すか保守を委託するかの判断は、Next.jsのCVE対応は誰がやるのかで整理しています。

まとめ

• 11月3日の修正版は 16系が16.4.5、15系が15.5.29 。16系は7件すべて、15系は3件が対象で、16.3系の修正版は出ていません
• 4件は use cache を使う16系のアプリ、2件はVercel以外の自前サーバーで動かす構成、1件はEdgeランタイムでCookieを設定するルートが条件です
• GHSA-mfr8-8qww-v76hは、アドバイザリではMedium、公式ブログではHighと表記が分かれています。テナントごとにデータを分けているアプリは優先して上げます
• 11月8日時点で、7件は npm audit に表示されません。公表元のアドバイザリで確認します

上の検索で、use cache やEdgeランタイムのルートがどこにあるか分からなかった場合は、その箇所の洗い出しからご相談いただけます。私たちは、Next.jsで動いているシステムの保守として、該当の判定、検証、本番への反映までをお手伝いしています。

※本記事は、2026年11月8日時点の Next.js公式ブログ、事前告知、vercel/next.js のSecurity Advisoriesと各リリースノート、Next.js Support Policy、GitHub Advisory Databaseの登録状況、npmレジストリの情報に基づいています。アドバイザリの内容は更新されることがあるため、対応の判断にあたっては各アドバイザリの最新の内容を確認してください。