Next.jsのCVE-2025-66478が出たら、まず何をすべき？

結論（Conclusion）

これは「依存更新」ではなくインシデント対応。 最短でやることはこれ。

1. 影響範囲を確認（App Router / RSC利用 + 対象バージョン）
2. 公式に修正済みのNext.jsへ即アップデート
3. プレビューで要所検証（認証/動的ルート/404など）
4. 未修正期間に露出があり得るなら シークレット回転

ホスティング（Vercel等）が脆弱版をビルドブロックするなら、優先シグナルとして即対応。

背景（Explanation）

セキュリティアップデートで時間が溶けるのは、だいたい2つ。

• 対象かどうか分からず止まる
• 更新後に何を確認すべきかが曖昧

チェックリストにすると、調査→不安→先送りループを潰せる。

実務手順（Practical Guide）

手順1：影響範囲を最短で確認する

確認すること：

• App Router（RSC）を使っているか
• 本番に出ているNext.jsバージョン
• Edge runtime のルートがあるか

判断基準：

• 対象かもしれないなら、数時間調査するより「更新→検証」の方が安いことが多い。

手順2：修正版ターゲットを一次情報で確定する

• Next.js公式セキュリティアドバイザリ
• Next.js公式リリースノート

判断基準：

• 「15.1.9+」のような推測ではなく、アドバイザリで修正版を確定する。

手順3：差分を小さく更新する

• next を更新
• 必要なら peer（react, react-dom）もセット
• lockfileをコミット

手順4：CIで早期に落とす

最低ゲート：

• lint
• format
• build

手順5：プレビューで要所だけ確認

• 主要ページ
• 動的ルート（記事等）
• 404/not-found
• 認証があるならログイン→ログアウト1往復
• 計測があるなら発火確認（必要なら）

手順6：デプロイ→即確認

デプロイ後：

• robots.txt
• sitemap.xml
• 主要ページのスモーク

手順7：露出があり得るならシークレット回転

回転する条件：

• 脆弱版を本番で動かしていた
• カテゴリ的に秘密/データ露出があり得る

優先：

• セッション署名鍵
• 認証プロバイダのsecret
• 重要APIトークン

失敗パターン（Pitfalls）

• 対象判定で完璧を求めて止まる
• 修正PRに関係ない更新を混ぜる
• lockfileを忘れて再現性が崩れる
• 検証儀式がなく、本番で気付く
• 「更新したからOK」で回転判断を放置

チェックリスト（Checklist）

• [ ] 本番のNext.jsバージョンを特定した
• [ ] App Router / RSC利用を確認した
• [ ] 修正版ターゲットを一次情報で確定した
• [ ] 修正PRは最小差分（Next + peers）
• [ ] lockfileを更新してコミットした
• [ ] CIゲートが通った（lint/format/build）
• [ ] プレビューで要所確認した（主要/動的/404）
• [ ] 認証/セッションのスモークをした（該当するなら）
• [ ] デプロイ後に robots/sitemap/主要ページを確認した
• [ ] 露出の可能性を判断し、必要ならシークレット回転した
• [ ] 重大更新中は監視/ログレビューを一時強化した

FAQ

Q1. 毎回シークレット回転すべき？

毎回ではない。ただし未修正期間に秘密を扱っていたなら、露出前提で判断して過少回転しない。

Q2. Vercelがビルドブロックするのは何を意味する？

緊急度が高いということ。最低修正版へ最短で寄せる。

Q3. 修正PRを小さくする理由は？

スピードと確信のため。関係ない更新が混ざるとレビューもロールバックも難しくなる。

内部リンク（Internal links）

• 親記事（Hub）：Next.js セキュリティ：まずはここから
• 関連記事：
  • Next.jsのセキュリティアップデート運用
  • Next.jsのセキュリティヘッダー：実務チェックリスト
  • GitHub Actionsを固くする：ハードニングチェックリスト

参考（一次情報）

• Next.js Security Advisory: CVE-2025-66478