2026年7月20日、VercelはNext.jsの重要な脆弱性を修正するセキュリティリリースを公開しました。今回の対応は1件や2件の小さな修正ではなく、高リスクから中リスクまで合計9件のCVEをまとめて塞ぐ、近年でも規模の大きいセキュリティアップデートです。App Router、Server Actions、画像最適化APIといった、多くの本番プロジェクトが日常的に使っている機能が対象に含まれている点も見逃せません。
本記事では、今回のセキュリティリリースで何が起きたのかを一次情報ベースで整理したうえで、各脆弱性がどのような技術的リスクを持つのか、そして開発者・運用担当者が「今日中に」やっておくべき対応手順とチェックリストを、実務目線でまとめます。
何が起きたのか：事実整理
まず今回のセキュリティリリースの骨子を確認しておきます。公表元はNext.jsの開発元であるVercelで、2026年7月20日付でセキュリティリリースが発表されました。対象となる修正済みバージョンは以下の通りです。
- Active LTS系列：v16.2.11
- Maintenance LTS系列：v15.5.21
- v16.3系カナリア版：v16.3.0-canary.92
- v16.3系プレビュー版：v16.3.0-preview.7
- 安定版の v16.3.0 も近日中にリリース予定とされています
つまり、LTSを含むほぼ全てのサポート対象バージョン系列に修正が入っており、「カナリア版だけの限定的な話」ではない点がまず押さえておくべきポイントです。
修正された9件のCVEの内訳
今回のリリースでは、深刻度別に高リスク4件・中リスク5件、合計9件の脆弱性が修正されています。
高リスク脆弱性
- CVE-2026-64641：App Routerに関連するサービス拒否（DoS）脆弱性
- CVE-2026-64642：Turbopackかつ単一ロケール構成を使用している場合の、ミドルウェア・プロキシのバイパス
- CVE-2026-64645：書き換え（rewrites）処理に起因するサーバーサイドリクエストフォージェリ（SSRF）
- CVE-2026-64649：同じく書き換え処理に起因するSSRF
中リスク脆弱性
- CVE-2026-64644：SVG画像の最適化API利用時、またはEdgeランタイム環境でのメモリ消費に関する問題
- CVE-2026-64646：認証されていない内部サーバー機能エンドポイントの開示
- CVE-2026-64643：リクエストボディに関するキャッシュ混同（キャッシュコンフュージョン）
- CVE-2026-64647 / CVE-2026-64648：公表情報の中で詳細な技術的説明が限定的にとどまっており、本稿執筆時点で一般公開されている情報は多くありません
公表されている想定リスクとしては、アプリケーションの動作停止（DoS）、認証・アクセス制御のバイパス、悪意ある外部サーバーへのリクエスト誘導（SSRF）、そして情報漏えいが挙げられています。CVE番号やバージョン表記は原記事に明記されたものをそのまま採用しており、それ以外の技術的な因果関係については本稿での一般的な解説であることをあらかじめお断りしておきます。
技術的背景：なぜこれらが「まとめて」危険なのか
今回の修正群を俯瞰すると、単発の実装ミスというより、Next.jsが担っている「リクエストをどう受け取り、どう振り分け、どうキャッシュし、どう返すか」という基盤部分に横断的な見直しが入ったことが分かります。ここでは代表的な脆弱性カテゴリの技術的な意味を整理します。
App RouterのDoSリスク
App Routerはページ・レイアウト・APIルートのレンダリングパイプラインを担う中核機構です。ここに存在するDoS脆弱性は、細工されたリクエストによってサーバー側の処理コストを異常に増大させ、正規ユーザーへのレスポンスが遅延・停止する可能性を持ちます。CPUやメモリを消費させるタイプの脆弱性は、外部から明示的な認証情報なしに引き起こせるケースが多く、公開エンドポイントを持つサービスほど影響が大きくなりがちです。
Turbopack×単一ロケール構成でのミドルウェア・プロキシバイパス
Next.jsのミドルウェアは、認証チェックやリダイレクト、国際化（i18n）ルーティングなど、リクエストがページ処理に到達する前段の関門として使われることが多い機能です。特定のビルドツール（Turbopack）と単一ロケール構成という組み合わせ条件下でこの関門を迂回できるとすれば、「ミドルウェアで守っているつもりだったチェックが実は素通りしていた」という事態になりえます。ミドルウェアで認可判定を行っている構成では、このカテゴリの脆弱性は実質的な認証バイパスと同義になり得るため注意が必要です。
rewrites起因のSSRF
rewrites（書き換え）は、特定パスへのリクエストを別のURLへ内部的に転送する設定です。この処理に外部から制御可能な入力が混入すると、攻撃者が意図した任意の宛先へサーバー自身にリクエストを送らせる、いわゆるSSRF（Server-Side Request Forgery）に発展します。SSRFは単体でも情報漏えいにつながりますが、クラウド環境ではメタデータエンドポイントへのアクセスなど、より深刻な二次被害の起点になることが知られている攻撃パターンです。
キャッシュ混同と内部エンドポイントの開示
リクエストボディに起因するキャッシュ混同は、本来ユーザーごとに異なるべきレスポンスが誤って共有キャッシュに乗ってしまい、別のユーザーに配信される可能性を示します。また、認証されていない内部サーバー機能エンドポイントの開示は、本来は内部処理専用であるべき経路が外部から到達可能な状態になっていたことを意味します。いずれも直接の侵害ではないものの、後続の攻撃の足がかりとして利用されやすいカテゴリです。
影響範囲：誰が対応すべきか
今回のセキュリティリリースの影響範囲は、Vercelのホスティング環境を使っているかどうかにかかわらず、Next.jsフレームワーク自体を使っている全てのプロジェクトに及びます。特に次の条件に該当する場合は優先度を上げて確認してください。
- App Routerを使用したプロジェクト全般
- Server Actionsによるフォーム送信・データ更新処理を実装している場合
- next/image等の画像最適化APIを利用している、特にSVGを扱っている場合
- ミドルウェアで認証・認可・リダイレクト制御を行っている場合
- next.configでrewrites（書き換え）ルールを設定している場合
- Turbopackをビルド・開発サーバーに利用しており、かつ単一ロケール（i18n設定が単一言語）で運用している場合
- 自社インフラ・オンプレミス・他クラウドでNext.jsをセルフホストしている場合（Vercel環境限定の問題ではないため）
逆に言えば、これらの機能を一切使っていない極めて小規模な静的サイトであっても、Next.js自体のバージョンが対象範囲に含まれる以上、放置してよい理由にはなりません。バージョンの棚卸しをまず行うことが出発点になります。
開発者が今すぐ取るべき対応手順
公式リリースでは、対象バージョンへのアップデートはパッケージマネージャのコマンドで実施できるとされています。以下は一般的な更新手順の例です（実際のコマンドはプロジェクトのパッケージマネージャに合わせてください）。
npm install next@latest
# または
yarn add next@latest
# または
pnpm add next@latest
ただし、単に最新化するだけでは不十分です。次の手順で確認まで含めて対応してください。
ステップ1：現在のバージョンを確認する
package.jsonおよびロックファイル上のNext.jsのバージョンを確認し、Active LTS（v16.2.11未満）・Maintenance LTS（v15.5.21未満）のいずれの系列に属しているかを特定します。
ステップ2：対象バージョンへアップデートする
使用中の系列に応じて、v16.2.11以上、またはv15.5.21以上へアップデートします。v16.3系のカナリア・プレビューを追っている場合は、それぞれv16.3.0-canary.92以降、v16.3.0-preview.7以降を利用し、安定版v16.3.0のリリース情報にも注意を払ってください。
ステップ3：ミドルウェア・rewrites設定を棚卸しする
アップデートに加えて、ミドルウェアで認可判定のみに依存していないか、rewritesの転送先が外部入力によって変わる設計になっていないかをコードレベルで再点検します。フレームワーク側の修正が入っても、アプリケーション側の設計そのものが危険なパターンになっている場合は、あわせて見直す価値があります。
ステップ4：Turbopack＋単一ロケール構成の場合は個別確認
Turbopackをビルドに使用し、かつi18nを単一ロケールで構成している場合は、アップデート後に実際にミドルウェアが期待通り機能しているか（認証必須ページへの直接アクセスが弾かれるかなど）を手動でも確認します。
ステップ5：ステージング環境で検証してから本番反映する
今回はDoSに関する修正も含まれるため、アップデート自体が既存の挙動に影響を与えないか、ステージング環境での動作確認を経てから本番デプロイすることを推奨します。
ステップ6：監視とログを強化する
アップデート後も、異常なリクエスト増加、想定外の外向き通信（SSRFの兆候）、レスポンスタイムの急激な悪化がないか、しばらくの間は監視を強化しておくと安心です。
チェックリスト
- □ 自社プロジェクトのNext.jsバージョンを確認した
- □ Active LTS / Maintenance LTS のどちらの系列か特定した
- □ v16.2.11以上、またはv15.5.21以上へアップデートした（v16.3系利用者は対応バージョンを確認した）
- □ App Router・Server Actions・画像最適化APIの利用有無を洗い出した
- □ ミドルウェアの認可ロジックを再点検した
- □ next.configのrewrites設定に外部入力依存の転送先がないか確認した
- □ Turbopack＋単一ロケール構成の場合、更新後にミドルウェア動作を手動確認した
- □ ステージング環境で動作検証を行ってから本番へ反映した
- □ デプロイ後、アクセスログ・外向き通信・レスポンスタイムを監視している
- □ 今後の安定版v16.3.0のリリース情報を継続的にウォッチする体制を整えた
まとめ
2026年7月のNext.jsセキュリティリリースは、App Router・Server Actions・画像最適化API・ミドルウェア・rewritesという、多くのプロダクションサービスが日常的に依存している機能群にまたがる9件のCVEをまとめて修正するものでした。単一の脆弱性の深刻さだけでなく、「複数の経路が同時に見直された」という事実そのものが、フレームワークの根幹部分に対する棚卸しの必要性を示しています。
Next.jsのようなフルスタックフレームワークでは、フレームワーク側の脆弱性がそのままアプリケーションの認可・キャッシュ・通信経路の脆弱性に直結します。バージョンアップを「後回しにできる雑務」ではなく、「今日中に着手すべきセキュリティ対応」として扱い、今回紹介したチェックリストを使って自社プロジェクトの状態を確認しておくことを強く推奨します。
コメント