セキュリティ対策
Next.jsとReactは脆弱性が多いのか — CVEの実データで見る「危ないのはどこか」
「Next.jsやReactは脆弱性が多いのか」をNVDの実データで確認しました。Next.jsは56件（2026年だけで28件）、Reactは6件。そしてReactの近年の5件はすべてReact Server Components＝サーバー側です。Next.jsのCVEもMiddleware・キャッシュ・画像最適化・Server Actionsに集中しており、CWEの上位はSSRF・デシリアライズ・認可迂回。つまり危ないのは『フロントの書き方』ではなくフレームワークが引き受けたサーバー機能である、という話を、設計と運用の指針まで落として解説します。
対象：Next.js（App Router / Pages Router 問わず）でサービスを運用している人、これから採用を判断する人。「フレームワークの脆弱性が多いらしい」という漠然とした不安を、実データと、その中身に置き換えます。
実データ（NVD・2026年8月22日時点）
| Next.js | React | |
|---|---|---|
| 累計 | 56件 | 6件 |
| 年別 | 2020:1 / 2021:3 / 2022:3 / 2023:1 / 2024:6 / 2025:14 / 2026:28 | 2018:1 / 2025:4 / 2026:1 |
| 深刻度 | CRITICAL 2・HIGH 21・MEDIUM 29・LOW 4 | CRITICAL 1・HIGH 3・MEDIUM 2 |
| 最悪の1件 | CVE-2025-29927（ミドルウェアでの認可を迂回・CVSS 9.1） | CVE-2025-55182（React Server Components の事前認証不要RCE・CVSS 10.0） |
件数の読み方に注意
件数が多い＝危険な技術、ではありません。採用が広がるほど研究者の目も集まり、報告件数は構造的に増えます。逆に件数が少ない技術は「安全」かもしれないし「誰も見ていない」だけかもしれません。件数は入口の指標にすぎず、判断材料になるのは『どこに、どの種類が出ているか』です。なお本記事の件数は NVD をCPE（vercel:next.js / facebook:react）で照会した実数で、CPEが付与されていないものは含まれません。
どこに出ているのか
2025〜2026年に公開された Next.js のCVEを、記述に現れる機能名で分類するとこうなります。
| 出ている場所 | 中身の例 |
|---|---|
| キャッシュ | キャッシュの取り違え・汚染（別の利用者の応答が返る類） |
| Middleware / ルーティング | 認可の迂回。ミドルウェアで守っているつもりの経路が通ってしまう |
| 画像最適化 | 外部URLの取り込みに伴う SSRF とリソース枯渇 |
| Server Actions / RSC | 信頼できない入力のデシリアライズ、リクエストによる過負荷 |
| rewrites / redirects | 転送先の解釈のズレを突かれる |
CWEの上位も裏付けになります——CWE-770（リソースの無制限確保）、CWE-918（SSRF）、CWE-502（デシリアライズ）、CWE-400（リソース枯渇）、CWE-444（リクエスト解釈の不一致）、CWE-288/285（認可の迂回・不備）。これは典型的なサーバー／プロキシの脆弱性の並びです。
ブラウザ側（Reactのコンポーネント描画）
NVD上のReact本体のCVEは2018年の1件のみ
サーバー側①：React Server Components
近年のReactのCVE 5件はすべてここ（最悪は事前認証不要のRCE）
サーバー側②：Next.js の Middleware / キャッシュ / 画像最適化 / rewrites
認可迂回・SSRF・キャッシュ汚染・リソース枯渇
繰り返し出ている形＝「ミドルウェアでの認可」
同じ形が何度も出ている点は、単発のCVEより重要です。
2025年3月 — CVE-2025-29927（CVSS 9.1）
特定のヘッダを含むリクエストで、ミドルウェアで行っている認可チェックを迂回できた。修正は 12.3.5 / 13.5.9 / 14.2.25 / 15.2.3。2026年5月 — CVE-2026-44574（CVSS 8.1）
細工したクエリパラメータで動的ルートの値だけをずらし、URLの見た目を変えずに保護対象を表示させられた。修正は 15.5.16 / 16.2.5。2026年7月 — CVE-2026-64642（CVSS 8.2）
App Router × Turbopack ×config.i18n.localesが単一という構成で、ミドルウェア/プロキシによる認証を迂回できた。修正は 16.2.11。
ここから引き出せる設計判断
1年半で「ミドルウェアの認可が通り抜けられる」形の重大CVEが3回出ています。実装の個別バグではなく、“経路の手前で判定する”という構造そのものが、経路の解釈がズレた瞬間に破れるということです。だから当サイトの立場は明快で——ミドルウェアの認可は「入口の足切り」までにして、本当の認可判定はデータに触れる直前（ページ／Route Handler／データ層）にもう一度置く。二度書く手間より、迂回された日の被害のほうが圧倒的に高くつきます。
ホスティング形態で変わるものもある
見落とされがちですが、同じCVEでも自己ホストかマネージドかで影響が変わることがあります。たとえば CVE-2026-44578（CVSS 8.6）は、セルフホストで組み込みのNode.jsサーバーを使っている場合にWebSocketのアップグレード要求経由でSSRFが成立し、内部サービスやクラウドのメタデータ endpoint に到達し得るというもので、Vercelホストのデプロイは対象外と明記されています。
つまり「Next.jsの脆弱性」と一括りにせず、自分の動かし方（セルフホスト／マネージド、使っている機能）で当たり判定が変わることを前提に読む必要があります。
実務でやること
認可を二重化する（最優先）
ミドルウェアの認可は入口の足切りとして残しつつ、データに触れる直前でもう一度判定する。上に挙げた3件はいずれもこれで被害を止められる形でした。認証と認可の切り分けは 認証と認可の違い を参照。
外向きの取り込みを許可リストで絞る
画像最適化の外部URL、サーバー側の fetch の宛先、rewrite の転送先を許可した先だけに限定する。SSRF 系のCVEは、外向き先が自由なほど刺さります。クラウドのメタデータ endpoint への到達可否も確認する。
Server Actions / RSC のエンドポイントを認証の内側に置く
ここはリクエストのボディをデシリアライズする経路です（CWE-502のCVEが実際に出ています）。認証の外側に置かない、レート制限を掛ける、想定外のペイロードで落ちないようにする——/api と同じ扱いをする、が原則です。
更新を“仕組み”にする
Next.jsは修正版の公開が速い代わりに、追随しないと置いていかれます。実稼働版で判定し、依存を機械監視する具体策は Next.js を安全に運用する と osv-scannerの導入と使い方 にまとめています。件数が増えている以上、ここは人力では持ちません。
当サイトの視点：フレームワーク選びの問いは「件数」ではない
「Next.jsは脆弱性が多いから避けるべきか」という問いは、実は的を外しています。データが示しているのは、Next.jsが年々“サーバーとして”の責務を増やしているという事実です——ミドルウェアで認可し、画像を取りに行き、キャッシュを持ち、リクエストをデシリアライズする。それはリバースプロキシとアプリケーションサーバーを1つの依存として抱えているのと同じことです。だから評価すべきは「件数」ではなく「そのサーバー機能を自分が使うのか、使うなら誰が守るのか」。使わない機能は無効にし、使う機能は自分の設計で二重化する。この観点を持てば、フレームワークの選択は好き嫌いではなく、運用体制の問題として扱えます。
出典
- NVD（NIST）— 2026年8月22日時点で
cpe:2.3:a:vercel:next.js/cpe:2.3:a:facebook:reactを照会した実数にもとづく - CVE-2025-29927（ミドルウェアでの認可迂回）／CVE-2026-44574（動的ルートの値のずらし）／CVE-2026-64642（App Router × Turbopack の認証迂回）
- CVE-2026-44578（セルフホストのWebSocket経由SSRF・Vercelホストは対象外）
- CVE-2025-55182（React Server Components の事前認証不要RCE・CVSS 10.0）／CVE-2026-23864（RSCのDoS）
次に読む
よくある質問
QNext.jsは脆弱性が多いのですか？
件数としては多く、増えています。NVDを2026年8月22日時点で照会すると、Next.jsに紐づくCVEは56件で、内訳は2024年6件・2025年14件・2026年28件です。ただし『多いから危険な技術』と読むのは早計で、採用が広がるほど研究者の目も集まり報告件数は増えます。重要なのは件数より、どこに出ているかです。
QReactは脆弱性が少ないのですか？
React本体（ブラウザ側のUIライブラリ）としては非常に少なく、NVD上は6件です。そして2018年の1件を除く近年の5件は、すべてReact Server Components（react-server-dom-parcel / turbopack / webpack）に関するもの——つまりサーバー側です。中には事前認証不要のリモートコード実行（CVE-2025-55182・CVSS 10.0）も含まれます。
Q結局どこが危ないのですか？
サーバー機能です。Next.jsの近年のCVEはMiddleware、キャッシュ、画像最適化、Server Actions、rewritesに集中しており、CWEの上位もSSRF（CWE-918）、信頼できないデータのデシリアライズ（CWE-502）、リソース枯渇（CWE-770/400）、認可の不備（CWE-285/288）です。いずれもコンポーネントの書き方ではなく、フレームワークがサーバーとして提供している機能の問題です。
Q何をすれば一番効きますか？
①認可をミドルウェアだけに依存させない（実際に認可迂回のCVEが繰り返し出ています）②画像最適化やfetchの外向き先を許可リストで絞る③Server Actions／RSCのエンドポイントを認証の内側に置く④更新を運用として仕組み化する、の4点です。特に①は、同じ形の脆弱性が2025年と2026年に別々に出ている以上、設計として二重化しておく価値があります。