Next.js脆弱性の確認方法と対応：構成で影響を見分ける

Next.jsの脆弱性は、Next.js本体のほか、内部で使っているReactや画像処理ライブラリの不具合からも生じます。今回の3件はいずれも上流の依存ライブラリに原因があり、Next.jsの開発元は10月8日にブログで予告したうえで、10月14日に修正版を出しました。予告によると、3件のうち2件は9月の定例リリースから延期されたものです。

修正された3件の深刻度と影響が出る条件

修正版は、Active LTS（長期サポート）の16.4.1と、Maintenance LTSの15.5.28です。10月14日の公式ブログの告知は、npm install next@16.4.1での更新を推奨しています。「use cache」の件については、アドバイザリに回避策がなく、「該当する関数がなくても直ちに更新するように」と書かれています。

画像処理の件は、影響を受ける範囲が10.0.0からと広い一方、修正版が出たのは15系と16系だけです。14系以前で動いているサイトは、メジャーバージョンを上げないと修正版に届きません。

JPCERT/CCとIPAでの扱い

JPCERT/CC（JPCERTコーディネーションセンター）は2026年10月21日のWeekly Reportで「Next.jsに複数の脆弱性」を取り上げ、CVE-2026-96889の概念実証コードが公開されていることを確認したと書きました。対策は修正版への更新です。ただしWeekly Reportの一項目で、単独の注意喚起としては出ていません。IPA（情報処理推進機構）の「重要なセキュリティ情報」にも、今回のNext.jsの項目はありません。

公的機関の注意喚起が出ていないことは、更新しなくてよい理由にはなりません。概念実証コードが公開されている以上、条件に当てはまるサイトは攻撃の手順が手に入る状態にあります。

Next.jsのアドバイザリには、影響を受けるバージョンと、影響が出る条件の両方が書かれています。バージョンが範囲に入っていても、条件にある機能を使っていなければ影響しない脆弱性があります。

確認する4つの項目と順番

1. バージョン。プロジェクトでnpm ls nextを実行し、インストールされている版がアドバイザリの範囲に入るかを見ます
2. ルーター。appディレクトリでページを作っていればApp Router、pagesディレクトリならPages Routerです。両方を併用しているプロジェクトもあります
3. 使っている機能。Server Actions（"use server"）、"use cache"、next/imageによる画像最適化、middleware（16系ではproxy）を使っているかを、コードを検索して確かめます
4. 配信方法。Vercelなどのホスティング、next startやstandaloneでのセルフホスト、output: 'export'による静的エクスポートのどれかを、next.config.jsと公開先の設定で確かめます

静的エクスポートでは、Next.jsの公式ドキュメントにあるとおり、Server Actions、既定のローダーでの画像最適化、proxy（旧middleware）が使えません。公開中のサイトでNext.jsのサーバーが動かないためです。

構成ごとの影響：過去の脆弱性を含む5件の比較

今回の3件に、2025年の重大な2件を加えて並べました。2025年3月のCVE-2025-29927は、内部用のヘッダーを付けるだけでmiddlewareの認可を素通りできた脆弱性です。2025年12月のReact2Shell（CVE-2025-55182）は、React Server Componentsの処理の欠陥で認証なしにコードを実行でき、実際に悪用されました。どちらも、構成によって影響が分かれた例です。

表の中で「明記」と書いた欄は、アドバイザリや公式の文書に書かれていることです。それ以外は、条件と構成を照らし合わせた判断です。自社のサイトで判断するときも、この2つを分けて記録してください。

npm auditで分かること・分からないこと

当社は2026年10月30日、Next.js 16.4.0のままの当サイトでnpm auditを実行しました。nextはCriticalとして報告され、今回の3件のアドバイザリがすべて表示されました。影響範囲は「16.0.0から16.4.0」で、修正できる更新があるとも表示されました。

npm auditはインストールされた版がアドバイザリの範囲に入るかで判定し、ルーターや配信方法は見ません。当サイトのように構成上は影響しないサイトでも、Criticalのまま残ります。逆に、npm auditの結果だけで「影響なし」とも「影響あり」とも決められないため、前の項の4項目と合わせて判断します。

ここからは、当サイトで10月30日に行った対応です。判断の根拠のうち、公式に書かれていることと、当社の推論とを分けて書きます。

当サイトの構成

当サイトはNext.jsのPages Routerで作り、next.config.jsでoutput: 'export'を指定して静的なHTMLを書き出しています。書き出したファイルはFirebase Hostingから配信しており、本番でNext.jsのサーバーは動いていません。App Router、Server Actions、use cache、middleware、next/imageによる画像最適化は使っていません。

next buildが更新の通知で止まった

当社はClaude Codeなどのコーディングエージェントと一緒にサイトを更新しています。10月30日、エージェントが実行したnext buildが最初の更新通知で止まり、Next.js 16.4.0が既知の脆弱性の影響を受けると表示されました。同じコマンドをもう一度実行すると、警告を出したうえでビルドが最後まで通りました。

ビルドが止まったことで、この日のうちに3件のアドバイザリを読む作業に入れました。人が端末で実行していれば、10秒の通知が出るだけでビルドは止まりません。

3件をどう切り分けたか

• Server ActionsのDoSは、アドバイザリに「Pages RouterまたはServer Actionsを使わないアプリは影響を受けない」と書かれています。当サイトは両方に当てはまるため、影響なしと確定できました
• use cacheのリモートコード実行は、条件がApp RouterとCache Componentsです。当サイトはApp Routerを使っていないため、条件に当てはまりません
• 画像最適化のリモートコード実行は、アドバイザリに静的エクスポートについての記載がありません。静的エクスポートでは既定のローダーでの画像最適化が使えず、本番でNext.jsのサーバーも動かないことから、当社は影響なしと判断しました。これはNext.jsの仕様からの推論です。依存関係を確かめると、アドバイザリが回避策に挙げるsharp 0.35.5がすでに入っていました

影響がなくても16.4.3へ更新した理由

切り分けの結果は影響なしでしたが、2026年10月30日にNext.jsを16.4.0から16.4.3へ更新しました。理由は3つあります。

• 画像最適化の件は推論で判断しており、公式の記載で確定していない
• 脆弱な版のままにすると、ビルドのたびに通知が出て、npm auditにもCriticalが残る。次に対応が要る警告が出ても見分けにくくなる
• 今の版から離れるほど、次の修正版へ上げるときの差分が大きくなる。同じ16.4系のうちに追いつくほうが確認が少なく済む

更新で変わったのはpackage.jsonとpackage-lock.jsonだけでした。更新後はnpm auditから今回の3件が消え、next buildも通知で止まらずに最後まで通りました。

Next.jsには、修正版の予定を事前に知らせる仕組みと、手元で脆弱な版を使っていると知らせる仕組みの両方があります。どちらも2026年に始まったものです。

月1回の定例セキュリティリリースと事前の予告

Next.jsの開発元は2026年7月13日、「Next.js Security Release and Our Next Patch Release」で、セキュリティリリースの制度を始めると公表しました。おおむね月1回、ブログで予定日と最大の深刻度を予告してから修正版を出す制度です。背景には、LLM（大規模言語モデル）を使った脆弱性の発見が増えたことがあると書かれています。緊急のものや悪用が確認されたものは、これまでどおり臨時で修正されます。

9月30日の定例では、Pages RouterのSSG・ISRでセルフホストしている場合のキャッシュ汚染（CVE-2026-94543）も修正されました。今回Pages Routerが対象外だったことは、次のリリースでも対象外になることを意味しません。

next buildとnext devの更新通知（16.4.0から）

Next.js 16.4.0で、脆弱な版を使っているときに更新を促す機能（experimental.agentUpgrade）が加わり、既定で有効になっています。人が端末でnext buildやnext devを実行すると、「Upgrade now」「Skip」「Skip until next version」を選べる通知が10秒表示され、ビルドは止まりません。コーディングエージェントが実行したときは、最初の通知でコマンドが止まり、再実行すると警告付きで続行します。next devの画面に出る開発者ツールにも、脆弱性の情報が表示されます。

この機能は設定でfalseにすると止められます。当社は止めずに使っています。今回のように、ビルドが止まったことが更新作業を始めるきっかけになるためです。

next upgrade --agentで更新先の版を決める

実験的な機能として、next upgrade --agentがあります。方針に沿って更新先の版を決め、移行ガイドを用意してコーディングエージェントに作業を渡すコマンドです。securityの方針を選ぶと、今の版が脆弱な安定版であれば、対象となる最も近いメジャーバージョンの中で最新の安全な版を選びます。Pages Routerにも対応しています。

GitHubのアドバイザリとDependabot alertsで知る

アドバイザリの原文は、GitHubのvercel/next.jsのSecurityタブに、影響を受けるバージョンと修正版、条件付きで公開されます。自社のリポジトリをGitHubで管理しているなら、Dependabot alertsを有効にしてください。GitHub Advisory Databaseに新しい脆弱性が加わると、依存パッケージが該当するリポジトリに通知が届きます。

アドバイザリを読んでから公開するまでを、4つの段階に分けて進めます。影響なしと判断した場合も、同じ流れで更新します。

更新を誰がいつ行うかを決めておく

今回の3件は、10月8日の予告から10月14日の公開まで6日ありました。予告が出た時点で、誰が影響を切り分け、どの日に更新するかを決めておくと、公開日には更新作業から始められます。月1回の定例を前提に、更新の担当者と、ビルドと動作確認の手順を決めてください。

制作会社にサイトを作ってもらった場合は、公開後の依存パッケージの更新が保守の契約に入っているかを確かめてください。入っていなければ、セキュリティリリースが出ても誰も更新しないまま時間が過ぎます。PHPで作られたサイトで同じ状況になったときの考え方は、PHPの脆弱性にどう対応するかを書いたコラムにまとめています。

Next.jsサイトの運用・更新ならGinTrick

GinTrickは、TypeScript・React・Next.jsによるWebサイト・Webアプリケーションを開発し、公開後の保守と機能追加まで支援しています。サイバーエージェント・ドワンゴ出身のエンジニアが設計段階から入り、成果物を検品します。開発の流れと事例はシステム開発のページでご覧いただけます。

今のNext.jsサイトが脆弱性の影響を受けるかの切り分けや、更新を続けるための手順づくりは、要件定義から運用保守まで支援するGinTrickの無料相談をご活用ください。