フレームワーク ソフトウェア セキュリティ 公開日 2026.05.15 更新日 2026.05.15

Next.js 2026年5月セキュリティリリースまとめ|13件の脆弱性とアップグレード手順

2026年5月に Vercel公開した Next.js セキュリティリリースは、認可バイパス・SSRF・XSS・DoS・キャッシュポイズニングを含む 13件の脆弱性を一括修正しました。`WAF では完全対策にならない、パッチングが唯一の方法』 と公式が明言しており、緊急アップグレードが推奨されます。修正内容、推奨バージョン、移行手順を整理します。

先に要点

  • 2026年5月に Vercel公開した Next.js セキュリティリリース は、認可バイパス / SSRF / XSS / DoS / キャッシュポイズニング を含む 13件の脆弱性 を一括修正した、近年でも特に大規模な緊急アップデート。
  • 推奨アップグレード先は ` Next.js 16.2.6』 または ` Next.js 15.5.18』` Next.js 13.x / 14.x』 はそのままだと安全パッチを受けられない ため、`15.5.18 か 16.2.6 へ上げる』 のが事実上の唯一の対応。
  • `react-server-dom-*』 系も ` 19.0.6 / 19.1.7 / 19.2.6』 へ揃って上がる。RSC 利用者は要確認。
  • Vercel は今回 ` WAF レベルの保護では対応できない、パッチングが唯一の完全な対策』と明言。`CDNWAF を入れてるから後回しで OK』 が成立しない設計レベルの問題が含まれている。

Next.js から Security advisory』 のメールが大量に来て焦った』 13件って多すぎて何から見ればいいの?』 App Router 使ってるけど、自分は影響あり?』 ── 2026年5月の Next.js セキュリティリリースは、`大量の advisory が一度に出た事件』 として、フロントエンド界隈で大きな話題になりました。

ざっくり言うと、これは 認可・SSRF・XSS・DoS・キャッシュポイズニング』</strong> という <strong>Web セキュリティの代表的な攻撃面に複数の穴があった</strong> ことを、Vercel が <strong>調整リリース</strong> として一気に公開したものです。 どれか1個だけ』 のニュースではなく、`同時に直さないと意味がない』 種類の修正が並んでいるのが、今回の重さの正体です。

この記事では、現時点(2026年5月15日)で公開されている Vercel の changelog をベースに、13件の脆弱性の中身・推奨バージョン・移行手順・運用上の注意 を整理します。 具体的な CVE 番号や CVSS スコアは順次更新されるので、最終確認は必ず 公式 changelog と各 GitHub Security Advisory を見てください。

修正された 13 件 — 分類で押さえる

`脆弱性名だけ羅列されても頭に入らない』 ので、まず 5つのカテゴリ で整理します。

カテゴリ 件数 主な内容 影響面
認可バイパス / プロキシ回避 5 App Router プリフェッチ・Pages Router i18n・動的ルートパラメータの隙間で認可を抜けるパターン 本番アプリの権限境界
DoS 3 RSC DoS(CVE-2026-23870)、キャッシュコンポーネントでの接続枯渇、画像最適化 API 経由 サービス停止リスク
SSRF 1 WebSocket アップグレードリクエスト処理の脆弱性 内部ネットワークへの不正アクセス
キャッシュポイズニング 2 RSC レスポンスのキャッシュポイズニング、RSC キャッシュバスティング衝突 他ユーザーに汚染データ表示
XSS 2 CSP nonce 使用時 XSS、`beforeInteractive』 スクリプトでの XSS セッション乗っ取り・改ざん

13件の advisory』 と聞くと身構えますが、<strong> 5つの攻撃面に対する複数の修正』 と理解すれば見通しは立ちます。

カテゴリ別に何が起きうるか

各カテゴリでどんな攻撃が現実に起きうるかを整理します。

1. 認可バイパス / プロキシ回避(5件)

本来ログインユーザーや特定権限でしか見られない / 操作できないリソース』 が、<strong> URL の組み立て方や Pages Router の i18n 設定の隙間』 を突くことで認可なしにアクセスできてしまう、というカテゴリです。

App Router セグメントプリフェッチ経由(高)

Next.js が裏で投げる ` プリフェッチ用リクエスト』 が、本来の Middleware / 認可チェックを通らずにレスポンスを返してしまうケース。`認証ガードした管理画面』 が、リンクホバーだけで内容を漏らす可能性がある。

プリフェッチバイパス追加修正(高)

過去のセキュリティ修正が 不完全 だった部分への追加対応。`前回ちゃんとアップデートしたから安心』 が成立しない、というのが今回の特に難しいところ。

Pages Router i18n + プロキシ(高)

`デフォルトロケールパス』 の解釈の差で、`/ja/admin』 は守られているが `/admin』 ではプロキシ / Middleware を通らずに到達してしまう、というパターン。

動的ルートパラメータインジェクション(高)

` [id] のような動的セグメント』 に細工した値を渡して、認可ロジックを欺くタイプ。`ID チェックを Middleware に任せきり』 のアプリで顕著。

このカテゴリは 本番アプリの権限境界を壊す』</strong> 直接的な影響があり、AdSense や決済を扱うサイト』 ほど被害が大きくなります。

2. DoS(3件)

サービスを止める / 重くする』 攻撃面で、<strong> 1 リクエストで複数の関数を起動させる』 `重い処理を呼ばせて関数を枯渇させる』 系の修正です。

RSC DoS(CVE-2026-23870、高)

React Server Components 経由で `特定のリクエストを送ると関数が暴走 / メモリ枯渇』 を起こせる。`App Router 採用済み + 本番』 のアプリ全部が対象になる重要修正。

キャッシュコンポーネント接続枯渇(高)

` キャッシュコンポーネント機能を使うと、特定パターンのリクエストで接続が枯渇 → サービス停止』 という構造。`new キャッシュ機能を試したばかり』 のチームほど踏みやすい。

画像最適化 API 経由 DoS(中)

`/_next/image』 への巨大画像や悪意あるパラメータで、関数実行時間とメモリを食わせる。Vercel の請求暴発 の典型原因でもある。

なぜ脅威か

` 攻撃者は1台のサーバから自由にリクエストを撃てる』 ので、`攻撃者の手元のコスト = 数百〜数千円、防御側のコスト = 関数実行 + 帯域で数十万円』 のような 非対称さ が成立してしまう。

DoS は古い話』 と思われがちですが、<strong> サーバレス課金 + AI ストリーミング』 時代では、これが ` 経済的破壊』 として実害になりやすいので注意が必要です。

3. SSRF(1件)

` WebSocket アップグレードリクエスト処理時の SSRF(高)』 が修正されました。

SSRF とは

` サーバ自身に内部ネットワーク向けのリクエストを送らせる』 攻撃。` クラウド環境のメタデータエンドポイント(169.254.169.254)』 等を踏ませると、`Vercel 上の関数がクラウド側の認証トークンを取得 → 攻撃者に返す』 が成立し得る。

なぜ重大か

` クラウドの一時認証情報』 を盗まれると、`そこから DB 接続文字列や S3 アクセス』 まで芋づる式に取られる。`npm のサプライチェーン攻撃 と組み合わさると一気に深刻』。

WebSocket がきっかけ

` WebSocket 対応』 を入れている案件で、`upgrade ヘッダ』 を細工することで成り立っていた。`普通の HTTP しか使ってない』 サイトでは直接の影響は小さい可能性があるが、念のためアップデートはすべき。

WAF だけでは塞げない

`WAF で 169.254.169.254 をブロック』 のような対策では、`内部 DNS や IPv6 のループバック』 を経由されると素通りする場合がある。` アプリ側で根本修正』 しかない。

内部ネットワークに直結する穴』 はクラウド時代でいちばん怖い種類の脆弱性で、SSRF だけで Patch 必須』 と言える重みがあります。

4. キャッシュポイズニング(2件)

`他人のキャッシュに、攻撃者が望む内容を流し込む』 タイプの修正です。

RSC レスポンスのキャッシュ汚染(中)

`RSC』 のレスポンスは独自のキー設計で CDN にキャッシュされている。攻撃者が `キーを共有するように仕向ける』 と、`A 用に作られた個人情報入り RSC が、B にも返る』 という事故が起こる。

RSC キャッシュバスティング衝突(低)

キャッシュキーの計算が衝突しやすいパターンを使うと、`同じキャッシュ箱に複数のレスポンスが入って取り違える』 ことができてしまう。低スコアだが、`200 でエラーを返す API』 のような実装と組み合わさると影響が拡大。

他の Middleware 修正と関連

` Middleware リダイレクトのキャッシュポイズニング(低)』 も、認可バイパスのカテゴリと同じ系統。`リダイレクト先のレスポンスが共有キャッシュに残る』 と、`認可なしユーザーが、認可済みユーザー向けのリダイレクトを引き当てる』 が起きうる。

他者への影響が大きい

` キャッシュ汚染』 の怖さは、` 攻撃者だけでなく一般ユーザーまで影響を受ける』 ところ。`誰かが個人情報を見られた』 という事故報告の原因として頻出する。

認可は通しているのに、キャッシュ層で情報が漏れる』 は、認可だけ守れば安全』 という直感を裏切る種類の問題です。

5. XSS(2件)

CSP nonce 使用時の XSS(中)』 と beforeInteractive スクリプトの XSS(中)』 が修正されました。

CSP nonce 使用時 XSS

` Content Security Policy で nonce を使ってる』 と XSS から守られる想定だが、` Next.js 側の nonce 配り方の隙間』 でバイパスされるパターン。`CSP を入れているから安全』 と過信していたサイトほど痛い。

beforeInteractive スクリプト XSS

` next/script の beforeInteractive 戦略』 で読み込むスクリプトに、信頼できない入力が混ざるとそのまま実行される。`URL クエリから一部を Script タグの src に渡す』 ような書き方をしているコードが要注意。

XSS が成立すると何が起きるか

セッション Cookie の窃取、なりすまし送信、暗号資産ウォレットの拡張機能を介した取引承認…等。`お問い合わせフォームから JS が刺さる』 だけで、`管理者の権限を奪う』 まで行ける重さ。

対策の組み合わせ

`CSP の見直し』 `next/script の戦略変更』 `ユーザー入力の徹底エスケープ』 など、フレームワーク側のパッチに加えてアプリ側のレビューも必要。` パッチを当てて終わり、ではない』 のがこのカテゴリ。

CSP / Next.js のスクリプト戦略』 はセキュリティの最後の盾になっていることが多いので、それごとバイパスされる』 は精神的にも痛みのある修正です。

推奨アップグレード先

公式が示している推奨バージョンを表で並べます。

パッケージ 影響範囲 アップグレード先
Next.js 13.x / 14.x 全バージョン 15.5.18 または 16.2.6
Next.js 15.x ≤ 15.5.17 15.5.18
Next.js 16.x ≤ 16.2.5 16.2.6
react-server-dom-* 19.0.x ≤ 19.0.5 19.0.6
react-server-dom-* 19.1.x ≤ 19.1.6 19.1.7
react-server-dom-* 19.2.x ≤ 19.2.5 19.2.6

13.x / 14.x はもう個別パッチが配られていない』 という点が重要で、<strong> 古いままで放置すると、今回の問題に永遠にパッチが当たらない』 状態になります。

緊急アップグレードの段取り

`いきなり本番に上げて壊す』 を避けるための現実的な手順を整理します。

読み込み中...

段階を分けてゆっくり』 ではなく、<strong> 段取りは丁寧に組むが反映は早く』 という方針が、こうした緊急パッチでは大事です。

なぜ `WAF / CDN だけでは不足』 なのか

Vercel が今回明示している `パッチングが唯一の完全な対策』 という言葉の理由を整理しておきます。

攻撃面がアプリ内部

` 認可バイパス』 `RSC のキャッシュキー計算』 など、` Next.js 内部の処理ロジック』 に依存する穴。`外部からのリクエストをフィルタする WAF』 では、`正規にしか見えないリクエスト』 を弾けない。

プリフェッチは内部から飛ぶ

` 認可バイパスのうちプリフェッチ系』 は、`正規ブラウザの Next.js JS が裏で発行する』 内部リクエスト。CDN / WAF にとっては `普通の正規ユーザー』 にしか見えない。

パッチ済みの再現性

` 1度パッチを当てれば全リクエストで安全』 なのに対し、`WAF 設定』 は ` 環境差や設定ミスでザル化』 しやすい。`同じ攻撃に対して同じ強度で守れる保証』 はパッチング側が圧倒的に高い。

運用上の現実

` Vercel に乗っているなら CDN / WAF は Vercel 側』、`AWS / GCP 上のセルフホスト』 なら別 WAF。` パッチを当てる』 行動は、どの環境でも同じ意味で効く

`まず CDN / WAF で間に合わせ → あとで Next.js を上げる』 を選びたくなる気持ちは分かりますが、今回はそのルートが 意味のある守りにならない のが重要なポイントです。

教訓 — `Next.js を上げる文化』 を組織に作る

毎月のように来る Next.js のセキュリティ修正に対応し続けるための、組織レベルの仕組みを整理しておきます。

①バージョンを `pinned』 で固定する

` ^15.5.x』 のような緩いレンジではなく、` 15.5.18』 のように `pinned』。`勝手にメジャー / マイナーが上がる』 状態を避け、`意図して上げる』 だけにする。

② Dependabot / Renovate でアラート

` 新しいセキュリティパッチが出たら自動で PR』 が来る仕組み。`気付かない』 を構造的に防ぐ。

③ アップグレード用 PR テンプレ

` Next.js / React のアップグレード手順を社内 Wiki に保存』。`誰が PR を出しても同じ確認項目をたどれる』 状態に。

④ 月1の `依存ヘルスチェック』

` 月1で `Next.js / React / Vercel 公式 changelog』 をチームで読む会』 を 30 分でも設けると、`急なセキュリティリリース』 にも反応が早くなる。

このサイズの修正は今後も繰り返し来る』 前提で、いつでも上げられるチーム』 を作っておくのが、長期的には一番安いコストです。

AI 時代の前提として

v0 / Vercel を起点に AI でアプリを作る人が増えれば増えるほど、` 雛形の Next.js のバージョンが古いまま放置される』 パターンも増えます。

AI 生成テンプレの危険性

AI が `Next.js 13 / 14 のサンプル』 を出してきても、現状は本番運用に向かない。`AI 出力 = 古い Next.js』 を疑うクセが必要。

Mini Shai-Hulud との連動

npm 経由の Mini Shai-Hulud も、`脆弱な Next.js + 漏れた API キー』 の組み合わせで被害が拡大する。`Next.js のパッチ』 と `依存の signing 検証』 はセットで投資する価値がある。

RSC を採用する責任

` App Router + RSC』 を使うアプリは、`RSC キャッシュ / Server Action / Middleware』 周辺の最新セキュリティ動向を追う責任』 がワンセットになる。`楽な機能ほど深い影響範囲を持つ』 のはどのフレームワークでも同じ。

小さなチームほど自動化

` 個人 / 小チームで Next.js を本番運用するなら、Dependabot は最小コストで最大価値』。`気付ける PR が自動で来る』 仕組みを最初に積むのが、AI 時代の `1人で運用する SaaS』 の必須インフラ

AI で爆速に作る』 と セキュリティを継続的に当てる』 は、両立しないと意味がないペアです。

Next.js 2026年5月セキュリティリリースに関するよくある質問

Q. 自分は Pages Router しか使っていません。13.x のままで大丈夫ですか?

A. 大丈夫ではありません』</strong>。i18n + プロキシ』 の認可バイパスや `WebSocket SSRF』 など、Pages Router でも影響を受ける項目が含まれます。13.x への単独パッチは提供されないため、15.5.18 または 16.2.6 へのアップグレード が事実上の対応です。

Q. 13 / 14 から 15 / 16 への移行は大変ですか?

A. ケースバイケースだが、思っているより小さい』</strong> ことが多いです。多くのチームではApp Router への部分移行は別タスクにして、ライブラリだけ上げる』 で済みます。getServerSideProps が残るアプリ』 は、Pages Router の機能としては当面サポートされるので、まずバージョンだけ上げる』 を先に済ませるのが安全です。

Q. WAF や Cloudflare のルールで一旦防げないですか?

A. 一部は緩和できるが、完全な対策にはなりません』</strong>。特にプリフェッチ経由の認可バイパス』 RSC のキャッシュキー衝突』 系は、外形的に正規リクエストと区別がつかないため、フレームワーク側のパッチでしか塞げません。WAF で時間を稼ぐ間にパッチを当てる』 は OK ですが、`WAF があるからパッチしない』 はダメです。

Q. CVECVSS スコアの一覧はどこで見られますか?

A. GitHub の Next.js リポジトリの Security Advisory』</strong> と、<strong> vercel.com/changelog の該当ページ』がそれぞれの一次情報です。記事中の CVE-2026-23870(RSC DoS)以外は、Vercel changelog から各 advisory へのリンクが張られています。

Q. アップグレード後に挙動が変わったらどうしますか?

A. 認可バイパス修正でリダイレクト挙動 / Middleware 挙動が変わる』</strong> のが今回特に多いポイントです。Preview Deployment』 で先に動かし、<a href="/articles/representative-http-status-codes-explained">301 / 302 / 401 / 403』 の挙動を意図したものか比較</a>するのが現実的です。Vercel の Spend Management』 を上限設定しておくと、DoS 系の事故にも保険がかかります。

Q. RSC を使っていません。`react-server-dom-*』 もアップグレードすべきですか?

A. Next.js 15 / 16 を使うなら、依存として入っているので合わせて上げるのが原則』</strong>です。使っていない機能のために古いバージョンを残す』 は将来の他の脆弱性のリスクが残るだけなので、`整合するバージョンに合わせる』 が無難です。

Q. 同様のセキュリティリリースは今後も来ますか?

A. ほぼ確実に来ます』</strong>。Next.js は機能追加が速いフレームワークで、攻撃面』 も同時に増えています。`Dependabot / Renovate を入れて、月1で公式 changelog を見る』 という運用を組織に作っておくのが、長期的に一番安い対応です。

参考リンク

あとで見返すならここで保存

読み終わったあとに残しておきたい記事は、お気に入りからまとめて辿れます。