2025年12月、React Server Componentsを支える通信プロトコル「React Flight Protocol」に、認証を一切経由せずにサーバー上で任意のコードが実行されてしまう深刻な脆弱性が明らかになりました。研究者コミュニティでは「React2Shell」と呼ばれ、CVE-2025-55182（React）およびCVE-2025-66478（Next.js）として登録されています。特別な設定ミスがなくてもデフォルト状態のまま影響を受け、事前の認証情報やユーザー操作を必要としないという特徴から、React／Next.jsを本番運用しているすべてのチームにとって無視できない問題となりました。
本記事では、この脆弱性がなぜ発生したのか、React Flight Protocolの仕組みに踏み込んで技術的に解説するとともに、実際に自社のシステムを守るために今すぐ着手すべき対策と、再発を防ぐための恒久的な体制づくりまでを整理します。攻撃コードやPoCの実行手順には触れず、あくまで防御・対策の観点に絞って解説します。
React2Shellとは何か – 脆弱性の全体像
React2Shellは、React Server Components（RSC）のシリアライズ／デシリアライズ機構である「React Flight Protocol」のコア処理に存在した欠陥に起因する脆弱性群の総称です。関連するCVEは次の通りです。
- CVE-2025-55182：Reactのreact-server-dom系パッケージ（webpack／parcel／turbopack向け）に存在するリモートコード実行につながる脆弱性
- CVE-2025-66478：Next.js側で同様の問題を引き起こすルート
- CVE-2025-55184／CVE-2025-67779：後日追加で公開された、サービス拒否（DoS）につながる関連脆弱性
深刻度を際立たせる3つの特徴
この脆弱性が業界内で大きく取り上げられた理由は、以下の3点に集約されます。
- ゼロ設定で影響を受ける：特殊なオプションを有効化していない、標準的な構成のアプリケーションがそのまま対象になります。
- 事前認証が不要：認証情報、セッショントークン、ユーザー操作を一切必要とせず、外部から到達可能なエンドポイントに対してリクエストを送るだけで攻撃が成立し得ます。
- 攻撃成功率がほぼ100%：条件が揃えば高い確率で攻撃が成功するとされ、偶発的な失敗に頼った運任せの防御が期待できません。
認証の「手前」でリクエストが処理されてしまう性質を持つため、通常であればログイン画面やAPIキー検証で守られているはずの領域が、事実上無防備な状態に置かれてしまう点が最大の問題です。
発覚から公表までのタイムライン
本脆弱性が公になっていく過程は、次のような時系列で進みました。
- 2025年12月4日：非公式に、完全なリモートコード実行（RCE）を実現するエクスプロイトが公開される
- 2025年12月5日：研究者によるオリジナルの概念実証（PoC）が公開される
- 2025年12月9日：JFrog Security Research Teamが継続して状況を追跡していることが報告される
- 2025年12月12日：関連するDoS脆弱性であるCVE-2025-55184およびCVE-2025-67779が公開される
攻撃コードが先行して出回り、その後に公式な脆弱性情報が整理されていくという展開は、対応にあたるエンジニアリングチームにとって極めて厳しい状況を生みます。攻撃者側の情報流通が先行する局面では、CVE番号や修正版の発表を待つのではなく、影響範囲の洗い出しと暫定対応を並行して進める判断力が求められます。
技術的な仕組み – なぜ認証をすり抜けられるのか
React Flight Protocolの役割
React Server Componentsは、サーバー側でレンダリングされたコンポーネントツリーをクライアントへ届けるために、独自のシリアライズ形式でデータをストリーミング転送します。この転送に使われる仕様が「React Flight Protocol」です。サーバーコンポーネントが返すJSXツリーや関数参照、Promiseなどの複雑なデータ構造を、クライアント側のReactランタイムが再構築できる形式に変換し、逆にクライアントからサーバーへ渡されるServer Actionsの引数なども、同様の仕組みでシリアライズ・デシリアライズされます。
デシリアライズ処理そのものに存在した欠陥
今回問題となったのは、このFlight Protocolの「コアとなるデシリアライズ処理ロジック自体」に存在した欠陥です。RSCのアーキテクチャでは、クライアントから送られてきたペイロードを、アプリケーションのコードが呼び出される前に、フレームワーク内部のランタイムがまずデシリアライズして復元します。この復元処理の過程に不備があったため、細工されたペイロードを送り込むことで、意図しない処理を実行させることが可能になっていました。
アプリケーション独自の認証ロジックより先に処理されてしまう問題
通常、Webアプリケーションの安全性は「リクエストを受け取る → 認証・認可を確認する → ビジネスロジックを実行する」という順序が守られていることを前提にしています。しかし本脆弱性では、攻撃者が送り込む悪意あるペイロードが、アプリケーション独自の認証ミドルウェアやガード処理よりも「前段」にあるフレームワーク内部のデシリアライズ処理で解釈されてしまいます。つまり、開発者がどれだけ堅牢な認証ロジックをアプリケーション層に実装していても、その手前にあるプロトコル処理そのものが突破口になってしまうということです。これが「事前認証不要」「ゼロ設定で影響を受ける」という深刻な特徴に直結しています。
なお、JFrog Security Research Teamがこの欠陥をどのような手順・ツールで具体的に解析したかという詳細な調査プロセスは、参照した情報の範囲では明らかにされていません。公表されている事実として確度を持って言えるのは、上記の「デシリアライズ処理の欠陥」という原因の所在と、それがもたらす影響範囲の広さです。技術的な原因を正確に理解した上で、次章以降の対策を優先度高く実施することが重要です。
影響を受けるバージョンの詳細
脆弱性の対象となるパッケージとバージョン範囲は次の通りです。自社プロジェクトの依存関係と照らし合わせ、該当有無を確認してください。
react-server-dom-webpack / parcel / turbopack
- 脆弱バージョン：19.0.0、19.1.0〜19.1.1、19.2.0
- 修正バージョン：19.0.1、19.1.2、19.2.1
Next.js
- 脆弱バージョン：15.0.0〜15.0.4、15.1.0〜15.1.8、15.2.0〜15.2.5、15.3.0〜15.3.5、15.4.0〜15.4.7、15.5.0〜15.5.6、16.0.0〜16.0.6
- 修正バージョン：15.0.5、15.1.9、15.2.6、15.3.6、15.4.8、15.5.7、16.0.7
App RouterでReact Server Componentsを利用しているNext.jsアプリケーションはもちろん、react-server-dom系パッケージを直接利用する独自フレームワーク構成であっても対象になり得ます。バージョン範囲が広く、複数のマイナーバージョン系列にまたがって影響しているため、「少し前のバージョンだから大丈夫」という思い込みは禁物です。
放置した場合に起こりうるリスク
この脆弱性を放置した場合に想定される実害は、単なる情報漏えいにとどまりません。
- サーバー内部への任意コード実行による、機密情報・環境変数・APIキーの窃取
- 侵入した基盤を踏み台にした社内ネットワークへの水平展開
- 関連するDoS脆弱性（CVE-2025-55184、CVE-2025-67779）によるサービス停止・可用性の喪失
- 攻撃成功率の高さゆえの自動化された大規模スキャン・一斉攻撃の対象化
- 顧客データを扱うサービスであれば、コンプライアンス違反や信用毀損に発展するリスク
特に「事前認証不要」という性質は、インターネットに公開されているNext.jsアプリケーションであれば規模の大小を問わず標的になり得ることを意味します。スタートアップの小規模サービスであっても軽視できません。
今すぐ実施すべき対策
1. 修正済みバージョンへのアップグレード
最優先の対策は、影響を受けるパッケージを修正済みバージョンへ引き上げることです。まずは依存関係のバージョンを確認します。
npm ls next react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack該当バージョンが確認できたら、修正版へ更新します。
# Next.js を修正済みバージョンへ更新する例
npm install next@latest
# react-server-dom系パッケージを個別に固定する場合の例
npm install react-server-dom-webpack@19.2.1更新後は、必ずステージング環境でビルド・動作確認を行ってから本番環境へ反映してください。特にServer Actionsやストリーミングレンダリングを多用している場合は、回帰テストを重点的に実施することを推奨します。
2. アップグレードが困難な場合の代替策
依存関係の都合などで即座にアップグレードできない場合、Next.jsアプリケーションについては、React Server Componentsを前提としないPages Routerへの移行が緩和策として挙げられています。ただし大規模な構成変更を伴うため、恒久対策というよりも「アップグレードまでの一時的な回避策」として位置づけ、並行して本来のアップグレード作業を進めるべきです。
3. 暫定的な検知・遮断の強化
アップグレード作業と並行して、次のような防御層を強化しておくことも有効です。
- WAF（Web Application Firewall）で、RSCのFlightペイロードを想定した異常なリクエストパターンを検知・遮断するルールを検討する
- アプリケーションサーバーのアクセスログ・エラーログを監視し、通常見られない大量の異常リクエストやクラッシュの兆候がないか確認する
- 外部公開が不要なエンドポイントについては、リバースプロキシやネットワークACLで到達性そのものを制限する
再発防止のための恒久対策
依存関係の脆弱性監視を仕組み化する
今回のように、フレームワークのコア部分に存在する脆弱性は、アプリケーションコードのレビューだけでは検知できません。次のような仕組みをCI/CDパイプラインに組み込み、日常的に監視することが重要です。
npm auditやDependabot、Snykなどの依存関係スキャンツールを定期実行し、新規CVEの公開を検知したら即座に通知が届く体制を作る- React・Next.jsのリリースノートやセキュリティアドバイザリを購読し、メジャー・マイナーアップデートの追従サイクルを短くする
- 本番稼働中のバージョンを一覧化した台帳を整備し、脆弱性報告が出た際に自社の影響有無を即座に判定できるようにする
サーバーコンポーネントを扱う上での設計原則
React Server ComponentsやServer Actionsのようにサーバー・クライアント間の境界が薄いアーキテクチャでは、フレームワーク内部の通信プロトコルそのものが攻撃対象になり得るという前提に立った設計が求められます。
- フレームワークやランタイムのバージョンを最新の安定版に保つことを、機能開発と同じ優先度のタスクとして扱う
- 最小権限の原則に基づき、アプリケーションサーバーの実行ユーザー権限や、環境変数・シークレットへのアクセス範囲を必要最小限に絞る
- 本番環境と開発環境でネットワークセグメントを分離し、仮に一台が侵害されても被害が水平展開しにくい構成にしておく
- 侵害を前提にした監視体制（EDR、異常検知、改ざん検知）をあわせて整備し、脆弱性対応が完了するまでの「もしも」に備える
今すぐ確認したいチェックリスト
- □ 自社のNext.js／Reactのバージョンを確認し、影響範囲の一覧と照合したか
- □ react-server-dom-webpack／parcel／turbopackの利用有無とバージョンを確認したか
- □ 修正済みバージョンへのアップグレード計画とスケジュールを立てたか
- □ ステージング環境での動作検証手順を用意したか
- □ アップグレードが即座に困難な場合の暫定緩和策（WAFルール、ログ監視、ネットワーク制限など）を検討したか
- □ 依存関係の脆弱性を自動検知する仕組み（Dependabot等）が有効になっているか
- □ 侵害の兆候（不審なプロセス、異常な外部通信、想定外のエラー多発）を監視する体制があるか
- □ 今回の対応内容と教訓を社内のインシデント対応記録として残したか
まとめ
React2Shell（CVE-2025-55182、CVE-2025-66478ほか）は、React Server Componentsの根幹を支えるReact Flight Protocolのデシリアライズ処理に起因し、アプリケーション独自の認証ロジックが機能する前段で攻撃が成立してしまうという、極めて深刻な脆弱性でした。ゼロ設定・事前認証不要・高い攻撃成功率という3つの特徴は、React／Next.jsを利用するあらゆる規模の組織にとって座視できないリスクです。
対応の第一歩は、自社の依存バージョンを正確に把握し、修正済みバージョンへ速やかに更新することです。そのうえで、依存関係の脆弱性監視を仕組み化し、フレームワークのコア部分にも脆弱性が潜み得るという前提でセキュリティ設計を見直すことが、次に同種の問題が発生した際の被害を最小化する鍵となります。技術の進化とともに攻撃対象領域も変化し続けることを踏まえ、継続的なアップデートと監視体制の維持を組織的な取り組みとして根付かせていきましょう。
コメント