Next.js 10月の脆弱性9件 自前運用で当たる条件と移行先の版

10月7日を境に、npm audit が next に「high」を出すようになった。社外のCMSから画像を読み込み、Pages Router の ISR で記事ページを配信し、編集者は Draft Mode で下書きをプレビューしている。そんな Next.js のサイトを自社のサーバーやコンテナで動かしている場合、10月に公開されたアドバイザリのうち複数が当たる可能性があります。

10月のアドバイザリは2回に分けて出ました。10月7日（UTC）に GitHub Advisory Database に登録された6件は、9月30日に npm に公開された 16.3.8 と 15.5.27 で直っています。ところが10月14日、vercel/next.js がさらに3件を公開しました。CRITICAL のリモートコード実行（RCE）が2件、HIGH のサービス妨害（DoS）が1件で、16.3.8・16.4.0・15.5.27 もこの3件の対象です。修正版は 16.4.1 と 15.5.28 で、16.3系には修正版がありません。

16.3.8 への更新を勧めていた9月のNext.jsの脆弱性の記事も、10月16日に更新先を訂正しました。本記事は、9件が自社のサイトに当たるかを条件ごとに判断し、どの版に上げ、更新後に何を確かめるかを整理したものです。

移行先は16.4.1以上、15系は15.5.28

10月14日の3件は、16.x 系では 16.4.0 までをすべて対象にしています。npm に 16.3.9 はなく、16.3系のまま直す方法はありません。16.x を使うサイトは 16.4.1 以降（10月16日時点の npm の latest は 16.4.2）に、15.x を使うサイトは backport のタグが付いた 15.5.28 に上げます。リリースノートが挙げる修正は、16.4.1 がこの3件、15.5.28 が 16系だけを対象とする1件を除いた2件です。

10月7日の6件の修正は、16.4.0 にも入っています。6件の対象範囲は「16.3.8未満」で、リポジトリの履歴でも、16.3.8 に入った修正と同じ題名のコミット（#99477・#99478・#99479・#99480・#99482）が 16.4.0 のタグに含まれていました。16.4.1 以降に上げれば、9件すべての修正が入ります。

14.x 以前も無関係ではありません。10月7日の6件の対象範囲はいずれも 15.0.0 からですが、10月14日の画像最適化の件は 10.0.0 以上、Server Actions の件は 13.0.0 以上を対象にしています。13.x・14.x には新しい修正版が出ておらず（npm の next-14 タグは2025年12月公開の 14.2.35 のまま）、直すには 15.5.28 か 16.4系へのメジャー更新が必要です。

9件の当たる条件

アドバイザリの本文に書かれた条件と対象範囲です。まず10月14日の3件です。

次に10月7日の6件です。

表と図の「対象の版」は、アドバイザリの範囲（例: 16.3.8未満）を公開済みの最終版で表したものです。画像最適化の件の 16系の範囲は、アドバイザリでは「16.0.0より後、16.4.0以下」と書かれています。

条件ごとに自社のサイトを確かめる

ここからは、アドバイザリの条件をリポジトリのどこで確かめるかについての編集部の整理です。ただし10月14日の Critical の2件は、確認が終わるのを待たずに更新を進めてください。

use cache：Cache Componentsを使っているか

GHSA-673q は、Cache Components を有効にした App Router で、'use cache' の関数が複数の型付き配列（Uint8Array など）を返すと、認証なしで RCE につながるとしています。確認するのは、next.config の cacheComponents: true と、'use cache' を書いた関数の戻り値です。ただしアドバイザリは、回避策はなく、似た関数がなくても直ちに更新するよう求めています。Cache Components を使っているなら、確認より更新を先にします。

画像最適化：glibcのLinuxで動かしているか、sharpの版

GHSA-2464 は、画像最適化が使う上流のライブラリのメモリの問題で、glibc 系の Linux で Next.js を動かすと RCE につながる可能性があるとしています。題名は「SVG ファイルを使う場合」です。同じ CVE（CVE-2026-96889）は、9月30日に sharp 側でも「librsvg の脆弱性」として公開されており、修正版は sharp 0.35.5 です。musl 系（Alpine など）についてアドバイザリは何も述べていないため、本記事では判断しません。

Next.js のドキュメントでは、SVG は既定では最適化せず、images.dangerouslyAllowSVG で許可する仕組みです。ただしアドバイザリはこの設定による除外を書いていないため、編集部は設定にかかわらず更新を勧めます。

回避策は、Next.js が使う sharp を 0.35.5 以上にすることです。16.4.1 は sharp の範囲を ^0.35.5 に上げています。15.5.28 の範囲は ^0.34.3 || ^0.35.5 で、0.34系も受け入れたままです。そのため 15.x では、古いロックファイルの sharp が残ることがあります（後述の検証を参照）。自前のコードで sharp を直接使っている場合も、同じく 0.35.5 以上にします。

sharp 側のアドバイザリは、すぐに上げられない場合の回避策として sharp.block({ operation: ["VipsForeignLoadSvg"] }) で SVG の読み込みを止める方法を挙げています。あわせて、RCE を避けるには PIE（位置独立実行形式）でビルドされた node を使うこと、公式配布の Node.js のバイナリは PIE ではないことにも触れています。

Server Actionsを使っているか

GHSA-p3m5 は、Server Actions を1つ以上持つ App Router に細工した要求を送ると、CPU を使い切って、同じプロセスの後続の処理が止まるというものです。回避策は更新だけで、Pages Router だけのアプリと、Server Actions を使わないアプリは対象外です。'use server' を検索すれば、Server Actions の有無を確かめられます。

画像最適化：remotePatternsに何を許可しているか

High の GHSA-cjq9 は、next/image の最適化で、許可したリモートのURLから内部のネットワーク（プライベートIPなど）へ要求させられる問題です。回避策として、images.remotePatterns に許可したホストのうち、DNSの記録を信頼できないものがないかを見直すよう求めています。そして「remotePatterns を設定していなければ対象外」と明記しています。

確認するのは next.config.js（または .mjs・.ts）の images の設定です。CMSの画像配信のドメインや、ストレージのバケットを許可しているなら対象です。非推奨の images.domains だけを使っている場合はアドバイザリに記載がなく、編集部では判断できません。更新を優先してください。

Pages RouterのSSG・ISRを自社で運用しているか

GHSA-4jqv は、Pages Router で getStaticProps を使うページ（SSG）や、revalidate を返すページ（ISR）を持ち、Vercel 以外で動かしているサイトが対象です。アドバイザリによれば、あるページのキャッシュが別のルートの内容に置き換わり、再生成されるまで、すべての閲覧者に誤った内容が表示されます。pages/ で getStaticProps を検索すれば該当ページを洗い出せます。next start やスタンドアロン出力を自社のサーバーやコンテナで動かす構成が該当します。

ルート直下にcatch-allのページがあるか

GHSA-mcj8 は、pages/[...slug].js のようにルート直下に catch-all のページを置き、ほかに SSG・ISR のルートがあるサイトが対象です。このアドバイザリは Pages Router か App Router か、自前の運用かを限定していないため、pages/ と app/ の直下を両方確かめます。省略可能な [[...slug]] がこの条件に入るかは記載がありませんが、編集部は確認の対象に含めることを勧めます。

Draft ModeとCache Componentsを併用しているか

GHSA-3w37 は 16.3.0 以上が対象です。next.config で cacheComponents: true（または experimental.useCache）を有効にし、'use cache' の関数が下書きによって変わる内容を返すサイトで、編集者のプレビューと通常の閲覧が重なると、次のことが起きるとしています。

• 通常の閲覧者が、認証なしで未公開の内容を受け取る
• その要求でページが生成されると、未公開の内容が保存され、再生成まで全員に配信される
• キャッシュした関数はルートをまたいで共有されるため、汚染されるページはプレビュー中のページとは限らない

CMSのプレビューを使うサイトでは、公開前の情報が外に出る問題として優先して確かめます。

webpackでビルドしたOG画像ルート、開発機

GHSA-f87g は、next build --webpack でビルドした App Router が対象です。ドキュメントによれば Next.js 16 の既定は Turbopack で、webpack は --webpack を付けたときに使われます。build のスクリプトに --webpack があり、generateStaticParams で生成するページを絞って dynamicParams = false にしたルートに opengraph-image や twitter-image がある場合、除外したはずのURLの画像を要求できます。

GHSA-39w2 は本番には関係せず、next dev を動かす開発者のPCが対象です。開発中に悪意のあるサイトを開くと、プロジェクトの場所、エラーに含まれるソースの断片、ルートの一覧、開発時のログが読まれる可能性があります。委託先の開発環境も含めて更新を依頼します。

どの版に上げるか

16.x は 16.4.1 以降です。16.3系のパッチ版はないため、16.3.8 のサイトもマイナー版をまたいで 16.4系に上げます。10月16日時点の latest は 16.4.2 で、リリースノートによれば 16.4.1 からの変更は Turbopack の修正やドキュメントの更新です。編集部は、16.4.2 に上げ、ステージングで動作を確かめてから本番に出す進め方を提案します。

15.x は、backport のタグが付いた 15.5.28 です。15.3系など 15.5 より前の系列も対象範囲に入るため、15.5.28 まで上げます。13.x・14.x は上で書いたとおり修正版がないため、15.5.28 か 16.4系へのメジャー更新を計画します。

自前の運用で、ISR のキャッシュを Redis などに保存するカスタムのキャッシュハンドラー（cacheHandler）を使っている場合は、更新前に確認が要ります。16.3.8・15.5.27 から入った GHSA-4jqv・mcj8 の修正コミット「Scope response cache keys to their source route」は、キャッシュのキーに元のルートのSHA-256のハッシュを含める変更で、ドキュメントにも「キーはリクエストのパス名ではない」「キーをパス名として解釈していたハンドラーは、この名前空間に対応する必要がある」と追記されました。16.3.7 以前から 16.4系に上げる場合も、この変更をまたぎます。キーからURLを取り出して削除や再検証をする独自の処理があれば、動作を確かめてから本番に出します。

更新後に確かめること

npm auditの0件を当てにしない

編集部の検証環境で、next と react・react-dom（19.2.0）だけを依存に持つ構成を版ごとに作り、npm audit --json を実行しました。10月10日（Linux、Node.js v22.22.0、npm 10.9.4）と10月16日（macOS、Node.js v22.19.0、npm 10.9.3）の結果は次のとおりで、両日で実行した版の結果は同じでした。

next 16.3.7  : high 1件。next の項目に6件（GHSA-cjq9 / 4jqv / mcj8 / 3w37 / f87g / 39w2）
next 16.3.8  : 0件
next 16.4.0  : 0件
next 16.4.1  : 0件（10月16日のみ）
next 16.4.2  : 0件（10月16日のみ）
next 15.5.26 : GHSA-4jqv / mcj8 の2件（ほかに同梱の postcss の指摘）
next 15.5.27 : Next.js 本体の指摘なし（同梱の postcss の指摘は残る）
next 15.5.28 : Next.js 本体の指摘なし（同上、10月16日のみ）

10月16日の時点で、10月14日の3件は GitHub Advisory Database に収録されておらず、npm audit には表示されません。16.3.8・16.4.0・15.5.27 で指摘が0件でも、3件の対象から外れたわけではありません。 15.5.27・15.5.28 で残る postcss の指摘は 0959 の記事でも確認したもので、npm audit はメジャー更新の 16.4.2 を示します。

確かめるのは、実際に動いている版です。デプロイした成果物の中で npm ls next sharp を実行し、next が 16.4.1 以上（15.x は 15.5.28 以上）、sharp が 0.35.5 以上であることを見ます。

sharpが0.35.5に上がったか

古いロックファイルを再現するため、sharp の版を固定してから固定を外し、next だけを上げる検証をしました（10月16日、npm install --package-lock-only）。

15.5.28 は sharp 0.34系を受け入れるため、ロックファイルに 0.34系が残っていると上がりません。15.x のサイトは、更新後に npm ls sharp で版を確かめ、0.35.5 未満なら npm install sharp@^0.35.5 などで上げます。sharp 0.35系への更新で、自前のコードの画像処理が変わらないかもあわせて確かめます。

ISRのキャッシュの保存先が変わったか

Pages Router の ISR のページ（/ と /posts/[slug]）だけを持つ最小のアプリを 16.3.7 と 16.3.8 でビルドし、next start で開きました（10月10日、Linux）。16.3.7 ではキャッシュが従来どおり .next/server/pages/ に書かれ、16.3.8 では .next/server/route-cache/PAGES/<ハッシュ>/$/posts/hello.html のように、ルートごとの場所に書かれました。/posts/hello と /posts/world のハッシュは、どちらも文字列 /posts/[slug] のSHA-256と一致しました。10月16日に同じアプリを 16.4.1 で試したところ（macOS）、16.3.8 と同じ場所・同じハッシュで書かれました。

自前の運用では、更新後のサーバーで route-cache のディレクトリができていれば、修正が動いている1つの目安になります。カスタムのキャッシュハンドラーを使う場合は、Redis などに書かれたキーに同じ形の名前空間が入っているかを見ます。

Draft Modeのプレビュー

Cache Components を使っているサイトでは、更新後に、編集者のブラウザーでプレビューを開いたまま、別のブラウザーから同じページを開き、下書きの内容が出ないことを確かめます。これは編集部の提案で、検証環境では試していません。サイトを誰がいつ更新するかの決め方は、React2Shellの放置サイトと保守契約の見直しで整理しています。

確認した範囲

2026年10月10日に、github/advisory-database（commit 4f4dc0a）の6件のアドバイザリのJSON、vercel/next.js のタグ v16.3.7・v16.3.8・v16.4.0・v15.5.26・v15.5.27 と修正コミット、16.3.8 のドキュメントのソース、npm registry の公開日時を直接取得して確認しました。10月16日には、vercel/next.js の3件のアドバイザリと v16.4.1・v15.5.28・v16.4.2 のリリースノート、sharp のアドバイザリ GHSA-wq5f-xc86-pv6w、v16.4.1 の画像のドキュメントのソースを GitHub の API で読み、npm の公開日時と sharp の依存範囲を npm view で確かめました（資料調査）。あわせて、最小構成での npm audit（10月10日・16日）、Pages Router の ISR の最小アプリを 16.3.7・16.3.8（Linux）と 16.4.1（macOS）でビルドして起動したキャッシュの保存先の比較、古いロックファイルから next を上げたときの sharp の版の確認を行いました（実機検証）。脆弱性の再現、use cache・Server Actions・SVG の画像最適化・Draft Mode・remotePatterns・catch-all・webpack ビルドでの動作、カスタムのキャッシュハンドラー、15.5.28 でのビルド、16.3系から16.4系への更新に伴う互換性、14.x 以前でのアプリの動作は確認していません。nextjs.org と NVD は開けず未確認です。

Next.js で作ったサイトの更新計画や、自前の運用環境でのキャッシュの見直しは、開発・AI・自動化のご相談からお問い合わせください。

参考資料

• GHSA-673q-mjm6-r5xr: Unauthenticated Remote Code Execution in use cache functions returning typed arrays（vercel/next.js）
• GHSA-2464-fhr4-w9xw: Unauthenticated Remote Code Execution in Image Optimization API when SVG files are used（vercel/next.js）
• GHSA-p3m5-59mp-jv5r: Denial of Service in App Router using Server Actions（vercel/next.js）
• GHSA-wq5f-xc86-pv6w: Vulnerability in librsvg dependency CVE-2026-96889（lovell/sharp）
• Next.js v16.4.1 のリリースノート（vercel/next.js）
• Next.js v15.5.28 のリリースノート（vercel/next.js）
• GHSA-cjq9-62q9-8jv4: Next.js has Server-Side Request Forgery in Image Optimization（github/advisory-database）
• GHSA-4jqv-mc3x-m676: cache poisoning of SSG and ISR pages in self-hosted applications（github/advisory-database）
• GHSA-mcj8-r9mp-w47p: cache poisoning in SSG/ISR rendering（github/advisory-database）
• GHSA-3w37-wq28-93x7: Pending use cache fill can leak Draft Mode content（github/advisory-database）
• GHSA-f87g-xv8r-7p7x: metadata image routes via dynamicParams bypass（github/advisory-database）
• GHSA-39w2-rjm5-chcv: development server’s Model Context Protocol endpoint（github/advisory-database）
• vercel/next.js — commit 719e4c6（Scope response cache keys to their source route、16.3.x）
• vercel/next.js — commit e002ad6（Pin DNS resolution when fetching external images）
• vercel/next.js — commit bd9214f（Fix draft mode leaks through cross-request ‘use cache’ deduplication）
• vercel/next.js — incrementalCacheHandlerPath.mdx（v16.3.8）
• vercel/next.js — image.mdx（v16.4.1、dangerouslyAllowSVG）
• next — npm registry