Next.jsミドルウェアが“内部ヘッダー”を信頼し過ぎるとき——CVE-2025-29927が突きつける設計リスクです

今日の深掘りポイント

• ミドルウェアの無限ループ回避用ヘッダー（いわば「内部合図」）を外部から偽装されると、認証・地域制限などの制御を素通りされるリスクがある設計課題です。
• フレームワーク更新だけでなく、「内部用ヘッダーは境界で落とす」というネットワーク・アプリ両面のゼロトラスト設計が鍵です。
• ログ監査ではステータス推移（401/403→200）と管理系パスへの“x-middleware-*”系などの異常ヘッダー併用を軸にハンティングするのが近道です。
• SOCはWAF/リバースプロキシで“x-middleware-*”などの内部専用ヘッダーをドロップする一時防御を早期適用し、パッチ適用前後の効果検証を自動化することが重要です。
• MITRE ATT&CKでは、Exploit Public-Facing Application（T1190）に始まる初期侵入ののち、Impair Defenses（T1562）の文脈でミドルウェア回避が機能するシナリオが現実的です。

はじめに

報告によれば、CVE-2025-29927はNext.jsのミドルウェアに存在するバイパス問題で、特定のHTTPヘッダーを用いることで認証や地理的制限といった“防波堤”が迂回されてしまう可能性があるとされます。影響範囲はNext.js 11.1.4から15.2.2までという広さで、攻撃者が未認証のまま管理パネルやユーザーデータに到達できるおそれがあるという指摘です。人気フレームワークゆえに波及は広く、迅速なアップデートと境界での補強が求められる局面です。

一方で、執筆時点で本件に関する公式アドバイザリ（Next.js/VercelやMITRE/NVDの恒常的な一次情報ページ）の個別公開は確認できていません。現状入手できる公開情報は二次情報に限られており、読者のみなさんには公式アドバイザリの更新を継続的に確認しつつ、当面は堅実な暫定対策を重ねることを強くおすすめします。

深掘り詳細

いま確認できる事実関係です

• 公開レポートは、特定のHTTPヘッダーによりNext.jsミドルウェアのセキュリティチェックが迂回されうると説明しています。対象はNext.js 11.1.4〜15.2.2で、認証や地域制限が無効化される可能性が示されています。一次アドバイザリは未確認のため、記載のバージョン範囲や修正済みバージョンは公式情報の公開・更新を待つべきです。
• 報告の背景として「無限ループを防ぐために設計されたカウンター（もしくは内部用フラグ）」に起因するとされ、攻撃者がその合図に相当するヘッダーを外部から与えることでミドルウェアの実行がスキップされる、という説明がなされています。
• 依存管理やWAFの見直し、ログ監査の必要性が強調されており、即時のアップデートが推奨されています。

参考（公開時点で入手可能な二次情報）:

• Security Boulevard: CVE-2025-29927解説記事です。https://securityboulevard.com/2026/01/cve-2025-29927-understanding-the-next-js-middleware-vulnerability-2/ です。

一次情報の確認に活用すべき恒常ページ（個別アドバイザリが公開され次第の確認先）:

• Next.js Security Advisories（GitHub）: https://github.com/vercel/next.js/security/advisories です。
• Vercel Security: https://vercel.com/security です。
• MITRE CVE（トップページ）: https://cve.mitre.org/ です。

注記: 上記のうち、CVE-2025-29927に特化した一次アドバイザリの個別URLは執筆時点で確認できていません。公式の更新を待ち、必ず一次情報で最終判断することをおすすめします。

技術的背景と設計的示唆（仮説を含みます）

• 仮説1: Next.jsはミドルウェア再帰や無限ループを避けるために、内部フェッチや再エントリを示すための“内部用ヘッダー”やカウンターを用いている可能性があります。たとえば過去の設計パターンでは“x-middleware-…”や“x-…”で始まる内部合図を使い、これが存在するとミドルウェアの再実行を抑制する振る舞いがありえます。この内部合図が外部から注入可能なままだと、認証系ミドルウェアの実行自体がスキップされるリスクが立ち上がります。
• 仮説2: リバースプロキシやエッジ環境を前提にしたヘッダー信頼モデルが、パブリック境界で十分に“剥ぎ取り”されない場合に脆弱化します。内部用ヘッダーは本来境界で削除・再注入すべきですが、SaaSやセルフホストの多様なデプロイで一律に保証しづらく、設計として“外部リクエストに同名ヘッダーが来ても無視する”という防御的実装が必要になります。
• 示唆: フレームワークは“便利な内部合図ヘッダー”を持ちがちですが、アプリのゼロトラスト化が進むほど、内部・外部をヘッダーで区別するモデル自体が脆弱になります。境界でドロップし、アプリで無視し、重要判定（認可）はビジネスロジック層で重ねる、という三層防御が現実解です。

影響評価の視点です

• ミドルウェア前提の認証・地域制限・A/B振り分け・メンテナンスモードなどが“素通り”されると、管理UIや内部API、テナント境界の越境、課金や設定変更の不正実行などが派生します。
• ホスティング形態（VercelのEdge、Cloudflare Workers、NGINX/ALB配下のセルフホスト）で挙動や緩和手段が変わるため、境界コンポーネント単位での対策の粒度が重要になります。
• フレームワーク更新だけでは“ヘッダー注入の観測”や“内部ヘッダーの境界ドロップ”といった運用対策は補えないため、検知・可視化・ハンティングの整備が有効です。

脅威シナリオと影響

以下はMITRE ATT&CKに沿った想定シナリオ（仮説）です。

• 初期侵入（T1190: Exploit Public-Facing Application）です。

  • 攻撃者は公開中のNext.jsアプリに対し、“x-middleware-…”等の内部用ヘッダーを付与したリクエストを投下します。
  • ミドルウェアが内部合図と誤認し、認証や地域制限の検査をスキップします。

• 防御回避（T1562: Impair Defenses）です。

  • WAFやアプリ層のルールがミドルウェア上での判定を前提にしていると、ヘッダーバイパスによりログ・アラートが減衰する可能性があります。
  • 地理的ブロックやボット判定などのシグナルが評価されない経路が生まれます。

• 認証回避後の行動です。

  • 情報取得（T1213: Data from Information Repositories）で管理UI/APIから顧客情報・設定を閲覧・取得します。
  • アプリ設定変更やアカウント操作など、機密性に加えて完全性・可用性に波及する不正操作に発展します。
  • 多地域展開のSaaSでは、地域境界やテナント境界の越境リスクが累積します。

運用面の波及です。

• 認証基盤に問題があると誤認し、不要な大規模ロールバックやキー・トークン総入れ替えに踏み込むリスクがあります。まずはヘッダー注入の有無とミドルウェア実行経路の観測で切り分けることが重要です。
• セキュリティゲートがミドルウェア一枚に依存している設計では、脆弱性露呈時に代替経路がなく、セーフモード移行が難しくなります。フェイルセーフの設計が問われます。

セキュリティ担当者のアクション

一次アドバイザリの公開とパッチ適用を待つだけでは侵害リスクを下げきれない可能性があるため、次を並行して進めることをおすすめします。

1. インベントリとエクスポージャの即時可視化です。

• SBOMやSCAでNext.jsのバージョンを棚卸しし、11.1.4〜15.2.2相当が残っていないか洗い出すです。
• モノレポ・マイクロフロントエンド環境では、各パッケージのlockfileとビルドイメージ内の実体を二段で確認するです。

2. パッチ適用と回帰防止です。

• 公式アドバイザリで修正バージョンを確認次第、段階的にロールアウトするです。
• E2Eテストに「内部ヘッダーを付与しても401/403が維持されること」を追加し、将来の回帰検知を自動化するです。

3. 境界での暫定コントロール（即日）です。

• WAF/リバースプロキシで、クライアントから到来する“x-middleware-”“x-nextjs-”“x-vercel-*”など内部用と思しきヘッダーをドロップするです。
  • 例: “ヘッダー名が x-middleware- で始まる”を条件にブロック/除去するです。
• 反対に、アプリ層では“内部用ヘッダーは受信しても無視する”ロジックにしておくのが望ましいです。

4. ログ監査とハンティングです。

• 重点観測項目です。
  • 管理系/内部APIパス（/admin, /internal, /api/private など）への未認証ユーザーの200応答増加です。
  • 単一クライアントからの401/403→200への推移、および同一UA/同一IPでの“x-middleware-*”系ヘッダー出現です。
  • 地域制限対象国からのアクセスで地域判定ロジックが動いていない兆候（通常は403→今回は200）です。
• 具体的なハンティングの切り口です。
  • WAF/ALB/リバースプロキシのヘッダーログで、“x-middleware-”前方一致を含むリクエストの頻度・成功率・対象パスを抽出するです。
  • アプリログで“middleware executed”などの計測ポイントがあれば、実行スキップの割合を期間比較するです。

5. 権限・認可の二重化です。

• 認証・認可をミドルウェアだけに依存させず、APIハンドラ/サーバーアクション側にも最小限の認可チェックを実装するです。
• リスクの高い操作（設定変更、支払い情報更新など）には追加のサーバーサイドトークン検証や再認証を求めるです。

6. フレームワーク外側の堅牢化です。

• ルータ/ゲートウェイ層で“信頼するヘッダー”を明示的にホワイトリストし、それ以外のカスタムヘッダーは後段に渡さない方針にするです。
• CDN・エッジ（Cloudflare/Akamai等）のTransform/Rewrite機能で内部用ヘッダーを剥離し、必要ならば境界内で再注入するです。

7. コミュニケーションと備えです。

• 開発・SRE・SOCの三者で、検知→封じ込め→是正→検証のプレイブックを共有し、監視ダッシュボードに“内部ヘッダー到来率”のウィジェットを追加するです。
• 顧客影響が疑われる場合に備え、事後通知テンプレートとQ&Aを準備するです。

最後に、この件は単なるパッチ適用の話ではなく、「内部プロトコル（ヘッダー）をパブリック境界で露出させない」ことの重要性を改めて示しています。フレームワークの便利さと、ゼロトラストの原則をどう両立するか——その設計思想が問われている案件です。一次アドバイザリの公開を待ちながらも、できる対策は今日から着実に進めていきたいところです。

参考情報

• セカンダリソース: Security Boulevard – CVE-2025-29927解説です。https://securityboulevard.com/2026/01/cve-2025-29927-understanding-the-next-js-middleware-vulnerability-2/ です。
• 一次情報の確認先（恒常ページ）:
  • Next.js Security Advisories（GitHub）: https://github.com/vercel/next.js/security/advisories です。
  • Vercel Security: https://vercel.com/security です。
  • MITRE CVE: https://cve.mitre.org/ です。

注記: 個別CVEの一次アドバイザリや修正コミットのURLは、公開確認後に更新する前提で参照ください。現時点の技術的要点と対策は、フレームワーク一般に通用する信頼境界の原則に基づいています。