Next.js CVE-2026-44578：WebSocket SSRF（CVSS 8.6）の仕組みと自己ホスト向け緊急対策

Vercelが2026年5月6日に公開したCVE-2026-44578（GHSA-c4j6-fc7j-m34r）は、自己ホストのNext.jsサーバーに対して認証不要で内部HTTPリクエストを発行させられるSSRF（Server-Side Request Forgery）脆弱性だ。CVSSスコアは8.6（High）で、攻撃者はWebSocketアップグレードリクエストを細工することでNext.jsサーバを踏み台にし、AWS IMDSv2・Kubernetes SAトークン・内部APIなどクラウド環境の機密情報を窃取できる可能性がある。

影響を受けるのは自己ホスト環境のみで、Vercel管理のデプロイメントは影響を受けない。セキュリティ研究者dwisiswant0によるPoC（概念実証コード）が既に公開されており、脆弱性の悪用ハードルは低い状態にある。

セキュリティ脆弱性の全体的な管理・防御アプローチについてはサプライチェーンセキュリティ完全ガイド2026｜攻撃手法・防御ツール・実践チェックリストをご覧ください。

CVE-2026-44578とは：WebSocket SSRF が自己ホストNext.jsを踏み台にする仕組み

CVE-2026-44578のポイントは「通常のHTTPリクエストには存在する内部宛先へのリクエスト検証が、WebSocketアップグレード処理にはなかった」という一点に尽きる。

Next.jsがNode.jsのビルトインサーバー（next start や node server.js）で動作するとき、サーバーはHTTP/1.1 Upgradeリクエストを受け取る経路を持っている。通常のHTTPリクエストについては、外部からの不正なURLターゲットを弾くチェックが実装されている。しかしWebSocketへのアップグレードを処理するコードパスでは、この安全検証が適用されていなかった。

攻撃者が送る細工済みリクエストは概念上、次のような形を取る。

GET / HTTP/1.1
Host: target-app.example.com
Upgrade: websocket
Connection: Upgrade
X-Forwarded-For: 127.0.0.1
[細工されたターゲットアドレス]

Next.jsサーバーはこのリクエストを受け取ると、WebSocketアップグレード処理のコードパスを通じてリクエストを内部的にプロキシしようとする。このときターゲットアドレスのバリデーションが不十分なため、攻撃者はサーバー自身が任意のHTTP宛先へリクエストを発行する状態を作り出せる。

なぜ「自己ホスト限定」なのか

Vercel管理環境では、WebSocketアップグレードリクエストはNext.jsアプリのNode.jsプロセスが直接処理するのではなく、Vercelのエッジインフラ層が先に受け取り処理する。このインフラ層がリクエストの正規化・検証を担当するため、脆弱なNext.jsコードパスには到達しない設計になっている。

自己ホスト環境（Node.jsサーバー直接公開・Docker・Kubernetes・AWS Amplify・Render等）ではNext.jsのNode.jsプロセスが直接インターネットと向き合うか、リバースプロキシからUpgradeヘッダーをそのままNext.jsに転送する構成が多い。この場合、脆弱なコードパスに攻撃者が到達できる。

CVSS 8.6の内訳

CVSSv3.1での評価は以下の通り。

「認証不要・ネットワーク経由・攻撃複雑度低」の三拍子が揃い、CVSS 8.6（High）という評価に至っている。Critical（9.0以上）には届かないが、PoC公開済みの現状では理論値ではなく実際の攻撃リスクとして扱う必要がある。

攻撃が成立する条件

すべての自己ホスト環境が無条件に危険というわけではない。実被害に至るには以下の条件が揃う必要がある。

Nginx等のリバースプロキシを介している場合も、WebSocket Upgradeをそのままバックエンドに転送する設定（proxy_pass + proxy_http_version 1.1 + proxy_set_header Upgrade $http_upgrade）がデフォルト的に使われるため、ほとんどの自己ホスト構成で攻撃ベクトルが有効だ。

影響バージョンと修正版：Next.js 15.5.16 / 16.2.5へ即時アップグレード

修正版は15.5.16/16.2.5だが、Turbopackを使用している場合は15.5.18/16.2.6まで上げる必要があるというのが重要な注意点だ。

なお、5月7日公開のGHSA-26hh-7cqf-hhc6（CVE-2026-44575のTurbopackミドルウェア向け不完全修正フォローアップ）への対応も含めると、最終的に当てるべき推奨バージョンは15.5.18 / 16.2.6だ。CVE-2026-44578の修正だけを目的とするなら15.5.16/16.2.5で十分だが、どうせ更新するなら最新まで上げるほうが効率的だ。

バージョン確認と更新コマンド

# 現在のバージョン確認
node -e "const p=require('./node_modules/next/package.json');console.log(p.version)"
# または
cat node_modules/next/package.json | grep '"version"' | head -1

# npm (16系へ更新)
npm update next@^16.2.6

# pnpm (16系へ更新)
pnpm up next@^16.2.6

# yarn (16系へ更新)
yarn up next@^16.2.6

# 15系に留まる場合
pnpm up next@^15.5.18

# 更新後の確認
node -e "const p=require('./node_modules/next/package.json');console.log('Next.js:', p.version)"

monorepoでは packages/ 配下や apps/ 配下に複数の next が存在しうる。pnpm why next（npmなら npm ls next）で間接依存を含めた全インスタンスを確認することが重要だ。

# 全ワークスペースのnextバージョンを確認
pnpm why next --recursive 2>/dev/null || npm ls next --all 2>/dev/null

ホスティング環境別の影響サマリ

自己ホストかどうかが唯一の分岐点だ。環境別に整理する。

Kubernetes環境では特にリスクが高い。Next.jsサーバーがPodとして動作している場合、SSRFを経由してAWS/GCP/Azureのインスタンスメタデータサービスや、Kubernetesサービスアカウントのトークンエンドポイント（169.254.169.254や10.96.0.1等）に到達できる可能性がある。IAMロールが付与されたサービスアカウントであれば、クラウド全体への横移動の起点になりうる。

攻撃フローの図解：WebSocket SSRF が内部クレデンシャルを盗む経路

攻撃者は認証なしの単一リクエストで、Next.jsサーバーを踏み台にして内部のメタデータサービスやAPIサーバーへリクエストを発行させられる——というのが本脆弱性の要点だ。

通常HTTPとWebSocketアップグレードの検証差

通常のHTTPリクエストでは、Next.jsの内部ルーティングは外部から到達できない内部エンドポイントへのリクエストを適切に拒否する。しかしWebSocket Upgradeのコードパスではこの検証が存在しなかった——という非対称性が本脆弱性の本質だ。

修正（15.5.16 / 16.2.5）では、WebSocketアップグレード処理においても通常HTTPリクエストと同等のセーフティ検証が適用されるよう変更された。具体的には、Upgradeリクエストのターゲットアドレスが内部ネットワーク・ループバック・メタデータサービスのアドレスレンジに属するかどうかをチェックする処理が追加されている。

SSRF経由で窃取できる情報の例

クラウド環境で特に危険なのは、インスタンスメタデータサービス（IMDS）へのアクセスだ。

GCPでは metadata.google.internal 経由でサービスアカウントのアクセストークンを取得でき、Azureでは 169.254.169.254/metadata/identity/oauth2/token からManaged Identity トークンが取得できる。いずれもクラウドプラットフォーム全体への横移動の起点になりうる深刻な情報だ。

PoC公開済み：dwisiswant0のnext-16.2.4-pocs で再現確認する方法

セキュリティ研究者dwisiswant0がCVE-2026-44578を含む複数のPoCをGitHubに公開しており、脆弱性の再現・検証が容易な状態になっている。

PoC公開は実際の脆弱な環境への攻撃を容易にするが、同時に防御側が自社環境の脆弱性を確認するためにも活用できる。自社環境での確認（ペネトレーションテスト・脆弱性検証）は法的・契約的に明示的な許可が前提であることを念頭に置く必要がある。

脆弱性の有無を確認する最小コマンド

PoCを使わずに影響を受けるバージョンかどうかを確認するには、バージョンチェックが最も安全で確実だ。

# Dockerコンテナ内の場合
docker exec <container_name> node -e "console.log(require('/app/node_modules/next/package.json').version)"

# Kubernetes Podの場合
kubectl exec -n <namespace> <pod_name> -- node -e "console.log(require('/app/node_modules/next/package.json').version)"

# 直接サーバーの場合
node -e "console.log(require('./node_modules/next/package.json').version)"
# 表示されたバージョンが 13.4.13〜15.5.15 または 16.0.0〜16.2.4 であれば影響あり

パッチ適用後の確認

パッチ適用後に修正版が正しく動作しているかを確認するには、以下のコマンドでバージョンを再確認する。

# 更新後のバージョン確認
node -e "const v=require('./node_modules/next/package.json').version; const ok=v>='16.2.5'||v>='15.5.16'; console.log('next@'+v, ok?'✓ patched':'✗ NEEDS UPDATE')"

CVE-2026-44578の検証に使えるcurlベースのリクエスト確認

リバースプロキシのログでWebSocket Upgradeリクエストの異常な宛先を確認するための最小チェックは以下の通りだ。

# Nginxアクセスログでのアップグレードリクエスト確認（過去7日分）
grep "Upgrade" /var/log/nginx/access.log | tail -100

# 異常なHostヘッダー・X-Forwarded-Hostを含むアップグレードリクエストの有無を確認
grep "upgrade" /var/log/nginx/access.log | grep -v "websocket" | head -20

ログで不審なUpgradeリクエストが見つかった場合、攻撃が既に試みられた可能性がある。その場合はIMDSクレデンシャルのローテーション・CloudTrailログの確認等、インシデントレスポンスの手順に進むことを検討する。

5月セキュリティリリース全体像：CVE-2026-44578以外に注意すべきCVE

2026年5月のNext.js/Reactセキュリティリリースには、CVE-2026-44578だけでなく高深刻度CVEが複数含まれている。WebSocket SSRFの対応を進める際に、合わせて確認すべき他のCVEを整理する。

Vercelは5月6日に9件（CVE-2026-44574〜44582）を一斉公開し、翌5月7日にTurbopackミドルウェア向け不完全修正フォローアップ（GHSA-26hh-7cqf-hhc6）を追加公開した。高深刻度（CVSS 7.0以上）のものを整理すると次のようになる。

CVE-2026-44578（WebSocket SSRF）はVercel管理環境では無影響だが、CVE-2026-44574（動的ルートパラメータ注入・ミドルウェアバイパス、CVSS 8.1）は全環境に影響する点に注意が必要だ。middleware.ts で認証・認可を実装しているアプリはこちらも同等の優先度で対応する必要がある。

また、5月のリリースにはReactのセキュリティ修正も含まれており、react-server-dom-webpack / react-server-dom-parcel / react-server-dom-turbopack の19系も合わせてアップグレードすることが推奨される。

5月セキュリティリリースの全体像と各CVEの詳細についてはNext.js脆弱性CVE-2026-44574〜44582ほか一斉公開、最大CVSS 8.6・15.5.18/16.2.6で修正で詳しく解説している。

自己ホスト環境の対処手順：CVE-2026-44578 緊急対応チェックリスト

自己ホスト運用者がいま取るべきアクションは「バージョン確認→パッチ適用→ログ確認→監視強化」の4ステップだ。PoC公開済みの現状、パッチ適用は数日以内ではなく即日が望ましい。

Step 1: バージョン確認（2分）

# package.jsonで確認
cat package.json | grep '"next"'
# または node_modules直接確認
node -e "console.log(require('./node_modules/next/package.json').version)"

出力が 13.4.13 以上 15.5.16 未満、または 16.0.0 以上 16.2.5 未満であれば対応が必要だ。

Step 2: パッチ適用（10〜30分）

# 16系（推奨）
pnpm up next@^16.2.6 react-server-dom-webpack@^19.2.6

# 15系
pnpm up next@^15.5.18

# 間接依存も固定する場合（pnpm.overrides）

pnpm.overrides（または npm overrides）で間接依存を固定することで、他のパッケージが古いnextを引き込むリスクを防げる。

{
  "pnpm": {
    "overrides": {
      "next": ">=15.5.16"
    }
  }
}

Step 3: ログ確認（15分）

パッチ適用前の期間に不審なWebSocket Upgradeリクエストがなかったかを確認する。

# Nginxログの確認（直近30日）
grep "101" /var/log/nginx/access.log | grep -i "upgrade" | tail -50

# CloudFrontのアクセスログ確認（AWS）
aws s3 cp s3://<your-log-bucket>/cloudfront/ /tmp/cf-logs/ --recursive --include "*.gz"
zcat /tmp/cf-logs/*.gz | grep " 101 " | grep "Upgrade" | head -20

101ステータス（Switching Protocols）は通常WebSocket接続の確立を示す。本脆弱性の攻撃では101が返ることなく攻撃が成立する可能性もあるため、不審な宛先ホストへのリクエスト全体を確認する。

Step 4: IMDSv2強化（AWS環境）

AWSのEC2インスタンスでIMDSv2を必須化することで、SSRF経由でのIMDSアクセスに追加の防護層を設けられる。IMDSv2ではメタデータ取得に事前のPUTリクエストでトークンを取得する必要があり、単純なSSRFでは取得が困難になる。

# IMDSv2必須化（AWS CLI）
aws ec2 modify-instance-metadata-options \
  --instance-id <your-instance-id> \
  --http-tokens required \
  --http-endpoint enabled

ただしこれはSSRFへの緩和策であり、パッチ適用の代替にはならない。パッチ適用を最優先とし、IMDSv2強化はその後の追加防護として実施する。

暫定緩和策：Nginx/ALBでのWebSocket Upgrade制限

パッチ適用がどうしても間に合わない場合のみ、次の暫定緩和を検討できる。ただし正規のWebSocket機能も影響を受ける可能性があるため、WebSocketを使っていないアプリにのみ適用する。

# WebSocket Upgradeを完全に拒否する場合（WebSocket不使用のアプリのみ）
map $http_upgrade $connection_upgrade {
    default close;
    ''      '';
}
server {
    # ...
    location / {
        proxy_pass http://nextjs:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $connection_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

$connection_upgrade が空文字列を返す場合はUpgradeヘッダーがセットされず、WebSocket接続が確立されない。ただしこれは機能制限を伴う緩和策であり、アプリの要件と照らし合わせて判断する必要がある。

まとめ：PoC公開済みのSSRF、自己ホスト運用者は即日対応を

「CVSS 8.6なのでCriticalではない」という読み方はリスクを過小評価する。認証不要・PoC公開済み・クラウドクレデンシャル窃取につながるという組み合わせは、スコア以上の実被害リスクを持つ。自己ホスト環境の運用者はパッチ適用を速やかに進めることが求められる。

参照ソース

• GHSA-c4j6-fc7j-m34r — WebSocket Upgrade SSRF (CVE-2026-44578 / CVSS 8.6) — GitHub Security Advisory
• Next.js May 2026 Security Release — Vercel Changelog
• Vulnerabilities Patched in Next.js and React — CyberPress
• next-16.2.4-pocs — dwisiswant0 (PoC repository)