- React の CVE-2025-55182 と Next.js の CVE-2025-66478 により、React Server Components Flight プロトコルを介して認証されていないリモート コード実行が可能になります。
- この脆弱性は、RSC ペイロードの安全でないデシリアライゼーションに起因し、カスタム コードを変更せずにデフォルトの React および Next.js 構成が公開されたままになります。
- セキュリティ研究者は、ほぼ 100% のエクスプロイトの信頼性を報告し、パッチが分析されるにつれて大規模な攻撃が発生する可能性があると警告しています。
- 強化された React および Next.js リリースへの即時アップグレードが、特に最大 40% が脆弱である可能性があるクラウド環境では唯一の確実な緩和策です。
の開示 ReactのCVE-2025-55182 そしてその双子の問題 Next.js の CVE-2025-66478 低レベルプロトコルが機能不全に陥った場合、サーバーサイドJavaScriptスタックがいかに脆弱になるかが注目されています。これはニッチなバグではなく、React Server Componentsの中核を揺るがす、最も深刻なリモートコード実行の脆弱性です。 飛行プロトコル 多くの最新アプリが静かに依存しています。
この事件を特に不安にさせるのは デフォルトの設定が公開されている. 生成された単純なNext.jsアプリ create-next-app本番環境向けに構築され、特別なオプションを一切使用せずに導入された は、認証されていないHTTPリクエストによって侵害される可能性があります。複雑な設定ミスや特殊なプラグインは不要で、多くのチームが日々導入している標準スタックで十分です。
CVE-2025-55182とCVE-2025-66478が発見された経緯
問題の根源は React Server Components (RSC) を強化する react-server 実装このパッケージは、クライアントとサーバー間でシリアル化されたコンポーネントデータをやり取りするために使用されるFlightプロトコルの基盤となります。セキュリティ研究者が ラクラン・デイビッドソン 11 月下旬に Meta のバグ報奨金プログラムを通じて不審な行動が報告され、React チームと Meta チームは迅速に対応しました。
公開された勧告によると、この脆弱性は水曜日に公開され、 緊急パッチは約4日以内に発送されましたこれは、このような大規模なエコシステムに影響を与える問題としては異例の速さであり、この欠陥がいかに深刻であるかを強調しています。Reactのメンテナーは、この問題を 10.0のCVSSスコア、可能な限り最大限。
並行して、 Vercel — Next.js を開発する会社 — 同じ根本的なバグがフレームワークにどのような影響を与えたかを分析しました。Next.jsはサーバー上で同じRSC Flightプロトコルを使用しているため、この脆弱性を継承し、独自の識別子が割り当てられました。 CVE-2025-66478Vercel は、攻撃者の攻撃機会を可能な限り短くすることを目的として、React 勧告と同日に警告を発し、パッチをリリースしました。
素早い反応にもかかわらず、 セキュリティベンダーや研究者は、攻撃者が修正プログラムをリバースエンジニアリングする可能性が高いと警告し始めた。 非常に早く、 npmに対するサプライチェーン攻撃パッチを当てたコードが公開されると、バグがどこにあったかを推測し、機能するエクスプロイトを構築することがはるかに容易になります。
React Flight プロトコルでは具体的に何が問題になっているのでしょうか?
技術的なレベルでは、CVE-2025-55182とCVE-2025-66478はどちらも 攻撃者が制御するデータの安全でないデシリアライゼーション Flightプロトコル内で、React Serverコンポーネントは構造化されたペイロードを送受信し、サーバーはそれをデコードして実行フローを駆動するために使用します。
脆弱な論理は react-server パッケージ 受信RSCペイロードの構造と内容を厳密に検証できなかった攻撃者は、意図的に不正な、しかし綿密に作成されたFlightペイロードをReact Server Functionエンドポイントに送信することで、サーバーがそのデータをデシリアライズする際の動作に影響を与えることができます。単に無害なコンポーネントの状態を再構築するのではなく、コードパスを誘導して以下のコードを実行させることができます。 サーバー上の特権JavaScript.
このバグはプロトコルのデコード方法に影響を与えるため、 認証は不要リモート攻撃者は、到達可能なRSCまたはサーバー関数エンドポイントにHTTPリクエストを送信できれば十分です。これにより、この脆弱性は、単純な認証不要のRCEベクトルへと変化します。細工したリクエストを送信し、安全でないデシリアライゼーションを待つだけで、ペイロードがバックエンドで実行される可能性があります。
この問題を独自に分析したWizの研究者は、これを次のように表現している。 論理デシリアライゼーションの脆弱性 単純な解析バグではなく、完全に機能する概念実証エクスプロイトがテストで ほぼ100%の信頼性 脆弱なターゲット上でコード実行をトリガーします。
デフォルトのReactとNext.jsのデプロイメントが危険にさらされている理由
これらのCVEの最も心配な点の一つは、 すぐに使える構成に影響する多くのセキュリティ問題では、エクスプロイトには特定の機能フラグ、あまり使用されていないプラグイン、または非標準のデプロイメントモードが必要です。しかし、今回の場合はそうではありません。
React Server ComponentsとそのFlightプロトコルは、現代のReact 19とNext.jsのアーキテクチャに不可欠な要素となっています。その結果、 生成された標準プロダクションビルド create-next-app アプリケーション開発者が追加コードを書くことなく、攻撃者に悪用される可能性があります。攻撃者はカスタムルートやビジネスロジックを推測する必要はなく、汎用RSCエンドポイントを悪用するだけで十分です。
この欠陥はNext.js自体に限ったことではありません。 RSC Flightプロトコルをサーバーにバンドルまたは再実装します 脆弱性がある可能性があります。公開されている勧告やセキュリティ関連記事では、影響を受けるエコシステムがいくつか指摘されています。
- Next.js、下流に影響を与える最もよく知られたフレームワーク
- Vite RSCプラグイン (
@vitejs/plugin-rsc) - Parcel RSCプラグイン (
@parcel/rsc) - React Router RSC プレビュー
- レッドウッドSDK （よく言及される
rwsdk) - わくわく およびその他のRSC対応ツールチェーン
React自体では、このバグの影響は バージョン 19.0、19.1.0、19.1.1、19.2.0 関連するパッケージのメンテナーは次のように述べている。 19.0.1、19.1.2、または19.2.1へのアップグレード 動作が強化され、脆弱性が解消されます。Next.js には、パッチを適用した React サーバーロジックを統合した、対応する修正リリースがあります。
一部のインフラプロバイダーは影響範囲を明確にしている。例えば、Googleは次のように述べている。 Compute Engine のパブリック OS イメージはデフォルトでは脆弱ではありませんReact や Next.js が既成で出荷されていないため、ユーザーがこれらのフレームワークの影響を受けるバージョンをベースイメージ上にデプロイするとリスクが発生します。
雲全体の爆発半径はどれくらいですか?
ReactとNext.jsが本番環境でどれほど広く使用されているかを見ると、この問題の規模が明らかになります。Reactは、次のような主要プラットフォームのユーザーインターフェースの基盤となっています。 Facebook、Instagram、Netflix、Airbnb、Shopify、Walmart、Asanaなど多数さらに、無数の小規模なアプリや内部ダッシュボードが同じコンポーネントとフレームワークを使用して構築されています。
Wizの脅威インテリジェンスチームはクラウド環境からのテレメトリを分析し、 クラウド展開の約39～40%に脆弱なインスタンスが含まれている ReactやNext.jsのフレームワークと比較すると、Next.jsはおよそ 調査対象環境の69%、そして約 そのうち61%は、公開アプリケーションがその上で実行されている。これらのパーセンテージを合わせると、おおよそ 観測されたクラウド環境の44%は、公開されたNext.jsインスタンスをホストしている。正確なフレームワークのバージョンに関係なく。
人気と脆弱性の重なりこそが、防御側を警戒させる要因です。広く導入されているスタックに、信頼性のあるエクスプロイトパスを持つ、最大深刻度の認証されていないリモートコード実行（RCE）バグが存在する場合、 機会主義的攻撃や標的型攻撃が続くことはほぼ確実である迅速にパッチを適用した組織であっても、無防備なエンドポイントが調査され、侵害される可能性がある短い期間に直面する可能性があります。
最初の暴露の時点では、 確認された実環境での悪用は公に報告されていないしかし、Rapid7やwatchTowrの専門家を含む複数のセキュリティ研究者は、脅威アクターがすでにパッチのリバースエンジニアリングを行い、パッチが適用されていないサービスをスキャンし、自動化された攻撃チェーンを構築していると想定するのが現実的であると強調しました。
研究者やベンダーがエクスプロイトリスクについて語っていること
セキュリティコミュニティからの声明は一貫した見解を示しています。 これは理論的な問題ではない攻撃者にとって参入障壁は低い。watchTowrのCEO、ベンジャミン・ハリス氏はこの欠陥を次のように表現した。 世界で最も普及しているウェブフレームワークの1つを使用するユーザーにとって大きなリスク そして、搾取には「ほとんど前提条件がない」ことを強調した。
Wizの研究者も、脆弱性のあるバージョンとパッチを当てたバージョンの両方をテストした後、同様の評価を下しました。彼らの内部実験では、安全でないデシリアライゼーションを悪用するために細工されたペイロードが、 ほぼ100%の成功率 影響を受けたサーバー上で完全なリモートコード実行を引き起こす可能性がある。また、この攻撃は 完全にリモートで認証なし特別に構築された HTTP リクエストによって完全に駆動されます。
Rapid7の観点からは、 十分な数の人がパッチを解析すれば、技術的な記述や概念実証のエクスプロイトが出てくるだろう。その結果、特にインターネットに接続するアプリが多数存在するクラウド環境に対して、より広範なスキャンと大規模な攻撃の試みが活発化する可能性があります。
ベンダーコミュニティの外でも、 業界メディアは、これらのCVEがインターネットのかなりの部分に影響を及ぼしていると報じている。報告では、その深刻さだけでなく、フロントエンドとサーバーサイドレンダリングにReactとNext.jsに依存している大規模な消費者向けサイト、SaaSプラットフォーム、APIバックエンドの数も強調されています。
緩和策：React および Next.js ユーザーが今すぐ行うべきこと
React または Next.js を本番環境で実行しているチームの場合、メンテナーと研究者からのガイダンスは次の単純な点に集約されます。 パッチを当てたバージョンにアップグレードすることが唯一の確実な解決策であるFlight プロトコルの根本的な安全でないデシリアライゼーション動作を完全に解決できる構成トグルや汎用 WAF ルールは存在しません。
Reactチームは、影響を受けるブランチにいるすべての人に 強化リリース 19.0.1、19.1.2、または 19.2.1 に移行します、 react-server パッケージはアップデートに含まれています。Next.jsについては、Vercelが公開しています。 パッチを当てたRSC処理を統合した修正ビルド管理者は、選択したリリース ラインの最小安全バージョンを決定するために、公式の Next.js アドバイザリを参照する必要があります。
他の組織に依存する RSC対応フレームワーク Redwood、Waku、React RouterのRSCプレビュー、ViteおよびParcel RSCプラグインなどのRSCプラグインを使用する場合は、 対応するリリースノートとセキュリティチャネルを確認してください多くの場合、これらのプロジェクトは React のサーバー コンポーネントを単純にラップまたはバンドルするだけなので、React 自体を更新してから最新のフレームワーク リビジョンを取得する必要があります。
単純なパッチ適用だけでなく、クラウドに特化したツールが利用されています。 脆弱なインスタンスを大規模に探す例えば、Wizのお客様は、Wiz脅威センターのクエリやアドバイザリを利用して、影響を受けるバージョンのReactまたはNext.jsが自社環境に展開されている場所を特定できます。他の組織では、資産インベントリ、SBOMデータ、コンテナスキャンなどを利用して同様の可視性を実現しています。
これらのCVEによってシステムがすでに標的にされたり、侵害されたりしている兆候がある場合は、 インシデント対応サポートが推奨されます一部のベンダーは、CVE-2025-55182 または CVE-2025-66478 の悪用が疑われる顧客に対し、トリアージ、封じ込め、フォレンジックの支援を得るために IR チームに連絡するよう特に勧めています。
これはJavaScriptウェブエコシステムについて何を明らかにするのか
ReactとNext.jsのパッチですぐに穴は塞がれますが、 この事件は、サーバーサイドJavaScriptフレームワークが信頼できないデータをどのように処理するかについて、より広範な疑問を提起している。Flight のようなプロトコルはスタックの奥深くに位置し、開発者が直接検査することはほとんどない抽象化の背後に隠れているため、欠陥が気付かれる前に広範囲にわたる影響を及ぼす可能性があります。
事実 デフォルトで出荷され、頻繁に宣伝される構成で脆弱な動作 また、開発者エクスペリエンスとデフォルトで安全な設計との間の緊張関係も浮き彫りになっています。サーバーコンポーネントやクライアントとサーバー間のシームレスなシリアル化など、最新のアプリ開発を容易にする機能は、ひそかに複雑な攻撃対象領域を生み出す可能性があります。
セキュリティチームにとって、この事件は フレームワークレベルの脆弱性は、瞬時に組織全体の露出につながる可能性がある一般的なオープンソース コンポーネントの 1 つのバグが、特にコンテナーとテンプレートが再利用される場合、数十の個別のアプリケーション、マイクロサービス、および内部ツールの中心に現れる可能性があります。
良い面としては、ReactのメンテナーであるMetaとVercelからの反応が、 大規模な生態系でも協調的な情報開示と迅速なパッチ開発は可能である明確な勧告、バージョン管理された修正、セキュリティベンダーとの連携により、競合する多くの脆弱性の中で、防御側はこの問題を優先することができました。
今後、多くの観察者は、 Webフレームワークにおけるシリアル化、デシリアル化、プロトコル解析ロジックCVE-2025-55182 および CVE-2025-66478 により、Flight などのコンポーネントに対するより体系的なテストと厳格な検証が促進されれば、深刻なインシデントから長期的なセキュリティ上のメリットが生まれる可能性があります。
今のところ、ReactまたはNext.jsスタックを実行しているチームは、 パッチの展開と攻撃者の自動化最大深刻度の RCE がデフォルト構成、広範なクラウド環境、高信頼性の悪用手法に影響を及ぼすことがすでに研究で実証されているため、これらの環境を安全に保つには、組織が脆弱性のある場所をいかに迅速に特定し、すべてを強化されたリリースに移行できるかが重要になります。
