CVE-2025-55182対策ガイド：RSC脆弱性の検出と修正を実践するセキュリティ対応手順
お疲れ様です！IT業界で働くアライグマです！
「Next.jsを使っているプロジェクトで、緊急のセキュリティアップデートが必要らしい」「CVE-2025-55182って何？うちのプロダクトは大丈夫？」と、急に対応を迫られているエンジニアの方も多いのではないでしょうか。
2025年12月に公開されたCVE-2025-55182は、React Server Components（RSC）の実装に起因するリモートコード実行（RCE）脆弱性です。Next.js の App Router を使っているプロジェクトを中心に、影響範囲が広いことから GitHub 上でも複数の検出ツールや PoC（概念実証コード）が公開され、大きな話題になっています。
私自身、PjMとして複数のNext.jsプロジェクトを見てきましたが、今回の脆弱性は「とりあえずアップデートすればOK」では済まないケースもあるため、影響範囲の特定と対応手順を整理しておくことが重要です。
本記事では、CVE-2025-55182の概要から、自分のプロジェクトが影響を受けるかどうかの確認方法、具体的な修正手順までを実践的に解説していきます。
CVE-2025-55182の全体像と影響範囲
まずは、CVE-2025-55182がどのような脆弱性なのか、全体像を整理しておきます。ここを理解しないまま対応を進めてしまうと、「アップデートしたのに実は影響が残っていた」「そもそも影響を受けないのに過剰対応してしまった」といったことが起こりえます。
脆弱性の概要
CVE-2025-55182は、React Server Components（RSC）のシリアライズ処理に起因する脆弱性です。攻撃者が細工したリクエストを送信することで、サーバーサイドで任意のコードを実行できてしまう（RCE: Remote Code Execution）という深刻な問題です。
具体的には、RSCのペイロードをデシリアライズする際に、入力値の検証が不十分な箇所があり、そこを突くことでサーバー上でコードを実行できてしまいます。実践サイバーセキュリティ入門講座 でも解説されているように、デシリアライズ脆弱性は古くから知られている攻撃手法ですが、RSCという比較的新しい仕組みに潜んでいたことで発見が遅れました。
影響を受けるプロジェクトの特徴
この脆弱性の影響を受けるのは、主に以下の条件を満たすプロジェクトです。
- Next.js 13.4〜15.0.2 を使用していて、App Router を有効化している
- React Server Components を利用していて、use server ディレクティブを使った Server Actions を含む
- 外部からのリクエストを受け付けるエンドポイントがある（公開Webアプリケーション）
逆に、Pages Router のみを使っている従来型のNext.jsプロジェクトや、静的サイト生成（SSG）のみで動的なサーバー処理がないプロジェクトは、基本的に影響を受けません。
Next.js 16 Cache Components完全ガイド：App Routerのキャッシュ戦略を根本から理解する でも触れていますが、App Router と RSC の仕組みを理解しておくと、今回の脆弱性がどこに影響するのかがイメージしやすくなります。
影響有無の確認方法
次に、自分のプロジェクトが CVE-2025-55182 の影響を受けるかどうかを確認する方法を整理します。ここでは、手動での確認方法と自動検出ツールを使った方法の両方を紹介します。
手動での確認ステップ
まずは、以下の3点を順番に確認していきます。
Next.js のバージョン確認
npm list next
# または
yarn list next
# または
pnpm list next出力されたバージョンが 13.4.0 〜 15.0.2 の範囲に含まれている場合は、次のステップに進みます。15.0.3 以降、または 13.4.0 より前のバージョンであれば、この脆弱性の影響は受けません。
App Router の使用有無を確認
プロジェクト内に app ディレクトリが存在し、その中に page.tsx や layout.tsx があるかどうかを確認します。
ls -la app/
# または
find . -path ./node_modules -prune -o -name "page.tsx" -print | head -10app ディレクトリが存在しない、または pages ディレクトリのみを使っているときは、App Router を使っていないため影響を受けません。
Server Actions / RSC の使用有無を確認
プロジェクト内で use server ディレクティブを使っているファイルがあるかどうかを確認します。
grep -r "use server" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx" .このコマンドで何かヒットした場合、Server Actions を使っているため、CVE-2025-55182 の影響を受ける可能性が高いです。
ケーススタディ：私のチームでの緊急対応
私がPjMとして関わっていたNext.jsプロジェクトでも、今回の脆弱性の影響を受けました。具体的な対応の流れを紹介します。
状況（Before）：
当時、私のチームでは Next.js 14.2.3 を使った BtoB SaaS を運用していました。App Router を採用しており、フォーム送信や検索機能で Server Actions を10箇所以上使っていました。脆弱性情報が公開された時点で、本番環境が攻撃可能な状態であることが判明しました。当時のユーザー数は約500社、月間リクエスト数は約200万件の規模でした。
行動（Action）：
脆弱性情報を受けて、まず react2shell-scanner でステージング環境をスキャンし、影響を確認。その後、緊急メンテナンスを告知し、約4時間で Next.js 15.0.3 へのアップデートとデプロイを完了しました。並行して、AWS WAF に RSC ペイロードをブロックするルールを追加し、多層防御の体制を整えました。
結果（After）：
アップデート後の再スキャンで脆弱性が解消されていることを確認。攻撃ログの調査では、幸いにも悪用された形跡はありませんでした。この経験から、依存パッケージの脆弱性を週次でチェックする GitHub Actions ワークフローを追加し、今後の早期検知体制を整備しました。結果として、脆弱性情報公開から対応完了までの所要時間を約4時間に短縮できました。
npm Shai-Hulud感染チェックと対策：サプライチェーン攻撃から開発環境を守る実践ガイド でも触れていますが、セキュリティ対応では「影響範囲の特定」を最初に行うことが重要です。ゼロトラストネットワーク［実践］入門 のようなセキュリティ書籍でも、まずはアセットの棚卸しから始めることが推奨されています。
自動検出ツールを使った確認
GitHub 上で公開されている検出ツールを使うと、より確実に影響有無を確認できます。代表的なツールとして、react2shell-scanner があります。
# react2shell-scanner のインストールと実行
git clone https://github.com/assetnote/react2shell-scanner.git
cd react2shell-scanner
pip install -r requirements.txt
# 対象URLをスキャン
python scanner.py --url https://your-app.example.comこのツールは、対象のURLに対してRSCのフィンガープリントを検出し、脆弱性の有無を判定してくれます。本番環境に対して実行する場合は、事前に関係者への周知と許可を得てから行ってください。
修正手順：アップデートと設定変更
影響を受けることが確認できたら、次は修正作業に入ります。基本的にはNext.js を 15.0.3 以降にアップデートすることで対応できますが、いくつか注意点があります。
Next.js のアップデート
# npm の場合
npm install next@latest
# yarn の場合
yarn add next@latest
# pnpm の場合
pnpm add next@latestアップデート後、バージョンが 15.0.3 以降になっていることを確認します。
npm list next
# next@15.0.3 以降であればOKすぐにアップデートできない場合の緩和策
プロジェクトの都合で、すぐに Next.js をアップデートできない場合もあるかと思います。その場合は、以下の緩和策を検討してください。
Server Actions を一時的に無効化する
next.config.js で Server Actions を無効化することで、攻撃経路を塞ぐことができます。
// next.config.js
module.exports = {
experimental: {
serverActions: false,
},
};ただし、この設定を行うと Server Actions を使っている機能が動作しなくなるため、アプリケーションの動作確認を必ず行ってください。
WAF（Web Application Firewall）でのブロック
AWS WAF や Cloudflare WAF を使っている場合、RSC のペイロードパターンをブロックするルールを追加することで、攻撃を緩和できます。具体的なルール設定は、使用している WAF のドキュメントを参照してください。
AWSアンチパターン完全ガイド：やってはいけない設計と運用の落とし穴を回避する実践的アプローチ でも触れていますが、セキュリティ対応では「多層防御」の考え方が重要です。3カ月で改善！システム障害対応 実践ガイド のようなインシデント対応の書籍でも、単一の対策に頼らず複数の防御層を設けることが推奨されています。
修正後の検証とCI/CD への組み込み
修正が完了したら、脆弱性が解消されていることを検証し、今後同様の問題が発生しないようにCI/CDパイプラインに検出処理を組み込んでおくことをおすすめします。
修正後の検証
先ほど紹介した react2shell-scanner を再度実行し、脆弱性が検出されないことを確認します。
python scanner.py --url https://your-app.example.com
# 「Vulnerable: No」と表示されればOKまた、ステージング環境でアプリケーション全体の動作確認を行い、アップデートによる副作用がないことを確認してください。
CI/CD への組み込み
GitHub Actions を使っている場合、以下のようなワークフローを追加することで、依存パッケージの脆弱性を継続的にチェックできます。
# .github/workflows/security-check.yml
name: Security Check
on:
push:
branches: [main]
pull_request:
branches: [main]
schedule:
- cron: '0 9 * * 1' # 毎週月曜9時に実行
jobs:
audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npm audit --audit-level=high
continue-on-error: falseCloudflare Workerで構築するTelegramボット：サーバーレスメッセージング基盤の設計と実装 でも触れていますが、セキュリティ対応は「一度やって終わり」ではなく、継続的にチェックする仕組みを作っておくことが重要です。Clean Architecture 達人に学ぶソフトウェアの構造と設計 のような設計書籍でも、保守性と継続的改善の重要性が強調されています。
まとめ
最後に、本記事のポイントを整理します。
- CVE-2025-55182 は、React Server Components のデシリアライズ処理に起因する RCE 脆弱性であり、Next.js 13.4〜15.0.2 の App Router を使っているプロジェクトが主な影響対象
- 影響有無の確認は、バージョン確認 → App Router 使用有無 → Server Actions 使用有無の順で行い、必要に応じて react2shell-scanner などの自動検出ツールを活用する
- 修正はNext.js 15.0.3 以降へのアップデートが基本。すぐにアップデートできない場合は、Server Actions の無効化や WAF でのブロックを検討する
- 修正後は検証を行い、CI/CD に脆弱性チェックを組み込んで継続的に監視する体制を整える
セキュリティ対応は「緊急だから」と焦って進めると、影響範囲の見落としや副作用の確認漏れが起きやすくなります。本記事の手順を参考に、落ち着いて対応を進めていただければと思います。
厳しめIT女子 アラ美による解説ショート動画はこちら
PjMが厳選した【高年収】への近道
