はじめに：Next.jsを使っているあなたへ

いつもNext.jsで素晴らしいユーザー体験を構築されている日本のフロントエンドエンジニアの皆さん、こんにちは。今回は、Next.jsのServer Actionsに関する重要なセキュリティ脆弱性（GHSA-89xv-2m56-2m9x / CVE-2026-64649）についてお伝えします。この脆弱性は深刻度 'high' と評価されており、特にカスタムサーバーでNext.jsを運用している場合に影響を受ける可能性があります。ご自身のアプリケーションが危険にさらされていないか、そしてどのように対策すべきか、本記事で詳しく見ていきましょう。

脆弱性の概要：Server ActionsにおけるSSRFとは？

今回の脆弱性は「Server-Side Request Forgery (SSRF)」、日本語では「サーバーサイド・リクエスト・フォージェリ」と呼ばれます。これは、攻撃者がサーバーに対して、任意のURLへのリクエストを強制的に実行させる攻撃手法です。通常、サーバーは自身が信頼するエンドポイントにのみリクエストを送信しますが、SSRF脆弱性があると、攻撃者の指定した悪意のあるホストへリクエストを送信させられてしまいます。

Next.jsのServer Actionsにおいてこの問題が発生するのは、Server Actionがリクエストの転送（forward）やリダイレクト（redirect）を行う際に、攻撃者が意図的に細工した `Host` や `X-Forwarded-Host` といったヘッダーを信頼してしまうことに起因します。これにより、サーバーが本来アクセスすべきではない内部リソース（例：内部API、クラウドプロバイダーのメタデータエンドポイントなど）や、攻撃者が用意した外部ホストにリクエストを送信する可能性が生じます。最悪の場合、内部の値の取得や、ミドルウェア/プロキシ認証の回避につながる恐れもあります。

影響を受けるアプリケーションと環境

この脆弱性の影響を受けるのは、以下の条件に合致するNext.jsアプリケーションです。

1. **Server Actions を使用していること**: アプリケーションでServer Actionsを利用している場合が対象です。

2. **カスタムサーバーで運用していること**: `next start` コマンドでそのまま起動しているのではなく、Node.jsなどのランタイム上で独自のサーバーコードを記述してNext.jsアプリケーションをホストしている環境（例：`node server.js`）が特に危険です。これらの環境では、流入する `Host` ヘッダーが信頼できる値に固定されていないケースが多く見られます。

3. **プロキシの後ろにないデプロイメント**: プロキシ（Nginx, Cloudflareなど）を介さずに直接Next.jsアプリケーションが外部に公開されている場合も影響を受けやすくなります。プロキシが`Host`ヘッダーを適切に固定していれば、ある程度の緩和が期待できます。

公式のマネージドホスティングサービス（Vercelなど）や、Next.js 14.2以降の `next start` コマンドおよびスタンドアロン出力では、デフォルトでHostヘッダーが適切に処理されるため、この脆弱性の影響は受けにくいとされています。

具体的な対策：あなたのNext.jsアプリを守るために

この脆弱性からアプリケーションを保護するために、以下のいずれかの対策を速やかに実行してください。

最も推奨される対策は、Next.jsを脆弱性が修正された最新バージョンにアップグレードすることです。特にバージョン14.2以降では、`next start` やスタンドアロン出力でこの問題が緩和されています。常に最新のセキュリティパッチが適用されたバージョンを利用することが、セキュリティを維持する上で最も効果的です。

すぐにアップグレードできない場合でも、クライアントからの `Host` ヘッダーを信頼しないようにすることが非常に重要です。エッジサーバーやプロキシ（Nginx, Apache HTTP Server, クラウドのロードバランサーなど）で、流入する `Host` および `X-Forwarded-Host` ヘッダーを信頼できる値に固定するか、厳しく検証する設定を行ってください。

例えば、Nginxを使用している場合、以下のような設定で `Host` ヘッダーを上書きできます（例: `proxy_set_header Host example.com;`）。ご自身のインフラ構成に合わせて適切な設定を行ってください。

Next.jsのバージョン14.2.0以降であれば、`__NEXT_PRIVATE_ORIGIN` 環境変数を設定することで、サーバーの実際のオリジンを明示的に指定できます。これにより、Server Actionsが不正な `Host` ヘッダーに惑わされるのを防ぐことができます。あなたのデプロイメントの実際のオリジン（例: `https://www.example.com`）を設定してください。

設定例:

`__NEXT_PRIVATE_ORIGIN=https://www.example.com node server.js`

まとめ：セキュリティは継続的な取り組み

今回のNext.jsのSSRF脆弱性は、Webアプリケーションのセキュリティにおいて、サーバーサイドでのリクエスト処理がいかに重要であるかを改めて示しています。特にカスタムサーバーでNext.jsを運用しているフロントエンドエンジニアの皆さんは、速やかに上記の対策を実施し、アプリケーションを保護してください。

フレームワークやライブラリを利用する上で、セキュリティ情報を常にチェックし、適切なタイミングでアップデートや設定の見直しを行うことは不可欠です。本記事が、皆さんのNext.jsアプリケーションのセキュリティ向上の一助となれば幸いです。