Next.jsの脆弱性CVE-2025-29927まとめ

本記事の文章表現の一部には、生成AI(Google Gemini)を用いた校正・改善を行っています。ただし、掲載されている情報の正確性については筆者自身が責任をもって確認・執筆しています。AIの力を借りながらも情報の信頼性を最優先にしていますので安心してお読みいただければ幸いです。

1. 概要

CVE-2025-29927 は、Next.js (ReactベースのフルスタックWebフレームワーク) における 認可バイパスの脆弱性 です。特にNext.jsの ミドルウェア (middleware) で認可チェックを行っている場合に、攻撃者が細工したHTTPヘッダーを送信することで認可を迂回できる深刻な欠陥となっています。この脆弱性により、本来認可が必要な 保護リソース へ攻撃者が未認証のままアクセスできる可能性があります。脆弱性の深刻度はCritical (重大) と評価されており、CVSSスコアは9.1 (Critical)^[1] と報告されています。

この問題は2025年3月中旬に公表され、Next.js開発元のVercelにより速やかに修正が行われました。GitHubのセキュリティアドバイザリによれば、本件はセキュリティ研究者cold-try氏およびAllam Rachid, Allam Yasser各氏によって報告されたものです。脆弱性の報告後、わずか数日で修正版がリリースされており、Next.jsチームの迅速な対応が見られます。現時点で本脆弱性を悪用した大規模な攻撃の報告はありませんが、技術的詳細が公開されていることから、潜在的なリスクは非常に高いといえます。

2. 影響範囲

Next.jsを利用する全てのwebアプリケーション のうち、以下のバージョンが本脆弱性の影響を受けます^[2][3]:

• Next.js 15.x 系: 15.2.2 以前 (修正は 15.2.3 にて提供)
• Next.js 14.x 系: 14.2.24 以前 (修正は 14.2.25 にて提供)
• Next.js 13.x 系: 13.5.8 以前 (修正は 13.5.9 にて提供)
• Next.js 12.x 系: 12.3.4 以前 (修正は 12.3.5 にて提供)

影響範囲には公式の安定版リリースだけでなく、一部のリリース候補版 (rc) やカナリア版 (canary) も含まれています。基本的に Next.js 15.2.3, 14.2.25, 13.5.9 および 12.3.5未満の全て が該当すると考えて良いでしょう。
本脆弱性はNext.jsフレームワーク自体の問題であるため、アプリケーションのホスティング環境 (Node.jsのバージョンやOS) に依存せず再現します。特に Next.jsのMiddleware機能 を使用して 認証・認可チェック を行っているアプリケーションが危険にさらされます。ミドルウェア内でヘッダー値の検証をせずにアクセス制御を実装している場合、脆弱性の影響を強く受けます。

3. 脆弱性の技術的背景 (原因)

根本原因 は、Next.jsのミドルウェア処理において 特定の内部ヘッダーx-middleware-subrequestに対する検証が不十分 だったことです。Next.jsではミドルウェア間の内部通信や再リクエストの制御にこのx-middleware-subrequestヘッダーを使用していますが、脆弱なバージョンでは 外部からこのヘッダーを指定されても遮断せずに信頼 してしまう実装になっていました^[4]。本来、ミドルウェアは各リクエストをインターセプトして認証・認可などのセキュリティポリシーを適用します。しかし、攻撃者がリクエストにこのヘッダーを付与すると、Next.jsは「これは内部サブリクエストである」と誤認し、認可チェック用のミドルウェアをスキップして後続処理へ進めてしまう のです。結果として、認可が必要なはずの処理が行われないまま、リソースへのアクセスが許可されてしまいます。

もう少し技術的に補足すると、Next.jsでは本来内部でミドルウェアを経由した再リクエスト時にx-middleware-subrequestヘッダーをセットし、無限ループの防止や再実行の抑制に用いています。例えば、認可ミドルウェアが未認証ユーザをログインページにリダイレクトする際、再リクエストにはこのヘッダーが付与され、同じミドルウェアを二度適用しない仕組みが考えられます。しかし脆弱な実装では、外部から来たリクエストでもこの内部フラグを盲信 してしまい、「既にミドルウェア処理済み」とみなして 本来行うべき認可チェックを省略していたと推測されます。これはまさに 認可ロジックの不備 (CWE-285 Improper Authorization) に該当し、ソフトウェアがリソースアクセス時の認可チェックを正しく実施していない状況です^[5]。

以上の原因により、Next.jsミドルウェアに依存したセキュリティ機構 (認可) は、特定ヘッダーの細工という非常に単純な手口で破られてしまう状態となっていました。

4. 攻撃者による悪用方法

攻撃者が本脆弱性を悪用する方法は極めて単純かつ強力 です。攻撃者は標的のNext.jsアプリケーションに対し、x-middleware-subrequestヘッダーを含むHTTPリクエストを送信する だけで、ミドルウェアによる認可チェックを回避できます。具体的な攻撃シナリオを以下に示します。

• 被害サイト: https://vulnerable-app.com (Next.js製アプリ)
• 保護リソース: /protected-route (通常はログインユーザのみアクセス許可)
• 通常の挙動: 未認証ユーザがアクセスするとミドルウェアで検知され、401エラーやログインページへのリダイレクトとなる。

脆弱性を悪用したリクエストの例 (攻撃者が送信するHTTPリクエスト):

GET /protected-route HTTP/1.1
Host: vulnerable-app.com
x-middleware-subrequest: middleware

上記のように、特定のミドルウェア名 (例えばmiddlewareやsrc/middleware) を指定することで、認可ミドルウェアをスキップ し、そのまま/protected-routeの保護リソースを返却してしまいます。その結果、攻撃者は認証情報を一切持たなくても、HTTP 200 OK で本来アクセス不可能なデータを取得できてしまいます。

この攻撃は ネットワーク経由でリモートから実行可能 であり、特別な前提条件やユーザ操作も不要です^[5:1]。攻撃者はWebブラウザの開発者コンソールやcurl、各種HTTPクライアントツールを用いてヘッダーを付与したリクエストを送るだけで脆弱性を突けます。必要な権限も無く (未認証でOK) 、攻撃の複雑さも低いため、非常に再現性の高い攻撃手法と言えます^[5:2]。実際、本脆弱性のCVSS評価でも「攻撃に必要な権限: なし」「ユーザ操作要求: なし」「攻撃条件の複雑さ: 低」とされており、誰でも容易に攻撃を成立させられることが示されています。なお、記事執筆時点で公表されているProof-of-Concept (PoC) コードは存在しません(見つけられませんでした)が、上述のHTTPリクエスト例だけで十分再現可能であるため、PoCが無くとも注意が必要です。

5. 修正内容 (パッチの詳細)

Next.js開発チームは、本脆弱性に対して ソースコードレベルでの修正パッチ をリリースしました。修正は2025年3月17~23日付で行われ、Next.js 15.2.3, 14.2.25, 13.5.9 および 12.3.5 に組み込まれています。修正内容の要点は、外部から送信されたx-middleware-subrequestヘッダーを無効化する ことです。具体的には、Next.js内部で 「サブリクエストID (x-middleware-subrequest-id)」 と呼ばれるランダムな識別子を導入し、正規のミドルウェア内部処理ではそのIDを付加するように変更しました。そして、受け取ったリクエストのヘッダー中にx-middleware-subrequestが存在する場合は、この識別子と照合します。識別子が一致しない (=外部から恣意的に付与されたヘッダーだと判定できる) 場合、当該x-middleware-subrequestヘッダーを削除して以降の処理を行うようになりました。これにより、攻撃者が偽のヘッダーを注入してもNext.jsが内部リクエストと誤認することはなくなり、ミドルウェアによる認可チェックが確実に実行されるようになります。

また、Next.js公式のセキュリティアドバイザリおよびコミットログには、テストコードの追加も含まれています。修正後のバージョンでは、意図しないヘッダー付きリクエストが適切に処理 (遮断または無視) されることを検証するテストが追加されました。これにより再発防止を図っています。

なお、アップグレードできず旧バージョンを使用しなくてはならない場合は 利用者自身で防御策を講じる必要 があります(次節参照)。公式の勧告でも、パッチ適用が困難な場合は 外部から該当ヘッダーを含むリクエストがアプリケーションに到達しないよう防御せよ と明記されています。

6. 推奨される対応策

本脆弱性に対処するために、以下の対応策が推奨されます。

• 短期的対応策 (ワークアラウンド): Next.jsミドルウェア内での検知はバイパスされる恐れがある^[6]ため、すぐにアプリケーション側で実施できる対策としてリバースプロキシ (NGINX, Cloudflareなど) で当該ヘッダーを除去または遮断することが有効です。

• 長期的対応策 (恒久的な修正): 根本的な解決策は、Next.js自体を修正済みのバージョンにアップデートすること です。可能な限り早急にNext.jsを 15.2.3以降 (14~12系も同様にパッチ済みバージョン以降) へアップグレードしてください。アップデートにより、内部で今回の脆弱性が解消されるとともに、今後新たに報告されたセキュリティ改善も取り込まれます。特に認可や認証といった重要機能をミドルウェアに依存している場合、アップデートは不可欠です。加えて、依存パッケージの更新 (例: npm update) やnext audit等で関連脆弱性がないかチェックすることも推奨します。

• 追加のセキュリティベストプラクティス: 今回の問題を教訓に、信頼境界を越えて送信されるヘッダーの扱い には十分注意しましょう。Next.jsのようにフレームワーク内部で利用する特殊なヘッダーについては、外部から送信されても無視・除去するのが原則です。必要に応じてWAF（Webアプリケーションファイアウォール）を導入し、不審なヘッダーや一般的でないリクエストパターンをブロックするルールを整備してください。また、ミドルウェアによる認可チェックに限らず、重要なセキュリティ検証はアプリケーション内の複数箇所で冗長に行う (Defense in Depth, 多層防御) ことも検討すべきです。

• 検出方法 (脆弱性悪用のモニタリング): 自社のアプリケーションが本脆弱性の影響を受ける場合、攻撃の痕跡を監視・検出 する体制も構築しておくべきです。具体的には、サーバのアクセスログもしくはアプリケーションのリクエストログを解析し、x-middleware-subrequestヘッダーを含むリクエストが無いか定期的にチェックします。例えば、以下のようなログエントリが検出対象となります。

  203.0.113.50 - - "GET /protected-route HTTP/1.1" 200 ･･･ "x-middleware-subrequest: middleware"
  

  上記のように、未認証の状態で保護リソースに200番台の応答 が返っており、かつヘッダーにx-middleware-subrequestが見られる場合、攻撃試行の可能性があります。ログ監視には自動アラートを設定し、このパターンを検知した際にセキュリティ担当者へ通知する仕組みを導入すると良いでしょう。さらに脆弱性公表前のログについても遡及調査し、過去に同様のアクセスが無かったか確認しておくことで、潜在的な被害の有無を評価できます。

追記: ローカル環境で試せるデモを作成しました。
https://github.com/t3tra-dev/cve-2025-29927-demo

脚注

1. 後述するSnykのレポート等では9.3となっていますが、ここではGitHubのアドバイザリを元に9.1と示しています。

2. CVE-2025-29927 | Next.js #Timeline

3. CVE-2025-29927 | Next.js #Patched versions

4. Improper Authorization in next | CVE-2025-29927 | Snyk

5. CVE-2025-29927 vercel Next.js Header improper authorization (GHSA-f82v-jwr5-mffw)

6. Next.js version 15.2.3 has been released to address a security vulnerability | Hacker News