Next.js脆弱性CVE-2026-44574〜44582ほか一斉公開、最大CVSS 8.6・15.5.18/16.2.6で修正

Vercelが2026年5月6日、Next.jsに存在する9件のCVE（CVE-2026-44574〜44582）を一斉に開示した。翌5月7日には不完全修正のフォローアップとして GHSA-26hh-7cqf-hhc6（Turbopackミドルウェア経由のsegment-prefetchバイパス）が追加公開された。

最大CVSSは CVE-2026-44578（WebSocket経由のSSRF / CVSS 8.6）、続いて CVE-2026-44574（動的ルートパラメータ注入 / CVSS 8.1）。最終的な修正版はNext.js 15.5.18 と 16.2.6 で、5月6日の初期パッチ（15.5.16 / 16.2.5）から翌日に追加修正で2バージョン進んだ形になる。

Cloudflareは同社のChangelogで、Managed Rulesetの既存ルール2本（CVE-2025-55184・CVE-2026-23864向け）が今回のDoS系CVEを先回りでブロックしていると発表した。あわせて自社のNext.jsアダプタ「Vinext」は今回のCVEいずれにも該当しないこと、OpenNext on Cloudflareもハードニング済みであることが明示された。

ただしアプリ本体のパッチ適用は依然として推奨されており、Next.js 15.5.18 / 16.2.6 への計画的なアップグレードが望ましい。なお今回の最大CVSSは8.6でいずれもHigh区分に収まり、Critical級は含まれない。

セキュリティ全体の地図は サプライチェーンセキュリティ完全ガイド2026 をご覧ください。本記事は同ガイドのCVEクラスタに対応する個別速報です。

全10件の脆弱性 一覧表（CVE / CVSS / 影響範囲）

最大はWebSocket SSRF（CVSS 8.6）、続いて動的ルート注入（8.1）、segment-prefetchバイパス（7.5）。High区分が4件、Critical級は含まれない——というのが10件の概観だ。

以下のテーブルはGitHub Security Advisoryで一次確認した10件をCVSS降順で整理したもの。各CVE番号から公式アドバイザリへ直接リンクしているため、原文と引用箇所をクロスチェックできる（GHSA IDは本文中の各セクションでも参照）。修正版はモバイル可読性のため省略形で記載：A=15.5.16/16.2.5（5月6日初回パッチ）、B=15.5.18/16.2.6（5月7日不完全修正フォローアップ反映後の最終版）。

一斉公開された背景：RSC関連アドバイザリの継続的な公開

今回の10件は突発の事故ではなく、半年で20件超に達したRSC関連CVEラッシュの一部——というのが背景の要点だ。

きっかけは2025年12月の CVE-2025-55182（React flightプロトコル経由のRCE） で、それ以来Vercel・React・GitHub Security Lab・外部の研究機関がRSC実装の境界条件を継続的に掘り下げている。結果として2025年Q4から2026年Q2にかけて、月1〜2件ペースで新規CVEが公開されている状況だ。

過去CVEとの関係を整理すると、今回のリリースは「2025年末のRCE関連アドバイザリでRSC実装に注がれた研究者の目線が、副次的にミドルウェア層・キャッシュ層・Image Optimization APIなど周辺コンポーネントへ拡張された結果」と読むのが自然だ。RSC本体だけでなく、Next.jsの周辺機能まで見直し対象になりつつある。

高深刻度4件の中身：SSRF／ミドルウェアバイパス／DoS

高深刻度4件は「SSRF」「動的ルート注入によるミドルウェアバイパス」「segment-prefetchバイパス」「Cache Components DoS」の4カテゴリに分かれる。Critical級ではないが、SSRFは内部メタデータ流出、ミドルウェアバイパスは認証回避につながるため運用影響は大きい。以下、攻撃ベクトル別に深掘りする。

CVE-2026-44578（GHSA-c4j6-fc7j-m34r）— WebSocket SSRF / CVSS 8.6

自己ホストのNext.jsアプリで、Node.js組み込みサーバーがWebSocketアップグレードリクエストを処理する際の検証不備。攻撃者は細工したアップグレードリクエストでサーバーから内部APIや任意の外部宛にリクエストを発行させられる可能性がある。

クラウド環境ではAWS IMDSv2やCloud Run/Workersの内部メタデータエンドポイントからIAMトークン・環境変数・シークレットが窃取される可能性が指摘されている。Vercelホストは影響なし、影響範囲は >= 13.4.13 の長期間にわたる。

修正は通常HTTPリクエストと同じセーフティ検証をWebSocketアップグレードにも適用する形で行われた。

CVE-2026-44574（GHSA-492v-c6pp-mqqv）— 動的ルートパラメータ注入 / CVSS 8.1

middleware.ts で認可をかけているApp Routerアプリで、特殊なクエリパラメータで動的ルート値を書き換えることでミドルウェアの認可チェックをバイパスできる。可視URLは変わらないため、ログ・WAF・監査では検知困難。修正では「内部ルートパラメータ正規化を信頼されたルーティングフローに限定」し、外部リクエストでのパラメータエンコーディングを拒否する。

CVE-2026-44575（GHSA-267c-6grr-h53f）+ GHSA-26hh-7cqf-hhc6 — segment-prefetchバイパス / CVSS 7.5

App Routerのtransport-specificルート変種（segment prefetch）を経由した認可バイパス。本来middleware matcherで保護されているはずのパスが、内部プリフェッチ用の派生ルートではマッチャー対象外になっており、認証なしで保護コンテンツが取得できる。

5月6日に出た初回修正（15.5.16 / 16.2.5）はTurbopackミドルウェアでは効かなかったことが翌日判明し、5月7日に GHSA-26hh-7cqf-hhc6 として 15.5.18 / 16.2.6 で追加修正された。Turbopackユーザーは特に両方のパッチが当たっているかを確認する必要がある。

CVE-2026-44579（GHSA-mg66-mrh9-m8jx）— Cache Components DoS / CVSS 7.5

Partial Prerendering + Cache Components を使うアプリで、細工したサーバーアクションへのPOSTがデッドロックを引き起こしコネクションを保持、サーバーリソースを枯渇させる。修正は Next-Resume ヘッダーを内部ヘッダー扱いにして外部リクエストから受け付けないようにすること。暫定緩和としてエッジで Next-Resume ヘッダーを含む受信リクエストをブロックするのが推奨されている。

攻撃シナリオを図で整理：5分でわかる影響範囲

WAFで防げるのは左半分（既存DoS CVE）だけ、右半分（ミドルウェアバイパス・SSRF・新規DoS）はアプリ層に直接到達する——というのが下図の要点だ。10件をすべて頭に入れるのは大変なので、まず攻撃者がどこから侵入し、何を狙うのかを1枚にまとめる。

この図で重要なのは、WAFがブロックできるのは左半分（既存DoS CVE）だけで、ミドルウェアバイパス・SSRF・新規DoSベクターはそのままアプリ層に到達する点だ。「Cloudflareの後ろにいるから大丈夫」という想定は成立しにくく、依然としてアプリ本体の更新が最初の防御線になる。

影響を受けるバージョンと修正版：パッチコマンド

修正版は Next.js 15.5.18 / 16.2.6（5月7日の不完全修正フォローアップ反映後）。

更新コマンドの例:

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

# Next.js 15.5系（LTS的に残しているチーム向け）
pnpm up next@^15.5.18

# Vinext / Vite系
pnpm up @cloudflare/vinext react@^19.2.6 react-dom@^19.2.6

# 確認
pnpm why next | grep -E "next@1[56]"
pnpm why react-server-dom-webpack

pnpm why（npm/yarnなら npm ls / yarn why）で間接依存も含めて旧バージョンが残っていないかを必ず確認する。@vercel/og や独自プラグインが古いバージョンをロックしているケースが過去CVEの調査でも頻発した。

深掘り：CVE-2026-44581（CSP2XSS）はなぜCSPヘッダー経由でXSSになるのか

「CSPヘッダーがXSSの入口になる」というメカニズム自体が直感に反するため、CVSS 4.7（Moderate）の数値以上に注意が必要——というのが CVE-2026-44581（GHSA-ffhc-5mcf-pf4q）の特徴だ。

10件のうち単独で技術解説に値するのが本CVE。CVSSは数値上は控えめだが、攻撃メカニズムが「セキュリティヘッダーが攻撃ベクトルになる」という構造を持つ。

AISafe Labsが命名した CSP2XSS（Content-Security-Policy 2 XSS） として技術詳細が公開されているため、本節では同社の分析をベースにコードパス・攻撃シナリオ・緩和策を整理する。

脆弱なコードパス：nonce抽出時のエスケープ漏れ

App Routerはリクエストの Content-Security-Policy ヘッダーに含まれる nonce-… 値を内部関数 getScriptNonceFromHeader で抽出し、レスポンスのHTML内に注入する。問題はその検証ロジックだ。

• 関数内の ESCAPE_REGEX は & < > といったHTML特殊文字を弾くが、ダブルクォート " を拒否しない。
• 抽出したnonce値は2つのシンクに到達する:
  • アイコン再挿入スクリプト: <script nonce="…"> の属性値に直接補間される（追加のエスケープなし）。
  • RSCフライトデータ: JSON.stringify で \" にエスケープされるが、HTMLパーサーは属性値内の生の " を属性閉じと解釈する。

JSON文字列としては正規でも、HTMLコンテキストでは属性値をはみ出すという、古典的な「コンテキスト混同（context confusion）」のパターンだ。

攻撃ペイロード：nonce値に " を含めて属性を脱出する

攻撃者は次のようなnonce値をCSPヘッダーに乗せて送る:

Content-Security-Policy: script-src 'nonce-x"src=data:text/javascript,alert(document.domain)//'

サーバーがこのnonce値を抽出してアイコン再挿入スクリプトに埋め込むと、レスポンスHTMLは概ねこうなる:

<script nonce="x" src=data:text/javascript,alert(document.domain)//">…</script>

ブラウザは nonce="x" で属性が閉じたと解釈し、続く src=data:text/javascript,… をスクリプトの読み込み先として処理する。結果、攻撃者の制御するJavaScriptがページのオリジン上で実行される。

反射型から保存型XSSへ：ISRがキャッシュ汚染を引き起こす

単発のリクエストだけなら反射型XSS相当で被害は限定的だが、本脆弱性は Incremental Static Regeneration（ISR）と組み合わさると保存型XSSに化ける。条件は次の3点:

3条件が揃うと、攻撃者が一度悪意あるCSPヘッダーで再生成タイミングを掴むだけで、以降のすべての訪問者にポイズニングされたHTMLが配信される。Cloudflareの Cache-Key カスタム設定や、Vercel CDNのデフォルトキー（URL + Vary 指定ヘッダー）を確認しないと、影響範囲を見落としやすい。

Pages Routerはなぜ影響を受けないのか

Pages Router 系（pages/ ディレクトリ）はReact JSX経由で属性値をレンダリングするため、" が自動で " にエスケープされる。CSP由来のnonce値がJSXを通る限り、属性脱出は起きない。一方App RouterはRSC配送やスクリプト再注入で文字列補間をJSXより低レイヤで行う箇所があり、そこでエスケープがすり抜けた、というのがAISafe Labsの結論だ。

緩和策：受信CSPヘッダーをミドルウェアで剥がす

最終対策は Next.js 15.5.18 / 16.2.6 へのアップグレードだが、即時にバージョンを上げられない場合は、ミドルウェアでリクエスト側のCSPヘッダーを物理的に削除することで攻撃ベクトルを塞げる:

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const requestHeaders = new Headers(request.headers)
  requestHeaders.delete('content-security-policy')
  requestHeaders.delete('content-security-policy-report-only')
  return NextResponse.next({
    request: { headers: requestHeaders },
  })
}

export const config = {
  matcher: '/:path*',
}

Cloudflare Workers / Vercel Edge Middleware いずれでも動作する。通常のクライアントは CSP をリクエストヘッダーで送ってこないため、削除しても正規動作には影響しない（CSPは本来サーバーがレスポンスで返すヘッダー）。WAFレイヤで同等の処理ができる場合は、そちらで弾くのも有効。

検証用PoC（参考）

挙動を再現する最小コードはPythonの requests で次のように書ける:

import requests

target = "https://your-app.example.com/"
malicious_nonce = 'x"src=data:text/javascript,alert(document.domain)//'

resp = requests.get(target, headers={
    "Content-Security-Policy": f"script-src 'nonce-{malicious_nonce}'"
})

# レスポンスHTML中にdata:URI由来のスクリプトソースが現れていれば脆弱
if 'data:text/javascript' in resp.text:
    print("VULNERABLE")

自社アプリの再現確認に利用できる。本番環境や第三者サイトには絶対に向けないこと（無許可のセキュリティテストは法的問題になる）。

Cloudflare Managed WAFの動き：旧ルールが新CVEを”ついでに”防いだ

Cloudflareの公式発表で興味深いのは、過去CVE向けに導入したWAFルール2本が、今回の新CVEもブロックすると判明した点だ。具体的には:

• Rule ID 2694f1610c0b471393b21aef102ec699：CVE-2025-55184（DoS+ソース漏洩）向けに2025年12月から展開。
• Rule ID aaede80b4d414dc89c443cea61680354：CVE-2026-23864（メモリ枯渇DoS / CVSS 7.5）向けに2026年1月から展開。

これらはManaged Rulesetがデフォルト有効ならFree含む全顧客でBlock動作で稼働している。今回のDoS系CVE（CVE-2026-44579、CVE-2026-44577）に対しては追加設定なしでカバーされる。

ただしCloudflareは同時に重要な但し書きを添えている:

残り高深刻度3件（ミドルウェアバイパス・SSRF系）についてはWAFルールで安全に緩和できるか調査中。誤爆で正規アプリ機能を壊さないかを慎重に評価している段階。

つまりWAFだけでは10件中の3件をカバーできない。さらに、ミドルウェアバイパス（CVE-2026-44574 / 44575）やSSRF（CVE-2026-44578）はリクエスト形状が正規利用と非常に近いため、WAFで弾く=”正規ユーザーも弾く” リスクが大きい。アプリ側パッチが本筋という主張はここから来ている。

Vinext と OpenNext on Cloudflare：なぜVinextは無傷だったのか

Vinextは10件すべて影響なし、OpenNext on Cloudflareは部分的に影響ありで追加ハードニングを適用済み——というのがCloudflare自身の評価だ。

Cloudflareは社内で Vinext（Vite上にNext.js APIを再実装したアダプタ）と OpenNext on Cloudflare（OSSコミュニティ製Next.jsアダプタ）を提供しており、それぞれの状況を以下のように整理した。

Vinextの「無傷」は設計上の偶然ではない。同プロジェクトはエッジ環境（Cloudflare Workers / Pages Functions）に最適化するため、ミドルウェア処理・RSC配送・キャッシュ層をゼロから書き直しており、結果としてVercelホスティング前提のNext.js本体に蓄積された境界条件バグを引き継いでいない構造になっている。

ただしVinextは「Next.jsの大半の機能を再現する代替実装」であり、完全な互換ではない。pages/ ディレクトリAPI・一部のmiddleware機能・特定のサードパーティプラグインで挙動差があるため、本番アプリを丸ごと移行するのは現実的でない場合が多い。今回のCVE回避目的で乗り換えるよりも、本体パッチ適用が現実的だ。

OpenNextは構造上Next.js本体のコードを利用するため、追加ハードニングとしてCloudflareチームが攻撃ベクトル向けの追加チェックをアダプタ層で挟んだが、これはユーザー側のNext.jsアップグレードを置き換えるものではない点に注意。

編集後記：Cloudflareの対応速度に見る”第二の責任者”ポジション

今回の一件で個人的に印象に残ったのは、Cloudflareの対応の速さと網羅性だ。

脆弱性公開と同日（2026年5月6日）にChangelogが出て、しかも過去CVE（CVE-2025-55184・CVE-2026-23864）向けに展開済みのWAFルール2本が、新CVEもついでにブロックすることを検証済みで発表できる、というのは「先回り」というより過去の対応が再利用可能な資産になっていることの証明と言える。

WAFルールは一度作って終わりではなく、後続CVEへのカバレッジを継続検証していることが裏で動いていなければ、こうは出せない。

加えて Vinext が無傷だったのも偶然ではなく、Vercelホスティング前提の境界条件バグを引き継がない設計になっていたことの結果だ。

「自社実装をフレームワークと並行で持ち、エコシステムの脆弱性公開時に独立して影響範囲を即時表明できる」 というのは、現状ではCloudflareくらいしかやれていない芸当だ。OpenNextへのハードニングまで同時にコミットしているあたりも含めると、CDN事業者というよりNext.jsエコシステムの第二の責任者ポジションを取りにいっている、と読むのが自然だ。

ベンダー選定の評価軸として「インシデント時の透明性と対応速度」を改めて入れる価値がある、というのが今回の率直な感想だ。

自社アプリのチェックリスト：3段階の対応フロー

やるべきことは「初動10分でバージョン確認」「当日〜数日でパッチ適用」「翌週で設計レビュー」の3段構え——以上が結論で、以下は時間配分の目安と各フェーズの具体タスクを並べたチェックリストだ。

overrides は特に重要で、間接依存で古い next が引きずられるケースを潰せる。package.json の例:

{
  "pnpm": {
    "overrides": {
      "next": "^16.2.6",
      "react-server-dom-webpack": "^19.2.6",
      "react-server-dom-parcel": "^19.2.6",
      "react-server-dom-turbopack": "^19.2.6"
    }
  }
}

過去CVEとの連続性：RSCは”枯れる”までもう少しかかる

2025年12月のCVE-2025-55182（RCE）、2026年1月のCVE-2025-55184（DoS+ソース漏洩）、CVE-2026-23864（メモリ枯渇）、そして今回の10件と、RSC関連CVEは半年で20件超に達する。これは脆弱性が”特に多い”のではなく、新しい仕組みが普及期に入って研究者・攻撃者の目に晒されている結果と読める。

歴史的には、Spring・Struts・Rails・Express といった主要フレームワークは普及してから2〜3年で一通りの境界条件CVEが出尽くし、その後は安定する。RSCの本格普及は2024年後半なので、2026年〜2027年前半は新規アドバイザリの公開ペースが続くと見ておくのが妥当だ。

まとめ：WAFは時間稼ぎ、本筋はパッチ適用

今回のリリースの教訓は単純で、「CDN/WAFは攻撃を遅らせる装置であって、止める装置ではない」 という古典的原則がRSC時代にもそのまま通用するということだ。Cloudflareの先回り対応は実用的だが、それでも10件中3件はカバー外で、残りもアプリ更新が前提にある。最大CVSSは8.6でCritical級ではないものの、Next.js 16.2.6 / 15.5.18 への計画的なアップグレードを通常のリリースサイクルで進めるのが望ましい。

参照ソース

一次ソース：GitHub Security Advisory（Vercel公式）

• GHSA-c4j6-fc7j-m34r — WebSocket SSRF（CVE-2026-44578 / CVSS 8.6）
• GHSA-492v-c6pp-mqqv — 動的ルート注入（CVE-2026-44574 / CVSS 8.1）
• GHSA-267c-6grr-h53f — segment-prefetchバイパス（CVE-2026-44575 / CVSS 7.5）
• GHSA-26hh-7cqf-hhc6 — Turbopackミドルウェア不完全修正フォローアップ（CVSS 7.5）
• GHSA-mg66-mrh9-m8jx — Cache Components DoS（CVE-2026-44579 / CVSS 7.5）
• GHSA-gx5p-jg67-6x7h — beforeInteractive XSS（CVE-2026-44580 / CVSS 6.1）
• GHSA-h64f-5h5j-jqjh — Image Optimization API DoS（CVE-2026-44577 / CVSS 5.9）
• GHSA-wfc6-r584-vfw7 — RSCキャッシュポイズニング（CVE-2026-44576 / CVSS 5.4）
• GHSA-ffhc-5mcf-pf4q — CSP nonce XSS（CVE-2026-44581 / CVSS 4.7）
• GHSA-vfv6-92ff-j949 — RSCキャッシュ衝突（CVE-2026-44582 / CVSS 3.7）
• Vercel Next.js Security Advisories（一覧）

二次ソース：解説・WAF対応

• WAF and framework adapter mitigations for React and Next.js vulnerabilities — Cloudflare Changelog（2026-05-06）
• CSP2XSS: Next.js App Router XSS via Content-Security-Policy header — AISafe Labs
• Critical Security Vulnerability in React Server Components — React Blog
• Next.js Security Update: December 11, 2025
• CVE-2026-23864: React and Next.js Denial of Service via Memory Exhaustion — Akamai