- CVE-2025-55182 および CVE-2025-66478 は、React Server Components Flight プロトコルを介して認証されていないリモート コード実行を可能にします。
- この欠陥は、RSCペイロードの安全でないデシリアライゼーションにあります。
react-server実装、デフォルト構成に影響します。 - Next.js やその他の RSC ベースのフレームワークもこの問題を継承しており、クラウドでホストされるアプリの大部分が危険にさらされています。
- ベンダーは強化されたアップデートをリリースしています。React、Next.js、その他の RSC フレームワークをアップグレードすることが、唯一の信頼できる緩和策です。
の発見 ReactのCVE-2025-55182 とその仲間 Next.js の CVE-2025-66478 現代のWeb開発業界全体に明確な警告が発せられました。これらの問題により、React Server Components（RSC）を使用するサーバーや、RSCの「Flight」プロトコルを実装したフレームワークは、完全に標準的な設定で動作している場合でも、認証されていないリモートコード実行の危険にさらされる可能性があります。
この状況を特に厄介にしているのは、 攻撃者がほとんど労力を必要としない 脆弱性を武器化する：脆弱なエンドポイントを狙った細工されたHTTPリクエストは、サーバー上で任意のコードを実行するのに十分な可能性があります。クラウド環境の大部分がReactとNext.jsに依存しているため、管理者と開発者がパッチを適用する必要性は強調しすぎることはありません。
CVE-2025-55182 と CVE-2025-66478 を理解する
CVE-2025-55182はコアバグに関するものである。 会場は react-server パッケージは、React Server Componentsとその「Flight」プロトコルを支えるコンポーネントです。このパッケージは、サーバー側でレンダリングされたコンポーネントがクライアントにストリーミングされる際に使用される特殊なペイロードの処理を担っており、これは新しいReact 19エコシステムの中核となるメカニズムです。
並行して、 CVE-2025-66478はNext.jsへの影響を捉えているはReact Server Componentsを統合し、同じ基盤プロトコルを再利用しています。Next.jsはこのRSCインフラストラクチャ上に直接構築されているため、プロトコルのあらゆる弱点は、次のようなツールでブートストラップされたNext.jsアプリケーションを含む、典型的なNext.jsアプリケーションにすぐに継承されます。 create-next-app.
どちらの識別子も 重大な、認証されていないリモートコード実行の脆弱性セキュリティ チームは、これらの脆弱性を最大の深刻度スコアで評価しました。これは、脆弱性の技術的な影響だけでなく、複雑な前提条件なしに実際の展開シナリオで悪用される可能性があるという事実も反映しています。
研究者らはまた、影響を受けた行動は デフォルトで有効 多くの構成で発生します。つまり、アプリケーションが特別なパターンを使用したり、リスクの高いオプションを追加したりしなくても、脆弱性が悪用される可能性があります。既存のRSCベースのスタックを採用するだけで、脆弱性が継承される可能性があります。
舞台裏では、問題は RSCペイロードが受け入れられ、処理されます サーバー側のロジックによって。信頼できない入力を徹底的に検証・制限する代わりに、デシリアライズプロセスは攻撃者が制御するデータによってサーバー上の実行パスを形成することを可能にしてしまうのです。
フライトプロトコルがRCEへの道となる仕組み
根本的な原因 React サーバーコンポーネントの CVE-2025-55182 これは、RSC「Flight」プロトコルの処理における論理的なデシリアライゼーションの欠陥です。RSCは、コンポーネントツリー、プロパティ、サーバーアクションを記述するために特殊なワイヤフォーマットを使用しており、サーバーはこれらをエンコードし、クライアントはレンダリングの一環としてデコードします。
サーバーが 悪意を持って形成されたフライトペイロード本来であれば、そのデータのすべての部分を信頼できないものとして扱うべきです。ところが、脆弱な実装では、この入力を、権限のあるサーバー側の動作に実質的に影響を与えるような方法で処理してしまいます。安全でないデシリアライズ処理は、悪意のあるデータと、完全なサーバー権限で実行されるJavaScriptコードとの間の橋渡しとなります。
セキュリティ研究者はこの種の問題を次のように説明している。 安全でない逆シリアル化アプリケーションが複雑な入力構造を受け取り、そこからオブジェクトまたは実行フローを再構築しますが、再構築されたオブジェクトに許可される操作について強力な保護対策を講じていません。この場合、攻撃者が任意のコードパスに実行を誘導する余地が生じます。
テスト中、研究チームは エクスプロイトを試みる際のほぼ完璧な信頼性概念実証攻撃は、機会主義的な悪用を防ぐために完全には公開されていませんが、ほぼ100%の成功率でリモートコード実行を実現することが示されています。唯一の実用的な要件は、細工されたHTTPリクエストを公開されたRSCエンドポイントに送信できることです。
したがって、この攻撃は リモートおよび認証なし有効なセッション、漏洩したトークン、事前の足掛かりは必要ありません。公開されているNext.jsやその他のRSCベースのアプリは更新されておらず、脆弱性がある場合は侵入される可能性があります。
誰が、何が影響を受けるのか
脆弱性は コア react-server 実装その影響はReact自体やNext.jsにとどまらず、RSCを同様の方法でバンドルまたは統合するあらゆるフレームワークに及んでいます。これにより、潜在的なリスクの範囲は、単一のライブラリやベンダーがメンテナンスする製品よりもはるかに広範囲に及んでいます。
公開された分析では、 最も顕著なダウンストリームターゲットとしてのNext.js人気とRSCとの深い統合を考えると、これは大きな問題です。Wiz Researchが収集したデータによると、クラウド環境のかなりの割合で、脆弱性のある範囲に該当するバージョンのReactまたはNext.jsが実行されており、Webのサーバーサイドレンダリングインフラストラクチャの重要な部分が危険にさらされています。
これらの評価からの推定によると、 クラウド環境の39%～40% これらのCVEの影響を受けるReactまたはNext.jsのインスタンスが少なくとも1つ含まれています。Next.js自体はこれらの環境の多くに存在し、多くの場合、インターネットに直接公開されている公開アプリケーションで利用されています。
Next.jsを超えて、 react-serverパッケージを埋め込んだフレームワークやツール RSCをサポートするもの、またはRSCが潜在的に危険にさらされているもの。フラグが付けられた例には以下が含まれます。
- Next.jsRSC 対応バージョンでは、
- Vite RSCプラグイン サーバー コンポーネントのサポートを提供します。
- Parcel RSCプラグイン 統合された React サーバー コンポーネントを備えています。
- React Router RSC プレビュー または実験的なリリース。
- レッドウッドSDK RSC 機能を使用した実装。
- わくわく および同様の RSC 駆動型フレームワークが登場しています。
クラウドプラットフォームベンダーは、それぞれの視点から爆発半径を明確にし始めています。例えば、 Googleは、Google Cloudの標準パブリックOSイメージが Compute Engine 向けの RSC スタックは、デフォルトでは脆弱な RSC スタックを含んでいません。ただし、ユーザーがこれらのイメージ上に独自の React または Next.js アプリをデプロイした場合、パッチを適用する責任はユーザーにあります。
なぜリスクが極端だと考えられるのか
いくつかの特徴が組み合わさって CVE-2025-55182およびCVE-2025-66478 特に防御側にとって懸念される点です。まず、攻撃対象領域はRSCのネットワーク通信に深く関わっているため、多くの環境では一般的なHTTPトラフィック経由でアクセス可能です。サーバーにアクセスするために特殊な機能を有効にする必要はなく、標準的な構成で十分です。
第二に、 デフォルト設定は脆弱である 影響を受けるRSCプロトコルを使用する一般的なアプリの場合。推奨された既成のツールとベストプラクティスに依存していた開発者は、何もカスタマイズせずに、知らず知らずのうちに影響を受けるアプリケーションを展開していた可能性があります。
3 番目に、攻撃が成功した場合の影響は極めて深刻です。 サーバー上での完全なリモートコード実行攻撃者がこのレベルに到達すると、通常、任意のコマンドを実行したり、環境のより深い場所に侵入したり、データを盗み出したり、アプリケーションロジックを改ざんしたりすることが可能になります。サービスが緊密に統合されているクラウドネイティブ環境では、こうした攻撃はすぐにより広範な侵害へと発展する可能性があります。
セキュリティ研究者らは、 パッチとアドバイザリは公開されています敵対者が変更をリバースエンジニアリングして独自のエクスプロイトを構築するのは時間の問題です。 npmのセキュリティに関するガイド.
最後に、 ReactとNext.jsの圧倒的な普及 本番環境ではリスクが増大します。Reactはインターフェース構築に最も広く利用されているJavaScriptライブラリの一つであり、Next.jsはサーバーレンダリングやハイブリッドアプリの定番フレームワークとなっています。ニッチなコンポーネントのバグであれば比較的影響が抑えられていたかもしれませんが、RSCのバグはWebスタックの大部分に影響を及ぼします。
ベンダーとセキュリティチームからの回答
脆弱性が特定されると、開示プロセスは迅速に進みました。 セキュリティ研究者のラクラン・デイビッドソン氏がこの欠陥を報告した。 11月下旬、Metaのバグ報奨金プログラムを通じてReactチームに通知されました。この早期通知により、メンテナーは問題を調査し、強化されたリリースを準備し、Next.jsなどの下流フレームワークとのガイダンスを調整することができました。
Reactのメンテナーはそれ以来 Reactとreact-serverパッケージの更新バージョンをリリースしました Flightプロトコルにおける安全でないデシリアライゼーション動作を修正しました。これらの強化ビルドは、RSCペイロードをより安全に処理するように設計されており、以前は信頼できないデータによってサーバー側の実行が指示されていたコードパスを閉鎖します。
ヴェルセルと Next.jsチームは独自の勧告を発行した影響を受けるバージョンとユーザーによるアップデート方法を詳細に説明しています。目標は、チームが影響を受けるデプロイメントを特定し、パッチ適用済みのリリースに移行できるようにすることであり、これには一般的なツールで作成されたアプリも含まれます。 create-next-app.
守備面では、 Wiz Researchおよびその他のセキュリティベンダー 組織がクラウド環境全体で脆弱なインスタンスを検出できるよう、分析、スキャン、クエリを公開しています。例えばWizは、欠陥のあるRSC実装に依拠しているReactとNext.jsのインストールを検出するための、事前構築済みのクエリと脅威センターのアドバイザリを追加しました。
インシデント対応コミュニティの専門家は、一部の組織が直面する可能性に備えている。 現実世界の搾取の試みセキュリティ企業は、CVE-2025-55182またはCVE-2025-66478に関連する標的型攻撃が疑われるチームに対し、 対応専門家を迅速に派遣する理想的には、攻撃者が足場を固める前に。
開発者とオペレーターのための即時の措置
React Server Componentsで構築されたWebアプリケーションを担当するチームにとって、 強化されたリリースへのアップグレードが唯一の信頼できる緩和策である脆弱性はプロトコル自体の処理方法に埋め込まれているため、構成の微調整だけでは、通常の RSC 機能を維持しながらリスクを完全に排除することは難しいでしょう。
実用的 対応計画 組織の場合は次のようになります。
- すべてのReactおよびNext.jsアプリケーションをインベントリする主な公開サイトだけでなく、内部ツールや目立たないサービスも含まれます。
- RSC を使用するかバージョンに依存する展開を特定する React と Next.js はベンダーのアドバイザリによって脆弱であるとフラグ付けされています。
- React、react-server、Next.js のアップグレード バージョン固有のガイダンスに従って、メンテナーによってリリースされた強化バージョン。
- 他のRSC対応フレームワークを確認する Vite および Parcel 用の Redwood、Waku、RSC プラグインなど、メンテナーがリリースしたらすぐに更新を適用します。
- ログとテレメトリを確認する RSC エンドポイントの周囲で、調査や悪用の試みを示唆する可能性のある異常な、不正な、または疑わしいリクエストを検出します。
クラウドセキュリティツールを使用する組織は、 ベンダー提供の検出コンテンツを活用する このプロセスを加速します。例えば、Wizが提供するクエリは、マルチクラウド環境全体で脆弱なパッケージやフレームワークを見つけるのに役立ち、見落とされたサービスが無防備なままになる可能性を低減します。
可能であれば、チームは以下も検討するとよいでしょう。 RSCエンドポイントの露出を一時的に制限する パッチ適用中は、アクセス制御、レート制限、アプリケーションファイアウォールなどの追加レイヤーの背後に侵入するようにしてください。これらの対策は完全な修正ではなく、一時的な対策ですが、攻撃者にとっての機会を減らすのに役立ちます。
注目度の高いRCEの場合と同様に、 重要な資産の周囲の監視 も同様に重要です。プロセス作成、アプリケーションサーバーからのアウトバウンドネットワーク接続、予期しない構成変更における異常を警告することで、攻撃の成功を早期に検出できます。
ウェブエコシステムへの長期的な影響
の出現 React の CVE-2025-55182 と Next.js の CVE-2025-66478 また、新しいWebプラットフォーム機能の設計と展開方法についても、より広範な議論が巻き起こっています。サーバーサイドレンダリングとサーバーコンポーネントは、パフォーマンスと開発者エクスペリエンスの向上を約束しますが、同時に、比較的少数のプロトコルとライブラリに多くの機能と複雑さを集中させています。
この事件から得られる教訓の一つは シリアル化とデシリアル化の層は特に精査する必要がある複雑なオブジェクトを再構築したり、信頼できないソースからの構造化されたペイロードを解釈したりするメカニズムは、検証が不完全な場合、深刻なバグの原因となる可能性があります。RSCに類似したパターンを採用するフレームワークが増えるにつれて、コードレビュー担当者やセキュリティ監査担当者は、これらの境界にさらに重点を置くようになるでしょう。
潜在的な影響の規模は、 オープンソースのエコシステムは、迅速かつ協調的な対応に依存している 重大な欠陥が見つかった場合、React、Next.js、クラウドプロバイダー、セキュリティベンダーは、迅速に連携し、パッチ、ドキュメント、検出ツールを公開する必要がありました。こうした連携により、開示から修復までの時間が大幅に短縮され、全体的な被害を軽減することができます。
同時に、この事件は デフォルト設定は現実世界のリスクを形作る可能性がある強力な機能がデフォルトで有効化され、広く採用されると、その機能に何らかの脆弱性があると、ほぼ一夜にしてシステム全体の問題となります。将来のフレームワーク設計では、デフォルトで安全な動作、オプトインによる高度な機能の利用、あるいはより明確なセキュリティ上のトレードオフに重点が置かれる可能性があります。
最後に、開発チームは自らの サーバー駆動型機能の脅威モデル化これまで十分に防御されていると感じられた環境でも、認証されていないリクエストがサーバー側のレンダリング パスに影響を与える可能性があるため、セキュリティ チームは長年の想定に疑問を抱き、より堅牢なテストに投資する必要に迫られることになります。
コミュニティがこれらの脆弱性を消化し続けるにつれて、 迅速な行動 RSC の使用状況にパッチを適用し、監視と再評価を行うことで、より強力な立場を築くことができます。CVE-2025-55182 と CVE-2025-66478 への対応は、単に 1 つのバグを修正するだけではありません。現代の Web スタックがいかに相互に関連しているかを改めて認識させ、それらが依存する基盤を注意深く監視することがいかに重要であるかを改めて認識させるものです。
