CVE-2025-55182—React Server ComponentsのRCEは「既定で刺さる」可能性が高い

今日の深掘りポイント

• RSC（React Server Components）の実装に起因するRCEで、認証なし到達・既定設定で露出しうるパスが鍵です。フレームワーク側（Next.jsなど）のRSCエンドポイント運用と密接に絡むため、「Reactだけ更新」で収束しない環境が相当数あります。
• 攻撃面はRSCプロトコルのデシリアライズ処理に集中。ミドルウェアやWAFでのRSCプロトコル／MIME特性に基づく緩和余地がありますが、正確なブロッキングにはバージョン/実装差の理解が不可欠です。
• 事業側影響は“Webの国境を越える”という意味で広範です。外部公開のRSCエンドポイント棚卸、Canary展開＋ログ監査を同時実施し、フレームワーク更新（React本体＋SSR/RSCハンドラ）をワンセットで回す運用標準を整えるべきです。

はじめに

CVE-2025-55182は、React Server Components（RSC）におけるリモートコード実行（RCE）脆弱性です。未認証リクエストから到達し得るRSCハンドラのデシリアライズ処理を突かれると、任意コード実行に至る可能性があります。RSCをサポートするアプリケーションは、明示的にサーバーアクション（use server）を使っていない場合でも影響を受ける構成があり、既定設定で露出する導線が現実的です。公開情報では詳細なトリガやバージョン範囲、検証用PoCの存在が示唆され、攻撃可能性は高いフェーズに入っています。TenableのテクニカルノートはRSCプロトコル面の理解に資する有用な一次情報です。

本稿では、技術的事実と組織運用の要点を分けて整理し、CISO/SOC/TIの視点で攻撃シナリオ、可視化と防御、即応ロードマップを提示します。

深掘り詳細

事実関係（確認できるポイント）

• 脆弱性の性質
  未認証のリモート攻撃者が、RSCに特有のシリアライズ／ストリーミング（いわゆる“Flight”プロトコル）に悪性ペイロードを混入させ、サーバ側で任意コード実行に至る可能性があるRCEです。RSC対応アプリは、直接サーバーアクションを呼ばなくても、RSCストリーム処理の入口が開いていれば攻撃面が成立します。一次情報として、Tenableが解析レポートを公開しています［React2Shell］(Tenable)。
• 影響面
  RSCはNext.jsなどモダンSSRフレームワークで標準利用が進み、RSC用エンドポイントが既定で公開される構成が一般的です。結果として「React本体の更新だけ」では攻撃面が閉じず、ランタイム（Node/Edge）、フレームワーク（Next.js等）、アダプタ（Vercel/自社CDNやリバースプロキシ）まで含めたパイプライン更新が必要になります。TenableはRSCプロトコル経由の到達性を前提とした実践的な悪用成立性を指摘しています(同上)。
• パッチ/緩和
  Reactチームから修正版が公開された旨が報告されています。適用は最優先ですが、実サービスではRSCエンドポイントの露出抑制、特定ヘッダ/MIME（例: text/x-component 等のRSCレスポンス特性）とルーティングの点検、WAF/リバプロでのプロトコル検証強化が並行必須です。技術詳細と検知のヒントはTenableの解説にまとまっています(同上)。

注: 執筆時点で、React公式のセキュリティアドバイザリやNVDの最終確定メタデータの公開範囲は限定的な可能性があります。組織適用時は、React公式リリースノート/アドバイザリ、フレームワーク（例: Next.js）のセキュリティ告知、パッケージレジストリの依存連鎖を都度確認する前提で進めます。

編集部インサイト（攻撃運用・防御運用の“すき間”）

• 既定公開の“目に見えないAPI”が攻撃面に
  RSCは画面表示の一部でありながら、実際には独自プロトコル/ストリームを話すAPIです。CI/CDでのE2Eテストでは見逃されやすく、WAFの既存ルールでも素通りしがちです。ルートディスカバリ（/.well-known的な探索、フレームワーク既定パスの定番スキャン）との組み合わせで初期侵入を加速させます。
• “React更新＝安全化”の誤認を回避
  実サービスは「React（ライブラリ）」「SSR/RSC実行器（Next.jsや独自SSR）」「リバプロ/エッジ（Vercel/Cloudflare/APIM）」「観測基盤（ログ/メトリクス）」が連動します。脆弱性はRSC境界のデシリアライズにあるため、境界での不正入力排除・異常検出・短期的遮断（Feature Flag/ルート切替）を準備しておくと、ライブラリ更新が間に合わない場合の被害最小化に効きます。
• ログと可観測性の“体系化”が決定打
  RSC特有のヘッダ・MIME・チャンク構造に基づくアノマリを集約可視化するダッシュボードを持つ組織は少ないのが実情です。今回のような新型プロトコル系脆弱性では、正規トラフィック分布（ペイロード長、分割数、ステータス異常、エラー頻度）を事前にベースライン化していれば、ゼロデイ観測やWAF誤検知調整が迅速になります。

脅威シナリオと影響

想定シナリオ（仮説を含む）:

• インターネット露出のRSCエンドポイントへ、細工したRSC/Flightフレームを送信し、サーバ側デシリアライズの不備を突いてコード実行。
• ステルス性確保のため、通常のナビゲーション/プリフェッチに紛れる形で段階的にペイロードを分割（ストリーミング断片化）。CDN/キャッシュ層をバイパスするためのキャッシュ不可ヘッダやPOST主体を利用。
• 既存WAFルールを回避するため、一般的なJSON/XMLではなく、RSC固有のコンテンツ型・トークン境界を悪用し、シグネチャの“空白地帯”に着地。

MITRE ATT&CK（仮説マッピング）:

• Initial Access: Exploit Public-Facing Application (T1190)
• Execution: Command and Scripting Interpreter（Node.js/サーバランタイムでの実行; T1059）
• Defense Evasion: Obfuscated/Compressed Files and Information（ストリーミング分割や非標準MIME; T1027）
• Discovery: Application Window Discovery/Query Registry相当のアプリ内環境調査（T1518/T1012に準ずる）
• Credential Access: OS/アプリケーション秘密情報抽出（環境変数・メタデータ; T1552）
• Exfiltration: Exfiltration Over Web Service（同一エンドポイント経由や別チャネル; T1567）
• Impact: Data Manipulation/Service Stop（T1565/T1489）

ビジネス影響:

• SaaS/EC/金融のSSR活用サービスでは、セッションハイジャックやテンプレート改ざん、支払いフロー改変リスクが現実的に増大します。
• サプライチェーン面では、マイクロ前段（エッジ）と本体（オリジン）双方にパッチが必要なため、保守窓口・責任分界の摩擦が増え、MTTRが延びやすいです。
• データ保護規制（個情法/GDPR）に対し、攻撃成立時のログ保全・侵害判断の迅速化が監督当局対応の成否を左右します。

セキュリティ担当者のアクション

優先度高（同時並行で即日〜72時間以内）

• 影響判定とパッチ適用
  • Reactの修正版へ更新。併せてNext.jsなどRSCハンドラ実装側の最新安定版へロールアップデート。
  • SBOM/依存グラフでRSC利用の有無と到達性（外部公開/内部限定）を棚卸し。VercelやCloudflare等のEdge実行も対象に含める。
  • 参考: 技術的背景と攻撃成立性に関する一次情報はTenableの解説を参照。
• 露出エンドポイントの即時防御
  • リバースプロキシ/WAFでRSC関連パスを仮遮断・許可リスト化（管理画面・BFF配下など必要域のみ開放）。
  • RSC特有のヘッダ/コンテンツタイプ（例: RSC/Flightレスポンスのtext/x-component系、ストリーミング分割）に基づく検知ルールを暫定適用。既存のJSON/XSS/SQLi専用ルールではカバーしないことを前提に独自シグネチャを追加。
  • CDNキャッシュ・プリフェッチ・サーバアクションの公開範囲を再設定（プリロード短縮・不要エンドポイント無効化）。
• 検知・対応体制
  • ログの迅速な集約: 4xx/5xxのうちRSCハンドラ由来を切り分け、ペイロード長・チャンク数の異常、同一クライアントからの高頻度ヒットをアラート化。
  • サーバ側での“安全失敗”強化: デシリアライズ失敗時の詳細エラー出力停止、例外時のスタックトレース抑制、リトライ無効化。
  • Canaryデプロイ＋トラフィックミラーリングで新ルールの誤検知/漏れを検証。

短中期（1〜4週間）

• アーキテクチャ見直し
  • “RSCインターネット直結”を原則禁止し、API GatewayやService Meshで検査・整形するパターンへ移行。スキーマ化とサイズ上限、分割数上限を設ける。
  • ライブラリ更新を“フレームワーク・ランタイム・エッジ”と一体運用に統合。プラットフォーム側SLA（Vercel/Cloudflare）と自社SLAを接続した更新手順書を標準化。
• 可観測性の定常化
  • RSCトラフィックのベースラインをダッシュボード化。デプロイごとに比較可能なメトリクス（平均ペイロード長、90/99パーセンタイル、チャンク率、エラー率）を定義。
  • 攻撃練度前提のTTPハンティングをSOCで継続（ストリーミング分割とUser-Agent/ASNの相関、短時間のルートブルートフォースなど）。

ガバナンス

• セキュリティ例外管理に「プロトコル系脆弱性」のカテゴリを追加し、ゼロデイ時の遮断権限（プロダクト側KPI影響範囲を含む）を事前合意。
• ベンダ連携（React/Next.js、PaaS/CDN）連絡網の更新と定期訓練。脆弱性開示〜緩和ルール配布〜本番反映までのMTTA/MTTRをKPI化。

総括

• 今回の事案は、流通量・即応性・実装差が重なる“Webスタックの地殻変動”です。実務的には、単一ライブラリ更新の枠を超え、RSCという“API化したUIパス”をセキュリティアーキテクチャの一級市民として扱うことが肝要です。検知・遮断・更新の3点を、開発と運用の合同プロセスに格上げしておくことで、次の同型事案でも被害最小化が可能になります。

参考情報

• Tenable: React2Shell: CVE-2025-55182 React Server Components RCE https://www.tenable.com/blog/react2shell-cve-2025-55182-react-server-components-rce

注記: 本稿は公開一次情報に基づく分析です。公式アドバイザリやNVDの更新に伴い、推奨バージョンや緩和策の細目が変動する可能性があります。最新情報の再確認を前提に、パッチ適用と監視強化を運用に組み込むことを推奨します。