Skip to main content

セキュリティアドバイザリ:React Server Componentsの重大なRCE脆弱性(CVE-2025-55182)

blog feature security alert purple

2025年12月3日

0 分で読めます

概要

2025年12月3日、複数のReact 19およびNext.jsのリリースに、React Server Components(RSC)の「Flight」プロトコルにおける重大な欠陥があることが、関係各所から公表されました。この欠陥により、認証なしでリモートコード実行(RCE)が可能になります。脆弱性の原因は、サーバー側でRSCペイロードを処理する際の、攻撃者が制御するデータの安全でないデシリアライゼーションです。
攻撃には細工したHTTPリクエストだけで十分で、デフォルト設定でも高い確実性で悪用できます。影響を受けるのはReact/Next.jsだけでなく、RSC実装を組み込んだあらゆるフレームワークやバンドラーです。
パッチが公開されており、直ちに適用する必要があります。未修正バージョンを実行しているシステムは、サーバー全体を侵害される危険にさらされています。

更新(2025年12月5日):

この脆弱性を最初に報告したLachlan Davidsonが、最初のPoCをGitHubで公開しました。

影響を受けたコンポーネントの概要

React Server Components(RSC)と「Flight」プロトコル

React 19では、クライアントとサーバーでUIのレンダリングを分担し、コンポーネントの状態やサーバー関数の呼び出しを、「Flight」プロトコルと呼ばれることの多い専用の転送形式でシリアライズする仕組みが導入されました。

影響を受けるパッケージ:

  • react-server-dom-webpack

  • react-server-dom-parcel

  • react-server-dom-turbopack

これらのパッケージは、サーバー側の処理を振り分けるために受信したRSCペイロードをデシリアライズします。デシリアライゼーションのロジックで構造や型の制約が十分に適用されていなかったため、悪意のあるペイロードによって実行動作を改変できることが脆弱性の原因です。

デフォルト設定が影響を受けた理由

Next.js App Routerを含め、RSCを採用するほとんどのフレームワークでは、このロジックがデフォルトで有効になっています。そのため、create-next-appで作成し、コードを変更せずにビルドしてデプロイした標準的なNext.jsプロジェクトも、デフォルト設定のままで悪用可能でした。

判明している事象のタイムライン

日付

事象

2025年11月29日

セキュリティ研究者のLachlan Davidsonが、Server FunctionエンドポイントでReactがペイロードをデコードする方法に関する欠陥を非公開で報告し、認証なしでRCEに至る経路を特定。

2025年11月30日

Metaのセキュリティチームが報告内容を検証し、Reactエンジニアリングチームと協力して修正を策定。

2025年12月1日

パッチが作成され、主要なエコシステムやホスティングプロバイダーが緩和策の実装とアップデートの検証を開始。

2025年12月3日

Meta/Reactチームが、React RSCパッケージを対象とするCVE-2025-55182のセキュリティアドバイザリを公開。

2025年12月3日

Vercelが、同じ根本的な欠陥のNext.js統合部分を対象とするCVE-2025-66478のアドバイザリを公開。

2025年12月3日

React(19.0.1 / 19.1.2 / 19.2.1)およびNext.js(修正済みの15.x/16.xとCanaryユーザー向けのダウングレード手順)の更新版が一般公開。

2025年12月3日以降

各エコシステムでパッケージのアップデート(Vite RSC、Parcel RSC、React Routerのプレビュー版、RedwoodSDK、Wakuなど)が続く。調査も継続中。

2025年12月4日

CVE識別子CVE-2025-66478は却下され、CVE-2025-55182に置き換えられました

注:公表時点で実環境での悪用は公に確認されていませんが、悪用に高度な技術はほとんど必要ありません。

影響を受けるコンポーネント

影響を受けるReactのバージョン

  • 19.0.0

  • 19.1.0

  • 19.1.1

  • 19.2.0

影響を受けるNext.jsのバージョン

  • 安定版15.xの全バージョン

  • 安定版16.xの全バージョン

  • 14.3.0-canary.77以降の実験版

RSCをバンドルしているため、影響を受ける可能性が高いその他のツールやフレームワーク:

  • Vite RSCプラグイン

  • Parcel RSCプラグイン

  • React Router RSCプレビュー

  • RedwoodSDK

  • Waku

  • 脆弱性のあるreact-server-dom-*モジュールを組み込んだすべてのパッケージ

クラウド環境における影響範囲

調査によると、スキャン対象となったクラウド環境の約39%で、脆弱なバージョンのReact/Next.js RSCを実行するワークロードが確認されました。

インシデントの発生原因

根本的な脆弱性:安全でないデシリアライゼーション

問題の根本には、サーバー側のRSCエンジンが次の情報を記述したシリアライズ済みの「Flight」ペイロードを受け入れる点があります。

  • コンポーネントの境界

  • サーバー関数の参照

  • データストリーム

脆弱な実装は、受信したデータ構造を過度に信頼していました。不正な形式でありながら構文上は有効なペイロードが送信されると、サーバーは次のような状態になりました。

  1. 想定外のオブジェクト構造や参照を拒否できない

  2. 攻撃者が提供した識別子を処理する

  3. 外部から実行されることを想定していない、特権的なJavaScript処理を実行する

これにより認証前のリモートコード実行が直接可能となるため、CVSSスコアは10.0(重大)です。

攻撃経路

  • リモート:ローカルアクセスや認証情報は不要

  • 認証不要:誰でも攻撃を試みることが可能

  • 1回のリクエスト:RSCエンドポイントへの細工したHTTPリクエストだけで十分

  • 高い信頼性:テストでは、デフォルト設定でほぼ100%の信頼性が報告されています

特に危険な理由

  • App Routerを使用するNext.jsアプリの大半では、RSCエンドポイントが公開されています。

  • RCEはルーティングロジックや認証ゲートより前に発生します。

  • クラウドやサーバーレス環境では、RSCエンドポイントがAPIの公開領域のルートに配置されていることがよくあります。

検出とスキャンの推奨事項

コード/依存関係スキャナーの場合

次の項目を確認してください:

  • "react-server-dom-webpack"のバージョン19.0.0、19.1.0、19.1.1、19.2.0

  • "react-server-dom-parcel"のバージョン19.0.0、19.1.0、19.1.1、19.2.0

  • "react-server-dom-turbopack"のバージョン19.0.0、19.1.0、19.1.1、19.2.0

  • 影響を受けるバージョンのセクションに記載されているNext.jsのバージョン

ランタイム/ネットワークレベルの監視の場合

次の項目を検知してください:

  • 不正な形式、または想定外のRSC Flightフレームを含む、RSCルートへのリクエスト

  • シリアライズされたRSCペイロード内のエントロピーが高いトークンや異常なトークン

  • サーバー関数の呼び出しエラーの急増

クラウドポスチャーツールの場合

次の構成でデプロイされているワークロードを探してください:

  • 2025年12月3日より前にビルドされたコンテナ

  • まだパッチが適用されていないReact 19またはNext.js 15/16のイメージ

  • App Routerまたはサーバーアクションを使用する、一般公開中のワークロード

Vercelでホストされているアプリは、プラットフォームレベルのリクエストフィルタリングの恩恵を受けられますが、アップグレードも必要です。

緩和策

1. 直ちにアップグレードする

React

  • 19.0.0 → 19.0.1

  • 19.1.x → 19.1.2

  • 19.2.0 → 19.2.1

Next.js

修正済みバージョン:

npm install next@15.0.5
npm install next@15.1.9
npm install next@15.2.6
npm install next@15.3.6
npm install next@15.4.8
npm install next@15.5.7
npm install next@16.0.7
  • Canaryユーザー → 14.3.0-canary.77以降を使用している場合は、安定版にダウングレードしてください:

npm install next@14

2. アップグレード後にアプリケーションを再ビルドする

CI/CDパイプラインで、修正済みの依存関係を使ってDockerイメージまたはサーバーレスバンドルを再ビルドしてください。

3. サードパーティ製フレームワークを検証する

Redwood、Waku、実験的なRSCプレビュー、またはバンドラーを使用している場合は、次の点を確認してください:

  • 更新済みのRSC実装が提供されている

  • 古いロックファイルによって脆弱なバージョンが固定されていない

4. 多層防御の対策を有効にする

  • サーバーサイドJavaScriptのランタイムサンドボックス化

  • RSCエンドポイントの厳格なルーティング

  • 不正な形式のRSCペイロードを検知するWebアプリケーションファイアウォール(WAF)ルール

コミュニティが取るべき次の対応

関連エコシステムのメンテナー向け

  • 独自のRSC拡張を監査する

  • 更新版のアドバイザリと修正済みビルドを公開する

  • 明示的な検証を伴うデシリアライゼーションスキーマの強化を検討する

組織向け

  • React Server Componentsを使用するすべてのワークロードを棚卸しする

  • インターネットに公開されているアプリを優先する

  • パッチ適用までの期間における不審な活動を監視する

  • パッチ適用後にフォレンジック調査を実施し、悪用されていないことを確認する

まとめ

このインシデントは、現代のJavaScriptエコシステムが抱える構造的な課題を浮き彫りにしています。動的なシリアライゼーション機構は、検証が不十分な場合、強力なRCE攻撃の経路になり得ます。React Server Componentsはさまざまなフレームワークの基盤として急速に普及しているため、この脆弱性の影響範囲は異例なほど広大です。

今回の問題へのパッチ適用は容易ですが、対応が遅れるほどリスクは大幅に高まります。組織は今すぐアップグレードし、依存するフレームワークを確認するとともに、エコシステムの調査が進むなかで今後の更新情報を継続的に確認してください。

修正を先延ばしにしないでください。Snykのアドバイザリを確認し、影響を受けるバージョンと詳細な修正方法をチェックしましょう:

Snyk Vulnerability DBをチェック

信頼できるデータと実用的なインサイトで、安全なソフトウェア開発を支援します。