- React の CVE-2025-55182 と Next.js の CVE-2025-66478 により、React Server Components Flight プロトコルを介して認証されていないリモート コード実行が可能になります。
- この問題は、細工された RSC ペイロードの安全でないデシリアライゼーションに起因し、一般的なフレームワークのデフォルト構成に影響を与えます。
- 研究者は、ほぼ 100% のエクスプロイトの信頼性を報告しており、クラウド環境の約 39～40% に脆弱なインスタンスが含まれていると推定しています。
- 強化された React および Next.js リリースへの即時アップグレードが唯一の確実な緩和策です。防御者は RSC 対応フレームワークも監査する必要があります。
ここ数日、JavaScriptエコシステムは2つの問題に取り組んできました。 最大深刻度のセキュリティ脆弱性 ReactとNext.jsに存在する脆弱性により、影響を受けるサーバー上でリモートコード実行が可能になります。 CVE-2025-55182 Reactと CVE-2025-66478 Next.js では、React サーバー コンポーネントが、いわゆる Flight プロトコルで特殊なネットワーク トラフィックを処理する方法に重点を置きます。
これらの問題は デフォルトのフレームワーク構成 細工されたHTTPリクエストだけで実行できるため、多くのセキュリティチームのパッチリストのトップに急速に躍り出ました。ベンダー、研究者、クラウドプロバイダーは、今すぐパッチを適用し、脆弱性を評価し、広範囲にわたるスキャンとエクスプロイトの試みに備えるという共通のメッセージに今や一致しています。
CVE-2025-55182とCVE-2025-66478の実際の内容
問題の核心は、 react-server パッケージReact Server Components（RSC）とFlightプロトコルを支えるコンポーネントです。脆弱なバージョンでは、サーバーは特殊な形状のRSCペイロードを受け入れ、 適切な検証を行わずにデシリアライズする攻撃者が制御するデータがサーバー上で実行されるロジックに干渉できるようになります。
この動作により、構造化データであるべきものが 特権JavaScriptを実行するための手段 バックエンドで。HTTPリクエストが悪意のあるフライトペイロードを含むRSCまたはサーバー関数エンドポイントをターゲットとした場合、安全でないデシリアライゼーションパスが悪用され、認証されていないリモートコード実行（RCE）が発生する可能性があります。事前のアクセス、資格情報、またはユーザーによる操作は必要ありません。
React側の問題は次のように追跡されています。 CVE-2025-55182CVSSスコア10.0で最高評価を得ています。Next.jsはこれらのプリミティブの上にRSCとFlightプロトコルを実装しているため、同じコアの弱点、つまり下流への影響が CVE-2025-66478 同じ深刻度評価を持ちます。
セキュリティ勧告ではこのバグを次のように説明している。 論理デシリアライゼーションの脆弱性 これは典型的なメモリ安全性の問題ではありません。問題はペイロードの解析と信頼方法にあり、低レベルのバッファ処理にはありません。しかし、結果は同様に深刻です。リモート攻撃者がサーバー側の実行を制御できるのです。
脆弱なReactとNext.jsの設定
脆弱性の影響 React 19のサーバーサイドスタック 一般的に導入されているいくつかのバージョンで、19.0、19.1.0、19.1.1、19.2.0などのリリースが脆弱性を抱えていると指摘されています。 react-server パッケージとそのフライトプロトコル実装。パッチを当てたブランチは以下のように配布されます。 19.0.1、19.1.2と19.2.1これにより、強化されたデシリアライゼーション ロジックが導入されます。
フレームワーク側では、 Next.jsはそのままで影響を受ける. 生成された典型的なアプリケーション create-next-app本番環境向けに構築され、デフォルト設定でデプロイされたReactは、開発者が追加コードを追加することなく悪用される可能性があります。そのため、Next.jsを開発するVercelは、CVE-2025-66478に基づく独自のアドバイザリを発行し、修正されたReactパッケージを使用するフレームワークの更新バージョンをリリースしました。
影響はNext.jsだけに留まりません。 React Serverコンポーネントにバンドルまたはプラグインする Flightプロトコルが危険にさらされている可能性があります。これには、以下のようなツールやフレームワークが含まれます。
- Next.js
- @vitejs/プラグイン-rsc （Vite RSCプラグイン）
- @parcel/rsc （パーセルRSCプラグイン）
- React Router RSC プレビュー
- レッドウッドSDK / rwsdk
- わくわく
研究チームは、 デフォルト設定は一般的に危険にさらされているつまり、開発者が意図的に実験的なフラグや異常な設定を有効にしなかったとしても、影響を受けるバージョンの React Server Components を使用している場合、そのデプロイメントは依然として悪用される可能性があります。
エクスプロイトがどれほど容易か、そしてなぜ防御側が懸念しているのか
セキュリティコミュニティを不安にさせているのは、 搾取の障壁が低い複数の研究グループによると、これらの脆弱性を攻撃するには、アクセス可能なRSCまたはサーバー機能のエンドポイントに、特別に細工されたHTTPリクエストを送信するだけで済みます。認証、複雑な前提条件、ユーザーによる操作は不要であるため、このシナリオは自動化された攻撃にとって特に魅力的です。
制御されたテストでは、Wiz Researchなどのチームが概念実証エクスプロイトを構築し、 ほぼ100%の信頼性 脆弱な環境でリモートコード実行（RCE）を引き起こす。これらの完全なペイロードはまだ公開されていないものの、根本的な動作は単純であるため、公開パッチを研究することで、実際に動作するエクスプロイトを再現できるという見解が一致しています。
ReactとNext.jsの人気を考えると、多くの専門家は 大量スキャンと兵器化は時間の問題だ技術的な詳細やサンプルコードが地下コミュニティや公開リポジトリで流通すると、悪用が急増した、他の影響の大きいサーバー側の脆弱性と早期に比較できます。
研究者らはまた、 潜在的なターゲットの幅Reactは、ソーシャルメディア、eコマース、ストリーミング、SaaSなど、大規模組織のウェブサイトやアプリの基盤となっています。Next.jsなどのフレームワークは、社内アプリケーションと顧客向けアプリケーションの両方で広く使用されているため、脆弱なインスタンスは企業ネットワークの奥深くだけでなく、一般公開されているフロントエンドにも出現する可能性があります。
多くの勧告が発表された当時、 野生での悪用に関する確認された報告はないしかし、アナリストらは、脅威の攻撃者がすでに修正プログラムをリバースエンジニアリングし、どのホストがアクセス可能で誤って設定されているかを特定していると想定するのが妥当だと述べています。
クラウド環境全体での露出の広がり
クラウド規模のスキャンから得られたいくつかのデータポイントは、問題の規模を示しています。Wizの脅威ハンターは、約 クラウド環境の39% 彼らが分析したReactまたはNext.jsのインスタンスには、CVE-2025-55182および/またはCVE-2025-66478に脆弱なバージョンを実行しているものが含まれていた。他の内訳を見ると、この数字は 両方の技術を合わせると40％.
Next.jsに特化して見ると、フレームワーク自体はおよそ 環境の69% 彼らのデータセットでは、大多数のホストが 公開アクセス可能なアプリケーション Next.jsで構築されています。言い換えれば、彼らのテレメトリによると、 クラウド環境全体の44% 現在パッチが適用されているかどうかに関係なく、インターネットに公開されている Next.js インスタンスが少なくとも 1 つ必要です。
この組み合わせ 高い展開密度と公開露出 攻撃者がどの脆弱性に注力すべきかを判断する際に、まさにこの情報に注目します。単一のエクスプロイトチェーンは、類似した設定を持つ多くの標的に対して大規模に再利用される可能性があり、自動化ツールはIPアドレス範囲全体をスキャンしてパッチ未適用のサーバーを見つけることもできます。
一部のプロバイダーは、影響範囲を狭める取り組みを行っています。例えば、Googleは デフォルトのパブリックOSイメージ Google Cloud の Compute Engine で使用されるイメージは、そのままでは脆弱ではありませんが、顧客はそれらのイメージ上に展開するアプリケーションを監査してパッチを適用する必要があります。
ベンダーが提供するもの ウェブアプリケーションファイアウォール（WAF） 議論に加わっているのも事実です。例えばCloudflareは、トラフィックが完全にサービス経由でルーティングされている場合、WAFが一部のReactアプリケーションを悪用攻撃から保護するのに役立つと示唆していますが、このような保護は基盤となるソフトウェアの更新に代わるものではなく、追加レイヤーとして捉えるのが適切です。
タイムライン、発見、ベンダーの対応
CVE-2025-55182 と CVE-2025-66478 をめぐる一連の出来事は急速に展開しました。 セキュリティ研究者ラクラン・デイビッドソン React が React Server Function エンドポイント宛のペイロードをデコードする方法に問題があることを特定し、11 月末に Meta のバグ報奨金プログラムを通じて報告しました。
もともと Meta で開発され、現在では多くの最新 Web スタックの基礎となっている React は、この報告が確認されるとすぐに動き出しました。 約4日以内にReact チームは Meta と連携して、影響を受ける 19.x ラインに対する緊急アップデートを発行し、即時アップグレードを促すセキュリティ アドバイザリも発行しました。
同じ日に、 ヴァーセルは独自の勧告を発表した CVE-2025-66478 に基づき、Next.js の脆弱性が修正されました。フレームワークのメンテナーは、パッチリリース、ユーザー向けガイダンス、そして Next.js の RSC 実装が React のサーバーライブラリから脆弱な動作を継承する仕組みの詳細を公開しました。
公的な記事の多くは意図的に ステップバイステップのエクスプロイトの詳細を省略 今のところは、リスクの説明、影響を受けるコンポーネントとバージョンの一覧表示、そしてユーザーへの最新ビルドへの誘導に注力しています。その目的は、防御側が修正プログラムを適用する時間を確保し、それほど高度な技術を持たない攻撃者の攻撃を遅らせることです。
watchTowrやRapid7などの企業の研究者を含む業界の声は、これが React または Next.js を本番環境で実行しているすべての人にとって優先度の高い問題そして、その脆弱性が公に明らかになるまでの期間は短いかもしれない。
チームが今すべきこと
React Server Components、Next.js、またはRSC対応のプラグインやフレームワークを使用している組織にとって、最も明確なガイダンスは次のようになります。 強化バージョンへのアップグレードが唯一の完全な緩和策である脆弱なリリースを維持しながらバグを安全に無効化する構成トグルは存在しません。
React側では、19.0、19.1.0、19.1.1、19.2.0などの影響を受ける19.xビルドから 19.0.1、19.1.2、または19.2.1プロジェクトがどのブランチに固定されているかによって異なります。これらのバージョンでは、Flightプロトコルのペイロードに関するより厳格なチェックが組み込まれており、安全でないデシリアライゼーション動作が排除されています。
Next.jsユーザーの場合、推奨されるのは パッチ適用されたフレームワークリリースへのアップデート Vercelのアドバイザリで発表されたこの脆弱性により、依存関係ツリーが修正されたReactサーバーパッケージを確実にプルするようになりました。プロジェクト自身のコードでRSCを明示的に使用していない場合でも、フレームワークがサーバーコンポーネントを内部的に有効化している場合、RSCが露出する可能性があります。
Redwood、Waku、React Router RSCプレビュー、ViteおよびParcelのRSCプラグインなど、他のRSC対応スタックに依存しているチームは、 公式チャンネルを監視する これらのプロジェクトから。多くのプロジェクトは独自のReactサーバーランタイムをバンドルしているため、メンテナーは具体的なアップデート手順とバージョン番号を公開しています。
大規模なクラウドフットプリントを持つ組織にとって、脆弱な部分がどこに存在するかを把握するのは困難です。Wizなどのセキュリティベンダーの中には、次のようなサービスを提供しています。 事前に構築されたクエリとアドバイス 顧客が環境全体で影響を受けるReactおよびNext.jsインスタンスを特定できるよう、プラットフォーム内で対策を講じています。また、社内のセキュリティチームが適応できるよう、検出ロジックとスキャンルールを公開している企業もあります。
これがウェブエコシステム全体に及ぼす影響
CVE-2025-55182とCVE-2025-66478の出現により、 サーバーサイドJavaScriptフレームワークは複雑なシリアル化形式を処理するRSC と Flight プロトコルは、最新のアプリケーションを構築するための強力なツールですが、高度な機能を可能にする柔軟性によって、解析ロジックが慎重にロックダウンされていない場合、巧妙な攻撃対象領域が生じる可能性もあります。
開発者にとって、このエピソードは次のことを思い出させてくれる。 デフォルトのフレームワークの動作に依存しても安全性は保証されない そして、防御の重要性 npmに対するサプライチェーン攻撃このケースでは、通常の定型的な設定でアプリケーションが認証されていないリモートコード実行（RCE）の危険にさらされる可能性がありました。セキュリティアドバイザリの遵守、依存関係のピン留め、そして迅速なアップデート適用は、ReactやNext.jsベースのサービスを提供するチームにとって、もはや譲れないタスクになりつつあります。
防御の観点から、組織はこの出来事を利用して、 階層化された保護戦略パッチ適用は最優先事項ですが、多くの企業は、管理エンドポイントや内部エンドポイントへのアクセス制御の強化、疑わしい Flight プロトコル トラフィックを検出するための WAF ルールの導入、エクスプロイトの試みを示唆する可能性のあるサーバー側エラーの観測性の向上も検討しています。
この状況は、インターネットが現在、比較的少数の 共有オープンソースコンポーネント広く普及しているライブラリにたった1つのバグがあると、わずか数日でクラウドプロバイダー、SaaSプラットフォーム、そしてエンタープライズ環境に波及する可能性があります。これほど多くの組織が一度に影響を受ける場合、協調的な情報開示、ベンダーによる迅速な対応、そして明確なコミュニケーションが不可欠です。
今のところ、脆弱性のあるReactとNext.jsのインストールを修正リリースに導入することに重点を置いています。 搾取が日常的になる研究者らがほぼ完璧なエクスプロイトの信頼性を報告していること、デフォルト設定が脆弱であること、そしてクラウド環境の相当数が影響を受けるバージョンを実行していることから、これらの CVE は、わかりにくいプロトコルの詳細から、最新の JavaScript アプリケーションを保守するチームにとって差し迫った運用上の懸念事項へと急速に変化しました。
