Next.js の高危険度 SSRF 脆弱性 CVE-2026-44578：影響範囲とアップグレード方針

Next.js は 2026 年 5 月、高危険度の SSRF 脆弱性 CVE-2026-44578 を公開しました。

GitHub / Vercel のセキュリティアドバイザリ GHSA-c4j6-fc7j-m34r と NVD の記録によると、この脆弱性は、内蔵 Node.js server を使い、悪意ある WebSocket upgrade リクエストを受け取れる状態にある自己ホスト型 Next.js アプリケーションに影響します。攻撃者はサーバーに任意の内部または外部宛先へリクエストを代理送信させ、内部サービスやクラウド metadata エンドポイントを露出させる可能性があります。

Vercel 上でホストされているデプロイは影響を受けません。修正バージョンは 15.5.16 と 16.2.5 です。

先に結論

自前サーバー、コンテナ、Kubernetes、ECS、VPS、ベアメタル、または自己管理 PaaS で Next.js を自己ホストしている場合は、優先的に確認してください。

影響を受ける範囲：

next >= 13.4.13 < 15.5.16
next >= 16.0.0 < 16.2.5

影響を受けない、またはリスクが低いケース：

Vercel にデプロイしているアプリケーション。
15.5.16、16.2.5、またはそれ以降へアップグレード済み。
内蔵 Node.js server を外部に公開していない構成。
リバースプロキシやロードバランサーで不要な WebSocket upgrade をすでに遮断し、アウトバウンドアクセスも制限している環境。

推奨対応順：

本番環境で実際に動いている next バージョンを確認する。
自己ホスト型アプリをできるだけ早く修正版へアップグレードする。
すぐにアップグレードできない場合は、リバースプロキシまたはロードバランサーで不要な WebSocket upgrade を遮断する。
アプリケーションサーバーからクラウド metadata、内部管理画面、機密性の高い内部サービスへのアクセスを制限する。
直近の異常な WebSocket upgrade リクエストと内部アクセスログを確認する。

脆弱性の内容

CVE-2026-44578 は Server-Side Request Forgery、つまり SSRF の脆弱性です。

SSRF の本質的なリスクは、攻撃者が内部システムへ直接アクセスするのではなく、あなたのサーバーに代理でリクエストを送らせる点にあります。サーバーは通常、内部ネットワーク、クラウド基盤、内部サービスに近い場所にあるため、代理として使われると、攻撃者が本来アクセスできないリソースに届く可能性があります。

今回の Next.js の問題は WebSocket upgrade の処理経路にあります。アドバイザリによると、内蔵 Node.js server を使う自己ホスト型アプリケーションでは、細工された WebSocket upgrade リクエストにより、サーバーが任意の内部または外部宛先へ代理アクセスする可能性があります。

リスクのある対象は次のようなものです。

内部 HTTP サービス。
管理画面。
クラウド metadata アドレス。
コンテナまたはクラスタ内部のサービス。
サーバーからのみアクセスできる内部 API。

この脆弱性の CVSS v3.1 スコアは 8.6 High で、ベクトルは次の通りです。

1

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

これは、ネットワーク経由で攻撃可能、攻撃複雑度は低く、権限もユーザー操作も不要で、主に機密性に影響することを意味します。

自己ホストが危険になりやすい理由

今回のアドバイザリは、Vercel-hosted deployments are not affected と明記しています。

重点的に見るべきなのは自己ホスト型デプロイです。理由は単純で、自己ホスト環境のネットワーク構成はさまざまだからです。origin server を直接公開しているものもあれば、Nginx、Traefik、Ingress、Cloudflare、ALB、自前ゲートウェイの背後にあるものもあります。クラウド VM、コンテナネットワーク、Kubernetes クラスタで動く場合もあります。

これらの環境でアウトバウンドアクセスが制限されていない場合、Next.js プロセスは次のものに到達できる可能性があります。

169.254.169.254 のようなクラウド metadata アドレス。
プライベート IP 範囲。
VPC 内だけで公開されているサービス。
Redis、Elasticsearch、Prometheus、Grafana などの内部コンポーネント。
Kubernetes Service、Pod、管理エンドポイント。

つまり SSRF の危険性は Next.js だけで決まるものではありません。その Next.js サーバーがいるネットワークから何にアクセスできるかで決まります。

影響を受けるか確認する方法

最初に next のバージョンを確認します。

プロジェクトディレクトリで実行します。

1

npm ls next

または：

1

pnpm why next

直接確認することもできます。

1
2
3
4


cat package.json
cat package-lock.json
cat pnpm-lock.yaml
cat yarn.lock

バージョンが次の範囲に入る場合は対応が必要です。

1
2


>= 13.4.13 < 15.5.16
>= 16.0.0 < 16.2.5

次に、デプロイ方式を確認します。

特に注意すべき構成：

next start で本番サービスを起動している。
カスタム Node.js server で Next.js をホストしている。
Docker イメージ内で Next.js server を直接起動している。
Kubernetes / ECS / VPS / ベアメタルで自己ホストしている。
リバースプロキシの背後にある Next.js origin がなお到達可能。
アプリケーションのネットワークから内部サービスやクラウド metadata にアクセスできる。

アプリケーションが Vercel にデプロイされている場合、この脆弱性の影響は受けないと公式アドバイザリは述べています。ただし、同じリリース群に他の修正が含まれる可能性があるため、Next.js は常に更新しておくべきです。

どのバージョンへ上げるべきか

公式の修正バージョンは次の通りです。

15.5.16
16.2.5

アップグレード例：

1

npm install next@15.5.16

16.x を使っている場合：

1

npm install next@16.2.5

pnpm：

1

pnpm add next@15.5.16

または：

1

pnpm add next@16.2.5

アップグレード後、再ビルドしてリリースします。

1
2


npm run build
npm run start

または、CI/CD に沿って Docker イメージを再ビルドし、再デプロイしてください。

プロジェクトが 14.x または 15.x に固定されている場合、この修正のためだけに慌てて 16.x へメジャーアップグレードする必要はありません。まず 15.5.16 の修正ラインへ上げ、テストとリリースを完了し、その後でメジャーバージョン移行を計画するほうが安全です。

一時的な緩和策

すぐにアップグレードできない場合、アドバイザリの中心的な方針は次の通りです。origin server を信頼できないネットワークに直接公開しないこと。WebSocket upgrade が不要ならリバースプロキシまたはロードバランサーで遮断すること。そして可能な限り origin のアウトバウンドアクセスを制限することです。

検討できる緩和策：

Next.js origin server を直接公開しない。
Nginx、Ingress、ALB、Cloudflare などの入口層で不要な WebSocket upgrade をフィルタする。
業務で WebSocket を使っていない場合、upgrade セマンティクスを持つリクエストを拒否する。
アプリケーションサーバーに egress 制限をかけ、クラウド metadata アドレスと機密性の高い内部ネットワークへのアクセスを禁止する。
クラウド基盤が提供するより安全な metadata アクセス方式、たとえば token 必須の metadata サービスを有効化する。
管理画面、データベース、キャッシュ、監視システムに認証とネットワーク分離を追加する。

リバースプロキシ規則は一時的な緩和策であり、アップグレードの代替ではありません。フレームワークの脆弱性は最終的に修正版で解決すべきです。

運用上の確認ポイント

この脆弱性は主に機密性に影響するため、確認の中心は「内部リソースへのアクセスに使われたか」です。

確認すべきもの：

Web アクセスログ中の異常な Upgrade、Connection、Host、パス、送信元 IP。
リバースプロキシまたはロードバランサーの異常な WebSocket upgrade ログ。
Next.js サービス周辺の異常なアウトバウンド接続。
クラウド metadata サービスへのアクセスログや認証情報の使用記録。
内部管理サービス、監視システム、キャッシュ、検索サービスへの異常アクセス。
IAM 一時認証情報、アクセスキー、token の異常使用。
コンテナまたはホスト上の不審なプロセス、ダウンロード、横展開の痕跡。

悪用が疑われる場合：

ログと証跡を保全する。
露出した可能性のあるクラウド認証情報、API key、データベースパスワード、session secret をローテーションする。
クラウドアカウントの直近 API 呼び出しを確認する。
内部サービスのアクセス記録を確認する。
影響を受けたコンテナまたはホストを再構築する。
egress 制御と metadata 保護を再確認する。

React/Next.js RCE とは別の問題

混同しやすい点として、CVE-2026-44578 は Next.js WebSocket upgrade SSRF であり、以前の React Server Components 関連 RCE ではありません。

この問題の中心は、攻撃者が指定した内部または外部アドレスへサーバーにリクエストを送らせることです。主なリスクは情報漏えいと内部リソースの探索です。

一方、React Server Components 関連の RCE はコード実行リスクであり、影響や修正範囲が異なります。

そのため「Next.js に脆弱性がある」という大見出しだけで判断せず、具体的な CVE、影響バージョン、デプロイ方式、修正バージョンを対応させる必要があります。

優先対応すべきチーム

最優先で対応すべき環境：

自己ホスト型 Next.js 本番サイト。
クラウド VM、コンテナ、Kubernetes、内部ネットワークで動作する環境。
アプリケーションサーバーがクラウド metadata サービスへアクセスできる環境。
アプリケーションサーバーが内部管理画面、データベース、キャッシュ、監視システムへアクセスできる環境。
next start origin server を直接公開している環境。
古い next を使っており、アップグレード担当が明確でない環境。

相対的に優先度が低い環境：

完全に Vercel へデプロイされているアプリケーション。
すでに修正版へアップグレード済みのアプリケーション。
origin server が直接公開されておらず、入口層で不要な WebSocket upgrade を遮断している環境。
アウトバウンドネットワークが厳格に制御され、機密性の高い内部リソースへ到達できない環境。

ただし「優先度が低い」は「アップグレード不要」という意味ではありません。Next.js は露出度の高いフレームワークであり、古いバージョンを長く使うほどリスクは積み上がります。

開発チーム向けチェックリスト

次のチェックリストで対応できます。

すべてのリポジトリの next バージョンを確認する。
Vercel プロジェクトだけでなく、すべての自己ホスト型デプロイを洗い出す。
next start または内蔵 Node.js server を使うサービスを特定する。
15.5.16、16.2.5、またはそれ以降へアップグレードする。
本番イメージを再ビルドして公開する。
入口層で不要な WebSocket upgrade を遮断する。
アプリケーションサーバーからクラウド metadata と機密性の高い内部ネットワークへのアクセスを制限する。
直近の異常な upgrade リクエストとアウトバウンドアクセスを確認する。
露出した疑いのある認証情報をローテーションする。
Next.js のセキュリティ更新を依存関係更新プロセスに組み込む。

まとめ

CVE-2026-44578 は、真剣に対応すべき Next.js の高危険度 SSRF 脆弱性です。

Vercel ホストのデプロイには影響しませんが、自己ホスト型 Next.js アプリには広く影響します。対象は 13.4.13 から 15.5.16 未満、そして 16.0.0 から 16.2.5 未満です。トリガーは WebSocket upgrade の処理経路であり、攻撃者はサーバーに内部または外部アドレスへ代理アクセスさせ、内部サービスやクラウド metadata エンドポイントを露出させる可能性があります。

直接的な修正は 15.5.16 または 16.2.5 へのアップグレードです。一時緩和としては、origin server を直接公開しないこと、不要な WebSocket upgrade を遮断すること、アプリケーションサーバーのアウトバウンドアクセスを制限することが挙げられます。

運用チームにとって重要なのは CVE スコアだけではありません。あなたの Next.js サーバーが、そのネットワーク位置から何にアクセスできるかです。SSRF の実際の影響は、サーバーの背後にある内部リソースとクラウド権限に左右されます。

参考リンク：