Next.js・静的サイトは安全か　2025年の重大な脆弱性2件から見る、構成ごとの攻撃される入口

2025年に Next.js で公表された重大な脆弱性2件は、いずれも「サーバーで動く Next.js」が対象で、静的なHTMLとして書き出したサイト（静的エクスポート）は影響を受けない構成でした。一方で、サーバーで動かしている場合は2件とも対象となり、うち1件は国内でも悪用とみられる攻撃が報告されています（IPA、2025年12月10日更新）。

ただし、静的サイトであっても、サイトを作る過程で使う npm のパッケージを狙う攻撃は防げません。「新しい作りだから安全」とは言い切れず、構成によって攻撃される入口が変わると理解するのが実態に近いと考えます。

本記事では、公式発表と公的機関の情報をもとに、次の3点をご説明します。

• 2025年の重大な脆弱性2件が、どの構成に影響したか
• 静的サイトでも残るリスク（サプライチェーン攻撃）
• 構成ごとに確認すべきこと

2025年に公表された重大な脆弱性2件

項目	CVE-2025-29927（Middleware の認可回避）	CVE-2025-55182（React Server Components の遠隔コード実行）
公表日	2025年3月21日 [1]	2025年12月3日 [3]
深刻度（CVSS）	9.1（Critical）[2]	10.0 [3]
内容	Middleware で認可を判定している場合に、その判定を回避できる [2]	認証なしで、細工した HTTP リクエストによりサーバー上で任意のコードを実行できる [3]
影響を受けた構成	next start や output: 'standalone' でサーバーを自社運用している Next.js [1]	App Router で React Server Components を使う Next.js 15.x・16.x（14.3.0-canary.77 以降の canary を含む）[4]
影響を受けなかった構成	静的エクスポート（Middleware はサーバーなしでは動かないため）。Vercel・Netlify・Cloudflare Workers 上の実行環境も対象外と発表 [1]	サーバーを使わない React アプリ、Next.js 13.x・14.x の安定版、Pages Router、Edge Runtime [3][4]（55182 について。関連の脆弱性は別）
修正版	15.2.3・14.2.25（3月18日）、13.5.9（3月22日）、12.3.5（3月23日）[1][2]	15.0.5／15.1.9／15.2.6／15.3.6／15.4.8／15.5.7／16.0.7 [4]。その後の関連の脆弱性も含めた最新の修正版は、React の告知 [3] の一覧をご確認ください（13.x・14.x も関連の脆弱性では更新の対象です）
悪用の状況	公式発表の範囲では記載なし	米国 CISA が「悪用が確認された脆弱性」の一覧に2025年12月5日に追加 [6]。IPA は「国内で発生しているとの情報がある」と発表 [5]

CVE-2025-29927：Middleware の認可回避（2025年3月）

Next.js の Middleware（リクエストを処理する前に動く仕組み）で認可、つまり「この利用者がこのページを見てよいか」を判定している場合に、その判定を回避できる脆弱性です [2]。

Vercel が公開した経緯の報告 [1] によると、2月27日に報告を受け、3月14日に有効な脆弱性と確認し、3月17〜18日（UTC）に 15.2.3・14.2.25 を、3月22〜23日に 13.5.9・12.3.5 を出しています。影響範囲の調査では、静的エクスポートは「Middleware はサーバーの実行環境がなければ使えない」ため、真っ先に対象外と判断されたと記載されています。影響を受けたのは、next start や output: 'standalone' で自社のサーバーに置いて動かしている Next.js でした。

この事例から言えるのは、認可の判定を1か所（Middleware）だけに頼ると、その1か所が破られたときに守りがなくなるということです。GitHub の告知 [2] も、影響を受ける条件を「認可のチェックが Middleware で行われている場合」としています。データを返す処理の側でも権限を確かめる、という多層の設計が望ましいと当サイトでは考えます。

CVE-2025-55182：React Server Components の遠隔コード実行（2025年12月）

React の開発チームが2025年12月3日に公表した脆弱性で、深刻度は最大の CVSS 10.0 です [3]。React Server Components（サーバー側で画面の一部を組み立てる仕組み）が、受け取ったデータを復元する処理に欠陥があり、認証なしで、細工したリクエスト1つでサーバー上のコードを実行されるおそれがありました。

Next.js は同じ問題を CVE-2025-66478 として告知し、App Router を使う 15.x・16.x が影響を受けるとしています [4]。さらに、2025年12月4日 13:00（米国太平洋時間）の時点で修正していなかったサイトには、サイトが使っている秘密情報（API キーなど）を、重要なものから順に変更するよう強く勧めています [4]。修正するだけでは足りず、すでに盗まれた可能性まで考える必要があった、ということです。

国内では、IPA が2025年12月9日に注意喚起を出し、翌10日に「本脆弱性を悪用したと思われる攻撃が国内で発生しているとの情報があります」と追記しています [5]。その後も、サービス停止（CVE-2025-55184・CVE-2025-67779）やソースコードの漏えい（CVE-2025-55183）につながる関連の脆弱性が見つかり [3][5]、2026年1月26日にも新たなサービス停止の脆弱性（CVE-2026-23864）が追加されています [3]。1回の更新で終わらず、2か月近く追加の対応が続いた点は、運用の負担として見ておくべきだと考えます。

一方、React の公式発表は「アプリの React のコードがサーバーを使っていない場合は、この脆弱性の影響を受けない」と明記しています [3]。

静的サイトと「サーバーで動く Next.js」の違い

2件に共通するのは、サーバーで動く処理がなければ、攻撃の入口そのものがないという点です。

Next.js の公式ドキュメント [7] は、静的エクスポートでは使えない機能として、次のものを挙げています。いずれも「サーバーが必要な機能、またはビルドの時点で計算できない処理」です。

• Proxy（旧 Middleware）、Rewrites・Redirects・Headers、Cookies
• Server Actions、リクエストに依存する Route Handlers
• Incremental Static Regeneration（ページの定期的な再生成）
• 既定の画像最適化
• dynamicParams: true の動的ルート、generateStaticParams() のない動的ルート
• Draft Mode、Intercepting Routes

言い換えると、これらの機能を使うことは、サーバー上で動く処理（＝攻撃される入口）を持つことと同じです。2025年の2件はまさにこの部分（Middleware と Server Components）で起きました。

構成	サーバー上で動く処理	2025年の2件の影響
静的エクスポート（HTML を書き出して配信）	なし（配信のみ）	どちらも対象外 [1][3]
ホスティング事業者の実行環境（Vercel など）	あり（事業者が運用）	29927 は実行環境側の作りにより対象外と発表 [1]。55182 は対象。事業者の一時的な緩和策はあったが「それに頼らず更新を」と React が案内 [3]
自社サーバーで next start・standalone	あり（自社で運用）	どちらも対象 [1][4]

静的サイトでも残るリスク：作る過程を狙う攻撃

静的エクスポートは「公開しているサイト」の入口を減らしますが、サイトを作る過程（開発者のパソコンやビルドの環境）は守れません。

2025年9月、米国 CISA は、JavaScript の部品の配布元である npm で「Shai-Hulud」と呼ばれる自己増殖型のマルウェアにより、500以上のパッケージが侵害されたと発表しました [8]。このマルウェアは、感染した環境で GitHub のアクセストークンや、AWS・Google Cloud・Microsoft Azure の API キーを探して盗み出すものでした [8]。Next.js も多くの npm パッケージを使って作るため、静的サイトであっても、ビルドに使う環境が感染すれば、公開用の鍵やクラウドの権限が盗まれるおそれがあります。

IPA の「情報セキュリティ10大脅威 2026」（組織編）でも、「サプライチェーンや委託先を狙った攻撃」が2位に選ばれています（8年連続）[9]。

CISA は、次の対応を勧めています [8]。

• npm の依存関係を見直し、package-lock.json などで影響を受けたパッケージがないか確認する
• 依存パッケージのバージョンを、安全と確認できたものに固定する
• 開発者の認証情報を変更する
• GitHub や npm のアカウントに、フィッシングに強い多要素認証を必須にする
• 不要な GitHub アプリ・OAuth アプリを外し、ブランチ保護・シークレットの検知・Dependabot のセキュリティ更新を有効にする

構成ごとに確認すべきこと

公式発表と公的機関の情報をもとに、当サイトで整理した確認項目です。

確認すること	静的エクスポート	ホスティング事業者の実行環境	自社サーバーで運用
Next.js・React を最新の修正版に更新する（関連の脆弱性を含む [3]）	推奨（公開サイトへの直接の影響は小さい）	必須	必須
秘密情報（API キーなど）を変更する（55182 で、2025年12月4日時点に未修正だった場合）	不要	必要 [4]	必要 [4]
認可を Middleware だけに頼っていないか	該当なし	確認する	確認する
npm の依存関係・ロックファイルの確認	必要 [8]	必要 [8]	必要 [8]
GitHub・npm・ホスティングのアカウントの多要素認証	必要 [8]	必要 [8]	必要 [8]
脆弱性情報の入手先を決めておく（IPA・JPCERT/CC・開発元の告知）	必要	必要	必要

静的エクスポートは、サーバーを使う機能をあきらめる代わりに、公開サイトの入口を大きく減らせる選択肢です。お問い合わせフォームや会員機能が必要な場合は、その部分だけ外部のサービスを使うといった分け方もあります。ただし、その外部サービスの側にも同じように入口ができる点には注意が必要です。

よくある質問

静的サイトなら、セキュリティ対策は不要ですか

不要ではありません。2025年の Next.js の2件のような「公開サイトのサーバーを狙う攻撃」の入口は小さくなりますが、npm パッケージを通じたサプライチェーン攻撃や、GitHub・ホスティングのアカウントの乗っ取りは、静的サイトでも起こりえます [8]。

WordPress などの従来型の CMS と比べて、Next.js は安全ですか

一概には言えません。2026年10月には、WordPress などの土台である PHP にも緊急レベルの脆弱性が公表されました（PHP2Shell の概要と対応）。どちらも、サーバーで動く処理を持てば、その処理が攻撃の入口になります。Next.js でも、2025年には CVSS 10.0 の脆弱性が見つかり、国内で悪用とみられる攻撃も報告されました [3][5]。安全性は「どの技術か」よりも、「サーバーで動く処理をどれだけ持つか」「更新をすぐに当てられる体制があるか」で大きく変わると当サイトでは考えます。

自社のサイトが影響を受けるか、どう確認すればよいですか

まず、①静的エクスポートか、サーバーで動かしているか、②App Router と Pages Router のどちらか、③Next.js と React のバージョン、の3点を確認します。そのうえで、開発元の告知 [2][4] にある影響を受けるバージョンと照らし合わせてください。制作会社に依頼している場合は、この3点の回答と、更新の予定日を確認するのが確実です。

制作会社に相談する場合

当サイトでは、Web制作を掲げている企業の開示状況を掲載しています。制作会社を選ぶ際には、制作後の更新（脆弱性への対応）を誰が・どの範囲で担うのかを、契約前にご確認ください。

• Web制作を掲げている企業の開示状況
• AIガバナンス・セキュリティを掲げている企業の開示状況

脆弱性が公表されたときの進め方は「脆弱性が見つかったときの対応手順」で整理しています。