【更新 2026-08-02】本記事を見直し、修正しました。主な修正点：ミドルウェア／プロキシによる認可回避の公表回数を「4度目」から「6度目」に訂正し、経緯の表から抜けていた CVE-2026-44573・CVE-2026-44574（いずれも2026年5月6日公表）を追加。あわせてサポート表の16.x欄を、次のメジャー版公開でサポート終了ではなく Maintenance LTS へ移行する旨に訂正。
2026年7月21日、Next.js が9件の脆弱性（High 4件・Medium 5件）を修正した「7月セキュリティリリース」を公開しました。ミドルウェアで実装した認証・認可がまるごと回避されるもの、サーバー側から攻撃者の指定したホストへ通信させられる SSRF などが含まれます。影響範囲は古いもので v12.0.0 まで遡りますが、修正版として提供されたのは v16.2.11 と v15.5.21 の2系列だけです。
自社サイトや社内ツールに Next.js が使われているなら、今日やることは3つです。(1) 使用しているバージョンを確認する、(2) 後述の「構成条件」で該当有無を判定する、(3) 15.5.21 または 16.2.11 へ更新する。13系・14系を使っている場合は更新先が存在しないため、メジャーバージョンの移行計画そのものが対応策になります。
この記事でわかること
- 今回修正された9件の CVE と、それぞれの影響バージョン
- 「バージョンが古い＝該当」ではない理由と、構成による該当判定の手順
- ミドルウェアによる認証回避が Next.js で繰り返されている経緯
- 13系・14系に修正版が無いこと、15系が2026年10月にサポート終了する事実
- 情シスとして自社の Next.js を棚卸しする現実的な方法
何が起きたのか
Next.js は React ベースの Web アプリケーションフレームワークで、企業のコーポレートサイトやオウンドメディア、社内向けの業務ツールまで幅広く使われています。開発元の Vercel は2026年7月13日に「今後は月に1回程度、事前予告つきでセキュリティリリースを出す」と発表し、その第1弾が今回の7月リリースです。JPCERT/CC も7月29日付の Weekly Report で取り上げています。
修正された9件は以下のとおりです。バージョン範囲はホスティング事業者 Netlify が公開した一覧および各 GitHub Security Advisory によります。
| CVE | 深刻度 | 内容 | 影響を受けるバージョン |
|---|---|---|---|
| CVE-2026-64641 | High | Server Action への細工リクエストで CPU を食い潰し、同一プロセスの他リクエストも止まる（DoS） | 13.0.0〜15.5.20 / 16.0.0〜16.2.10 |
| CVE-2026-64642 | High | Turbopack ビルド＋ロケール1件の構成で、ミドルウェア／プロキシによる認証・認可が回避される | 16.0.0〜16.2.10 |
| CVE-2026-64645 | High | rewrites() / redirects() の転送先ホスト名をリクエスト由来の値で組み立てていると、任意ホストへ向けられる（SSRF・オープンリダイレクト） | 12.0.0〜15.5.20 / 16.0.0〜16.2.10 |
| CVE-2026-64649 | High | カスタムサーバー構成で Server Action が転送・リダイレクトする際、Host 系ヘッダーを操作されて悪意あるホストへ送信させられる（SSRF） | 14.1.1〜15.5.20 / 16.0.0〜16.2.10 |
| CVE-2026-64643 | Medium | Server Action / use cache のエンドポイント ID が未認証で外部に露出する（偵察に利用される） | 13.0.0〜15.5.20 / 16.0.0〜16.2.10 |
| CVE-2026-64644 | Medium | セルフホスト時、画像最適化 API が悪意ある SVG を処理して CPU を消耗する | 15.5.0〜15.5.20 / 16.0.0〜16.2.10 |
| CVE-2026-64646 | Medium | Edge ランタイムの Server Action でペイロード上限が無く、メモリを消費させられる | 13.0.0〜15.5.20 / 16.0.0〜16.2.10 |
| CVE-2026-64647 | Medium | 不正な UTF-8 を含むリクエストボディで、別リクエストのキャッシュ済みレスポンスが返る | 13.0.0〜15.5.20 / 16.0.0〜16.2.10 |
| CVE-2026-64648 | Medium | 特定形式の fetch 呼び出しで、ボディが異なる別リクエストのキャッシュ済みレスポンスが返る | 13.0.0〜15.5.20 / 16.0.0〜16.2.10 |
修正版は v15.5.21（Maintenance LTS） と v16.2.11（Active LTS） です。
最も影響が大きいのはどれですか
認証・認可が回避される CVE-2026-64642 です。ミドルウェアでログインチェックをしている構成では、そこを通らずに保護対象のページへ到達される可能性があります。
NVD が付けた CVSS v3.1 で見ると CVE-2026-64641（DoS）が 7.5、GitHub 提供の CVSS v4.0 では 8.2 と、数値上は DoS 系が上位に並びます。ただし DoS は復旧できるのに対し、認証回避は気づかないまま情報が抜かれるため、実務上の優先度は逆になります。スコアだけでトリアージすると判断を誤る典型例です。
該当判定はバージョンだけでは決まらない
今回の9件は、いずれも「特定の機能・構成を使っている場合に限り成立する」タイプです。バージョンが範囲内でも、その機能を使っていなければ該当しません。逆に言えば、開発を外部に委託していて構成が分からない場合、社内だけでは判定できません。
| 確認すること | 該当する CVE |
|---|---|
| App Router を使っており、Server Action が1つ以上ある | 64641 / 64643 / 64646 |
Turbopack でビルドし、config.i18n.locales の要素が1件だけ |
64642 |
rewrites() / redirects() の転送先ホスト名をリクエスト値から組み立てている |
64645 |
| カスタムサーバー構成で動かしている | 64649 |
| セルフホストで既定の画像ローダーを使い、外部ホストの画像最適化を有効にしている | 64644 |
なお Vercel や Netlify のようなホスティング事業者を経由している場合、事業者側の構成によって実際の影響は変わります。Netlify は自社上のサイトについて、CVE-2026-64649 と CVE-2026-64644 は「影響なし」、CVE-2026-64641 と CVE-2026-64646 は「基盤側の上限により軽減」と説明しています。ただしこれは事業者ごとに異なる話なので、「どこかが守ってくれているはず」で更新を止めないことが肝心です。
ミドルウェアの認証回避は、これで6度目
CVE-2026-64642 は単発の事故ではありません。Next.js のミドルウェア（またはプロキシ）による認可チェックが回避される欠陥は、直近1年半で繰り返し公表されています。
| 公表 | CVE | 回避の入口 | 修正版 |
|---|---|---|---|
| 2025年3月 | CVE-2025-29927 | x-middleware-subrequest ヘッダーを付けるとミドルウェアの実行がスキップされる |
12.3.5 / 13.5.9 / 14.2.25 / 15.2.3 |
| 2026年5月6日 | CVE-2026-44573 | Pages Router で i18n を設定している場合、ロケール接頭辞の無い /_next/data/<buildId>/<page>.json にミドルウェアが適用されず、保護対象ページの SSR JSON を取得できる |
15.5.16 / 16.2.5 |
| 2026年5月6日 | CVE-2026-44574 | 細工したクエリパラメータでページ側が見る動的ルートの値だけを書き換えられ、URL のパスを変えずにミドルウェアの判定をすり抜ける | 15.5.16 / 16.2.5 |
| 2026年5月6日 | CVE-2026-44575 | セグメントプリフェッチ用の URL がミドルウェアのマッチャーに含まれていなかった | 15.5.16 / 16.2.5 |
| 2026年5月7日 | CVE-2026-45109 | 上記の修正が Turbopack ビルドの経路に適用されておらず、同じ回避が成立（不完全修正） | 15.5.18 / 16.2.6 |
| 2026年7月21日 | CVE-2026-64642 | Turbopack ビルド＋ロケール1件の構成で回避 | 16.2.11 |
入口はそのつど違いますが、根っこは同じです。ミドルウェアは「すべてのリクエストが必ず通る関所」ではなく、フレームワークがどのリクエストを通すか決めているに過ぎないという構造です。ルーティングの仕組みが増えるたびに、通らない経路が新しく生まれます。
したがって開発側への要望として伝えるべきは「更新してください」だけではありません。認可の判定をミドルウェアだけに置かず、データを返す処理そのもの（Server Action・API ハンドラ・データ取得層）でも実施しているかを確認してください。1つ抜けても情報が出ない構造になっていれば、次に同種の CVE が出ても被害に至りません。
見落とされやすいのは「13系・14系」と「15系のサポート終了」
今回の影響範囲は多くが 13.0.0 から、CVE-2026-64645 に至っては 12.0.0 からです。しかし公式が出した修正版は 15.5.21 と 16.2.11 の2つだけでした。これは Next.js のサポートポリシーによるもので、現在の対象は次の2系列に限られます。
| バージョン | 初回リリース | 状態 | サポート終了 |
|---|---|---|---|
| 16.x | 2025年10月21日 | Active LTS | 未定（次のメジャー版が出た時点で Maintenance LTS へ移行し、その後もセキュリティ更新は継続） |
| 15.x | 2024年10月21日 | Maintenance LTS（重大なバグ修正と必須のセキュリティ更新のみ） | 2026年10月21日 |
| 14.x 以前 | 2023年10月26日以前 | サポート対象外 | 終了済み |
ここから2つの事実が出てきます。
- 13系・14系のサイトは、今回の脆弱性の影響を受けるのに当てるパッチが存在しない。「更新して終わり」にはできず、15系または16系への移行が唯一の対応になります。
- 15系に更新しても、2026年10月21日でサポートが切れる。本記事執筆時点（2026年8月）から約3か月後です。今回 15.5.21 を当てる作業をするなら、同じ稟議で16系への移行も俎上に載せるのが現実的です。
Vercel は今後「月1回程度・事前予告つき」でセキュリティリリースを出すと明言しています。予定が読めるようになるのは運用側にとって朗報ですが、裏を返せば更新作業が毎月発生する前提になったということです。サポート切れのバージョンに留まるコストは、これから毎月増えていきます。
現場目線：そもそも自社に Next.js があると気づけない
正直なところ、情シスにとって一番厄介なのは技術的な中身よりも「うちで使っているのか分からない」という点だと思います。Next.js は資産管理ツールの「インストール済みソフトウェア一覧」には出てきません。package.json の依存関係として書かれているだけで、動いているのは委託先が構築したコーポレートサイトのサーバーだったりします。
しかも導入の主体が情シスでないことが多い。広報部門が制作会社に発注したキャンペーンサイト、事業部門が内製した業務ツール、数年前の担当者が立てたまま引き継がれていない社内ポータル。こうしたものは脆弱性情報が出ても誰も自分ごとにしないという共通点があります。同じ構図は、内製ツール基盤 Appsmith の脆弱性でも起きています。
棚卸しの現実的な一手は次の2つです。
- 自社管理のサーバー・リポジトリ側：
package.jsonを横断検索するか、稼働環境でnpm ls nextを実行してバージョンを確定させる。依存ライブラリの更新が滞りがちなのは研究でも裏付けられている実態です。 - 委託先が運用しているサイト：制作・保守の委託先に「Next.js の使用有無、バージョン、7月セキュリティリリースへの対応状況」を照会する。今回のように構成で該当が決まるケースでは、委託先しか答えを持っていません。契約に脆弱性対応の責任分界が書かれているかも、この機会に確認しておきたいところです。
この「発注はしたが中身は把握していない」という状態は、広い意味でのサプライチェーンのリスクそのものです。1回で完璧な台帳を作ろうとせず、まず公開サイトの一覧から着手するのが続けやすいと感じます。
情シスはどうすべきか
技術的な対策そのものは開発・委託先の作業になりますが、情シスが押さえるべき論点は公的な指針にまとまっています。まずはこちらを参照してください。
- IPA「安全なウェブサイトの作り方」 … 主要な脆弱性の解説に加え、「安全なウェブサイトの運用管理に向けての20ヶ条」が委託先との会話の共通言語になります。今回のような SSRF・オープンリダイレクトの位置づけを確認するのにも使えます。
- IPA「中小企業の情報セキュリティ対策ガイドライン」 … 委託先管理や資産の把握といった、体制面の指針が整理されています。
- JPCERT/CC Weekly Report … 今回の Next.js もここで取り上げられました。月次リリースが定例化する以上、週次で目を通す運用に載せておくと取りこぼしが減ります。
あわせて、SSRF のように「サーバー自身に外部へ通信させる」タイプの脆弱性は、過去の事例と同様、外向き通信の制限が有効な緩和策になります。パッチ適用と並行して、Web サーバーからの外部宛通信が無制限になっていないかを確認しておくとよいでしょう。
まとめ
- 2026年7月21日、Next.js が9件の脆弱性を修正した。ミドルウェアによる認証・認可の回避（CVE-2026-64642）と SSRF 2件（CVE-2026-64645 / CVE-2026-64649）が実務上の優先対応。更新先は v16.2.11 または v15.5.21。
- 該当判定はバージョンだけでは決まらない。App Router・Server Action・Turbopack・カスタムサーバーといった構成条件で成否が変わるため、委託先を含めて構成を確認する必要がある。
- 13系・14系には修正版が無く、15系も2026年10月21日でサポート終了する。パッチ適用だけでなく、バージョン移行の計画までを今回の対応に含めること。
出典
- July 2026 Security Release | Next.js
- Next.js Security Release and Our Next Patch Release | Next.js
- Next.js Support Policy
- JPCERT/CC Weekly Report 2026-07-29
- NVD – CVE-2026-64641
- GHSA-6gpp-xcg3-4w24（CVE-2026-64642）
- GHSA-267c-6grr-h53f（CVE-2026-44575）
- GHSA-26hh-7cqf-hhc6（CVE-2026-45109）
- Next.js security release (July 2026): what to know | Netlify（各CVEの影響バージョン一覧とホスティング側の影響。ホスティング事業者による整理）
- IPA「安全なウェブサイトの作り方」
