Reactのサーバーは驚くほど脆弱です

Reactのサーバーサイドセキュリティとの不安定な休戦がついに破綻しました。React Server Componentsの重大なリモートコード実行（RCE）バグが発覚した数日後、さらに2つの重大な脆弱性が見つかりました。それは完全なサービス拒否（DoS）攻撃とサーバーアクションのソースコード漏洩です。両方の脆弱性は、Reactの新しいサーバーサイドアーキテクチャとReact Flightプロトコルというまったく同じ実験的な領域に影響を及ぼしています。

これは難解なチェインフォーバグのような悪用ではありません。単一の認証されていないHTTP POST リクエストがあなたのアプリを停止させたり、サーバーのアクションコードをクライアントに吐き出させたりする可能性があります。Better Stackの「React Got Hacked, Again」デモでは、カスタムサーバーアクションがゼロの状態で、1つの巧妙に作成されたリクエストによってオフラインにされた標準のNext.js 16.0.8アプリが示されています。

DoSの脆弱性は、React Flightがチャンクデータを逆シリアル化する方法を悪用します。チャンク0 → チャンク1、およびチャンク1 → チャンク0を接続することで、サーバーは無限解決ループに陥り、CPUが過負荷になり、基本的なGETリクエストさえ処理できなくなります。CVE-2025-55184およびCVE-2025-67779はそれぞれ7.5（高）と評価され、React 19.0.0–19.2.0に搭載された同じRSCプラミングに影響を与えます。

その背後には、CVE-2025-55183があり、もう一つの簡単なPOSTでサーバーアクションのソースコードを暴露します。デシリアライザーを騙してサーバー関数の参照を自分自身の引数として渡させることで、Reactは関数を文字列化し、その実装をHTTPレスポンスで返すことになります。CVSS 5.3の評価は、そのコードがビジネスロジックや誤って取り扱われた秘密を埋め込んでいる場合のリスクを過小評価しています。

最も警戒すべきは、12月3日の以前のRCEパッチがこれらの2つのバグに対して何も効果がないことです。「Reactが再度ハッキングされた」に止まってその修正を適用するだけでは、あなたのアプリは依然として一パケットのDoS攻撃やコード露出に対して脆弱です。ReactチームのReact Blogも明確にこう述べています：すぐにアップグレードしてください。

Reactのサーバー時代に対する scrutiny は現在、非常に厳しくなっています。React Server Components、Server Actions、そしてReact Flightプロトコルは根本的に優れた開発体験を約束しますが、2週間以内に発生した3件のCVEは厳しい疑問を投げかけています。このスタックに基づいて構築されたライブラリやフレームワーク—Next.js、React Router、Waku、Redwood、カスタムRSCプラグイン—は、これらを孤立したバグではなく、エコシステム全体に関わるインシデントとして扱う必要があります。

不正なHTTPリクエストがReactサーバーを静かに圧迫する可能性があります。セキュリティ研究者は、認証されていないクライアントがプロセスを無限にハングさせることを可能にするReactサーバーコンポーネントの高危険度DoS脆弱性（CVSS 7.5）を明らかにしました。負荷がかかると、そのようなリクエストがいくつかあればCPUコアが100%に固定され、全体のデプロイメントが応答しなくなる可能性があります。

バグの中心には React Flightプロトコル があり、これはReactがコンポーネントツリーやサーバーアクションを「チャンク」としてストリーミングするために使用するワイヤフォーマットです。各チャンクは、`"$1"` のようなドル記号の表記を使用して別のチャンクを参照でき、デシリアライザーに「チャンク1を取得し、最終的な値が得られるまで解決を続ける」と指示します。健全なサーバーでは、このチェーンは最終的に具体的なオブジェクトまたはプリミティブに到達します。

攻撃者は、決して解決されないPOSTボディを送信します。サイクリックグラフを作成することで、チャンク`0`がチャンク`1`を指し、チャンク`1`が再びチャンク`0`を指すようにします。これにより、デシリアライザーの参照に対する信頼を悪用します。特別なツールは必要なく、攻撃的なJSONまたはマルチパートデータを含む単一のPOSTをサーバー関数のエンドポイントに向けるだけで、ループが引き起こされる可能性があります。

ReactのFlight実装は、終端値に達するまで各`"$n"`ポインタをたどりながらチャンク参照を再帰的に処理します。脆弱なバージョンは、堅牢なサイクル検出を行わないため、リゾルバーは永遠に同じ2つのチャンクを追い続けます。この無限ループはリクエストハンドラー内で発生するため、Node.jsのイベントループや同等のランタイムスレッドは他のクライアントにサービスを提供するために戻ることがありません。

Next.js 16.0.8のデモアプリでは、Better Stackがリアルタイムで影響を示します。特定のPOSTリクエストが原因で最初の接続が20秒以上停止し、その後の全てのGETリクエストが`/`でタイムアウトします。外部から見るとサイトは「ダウン」しているように見えますが、コンテナやVMは「実行中」と報告され、CPUは一つの毒されたリクエストで無駄に稼働しています。

爆風半径は思ったより大きいです。React自身のアドバイザリーでは、react-server-dom-webpackおよびその関連ライブラリ（Parcel、Turbopack）がバージョン19.0.0～19.2.0でリストされており、これはNext.js 15.xおよび16.x、React RouterのRSCサポート、Waku、RedwoodのSDK、およびさまざまなバンドラープラグインを支えています。React Server Componentsをサポートするアプリは、脆弱なデシリアライザーを継承します。

最も憂慮すべきことは、豪華なサーバーアクションに参加しなくても、攻撃を受ける可能性があるということです。Better Stackは、カスタムアクションやビジネスロジックが全くない状態で、標準の `create-next-app` プロジェクトに対するDoS攻撃を示しています。もしランタイムがサーバー関数のエンドポイントを公開している場合、敵対的なPOSTリクエストによって、そのデフォルトインストールが自己DoSボタンに変わる可能性があります。

Reactの2つ目の新しいバグは、サーバーがクラッシュしたときよりも静かですが、それでも不安を呼び起こします。巧妙に作成されたPOSTリクエストによって、バックエンドが攻撃者に自らのソースコードを文字通り引用してしまいます。CVE-2025-55183は、CVSS 5.3（中程度）に ratedされ、React Server ComponentsとNext.jsのサーバーアクションを対象とし、ReactのFlightプロトコルが関数参照をデシリアライズする方法を悪用します。

データを狙う代わりに、攻撃者は挙動を狙います。フライトワイヤーフォーマットを悪用することで、デシリアライザにサーバーアクション関数を同じ関数への引数として渡すように仕向けることができます。型チェックはトリガーされず、認証のバイパスも必要なく、通常のリクエストのように呼び出しが進行します。

ここでJavaScriptはあなたに逆らいます。関数が文字列に強制変換されると（テンプレートリテラル、連結、または明示的な`toString()`を介して）、JavaScriptのデフォルトのFunction.prototype.toString()は関数のソースコードを返します。もしあなたのサーバーアクションが引数をログに記録し、それをレスポンスに挿入したり、テキストとして保存したりすると、フレームワークは忠実にHTTPレスポンスに関数本体全体を埋め込んでしまいます。

Better Stackのデモでは、データベースに書き込む`submitName`サーバーアクションが、1回の悪意のあるPOSTによってその全実装をエコーしてしまいます。ペイロードは引数を`$F`「サーバー関数」参照としてマークし、その参照を`submitName`関数自体に戻します。Reactがチャンクを解決すると、関数は自らを`name`パラメーターとして受け取り、文字列化が行われるとコードが漏洩します。

範囲的には、これは即時の資格情報ダンプではありません。適切に扱われた環境変数（`process.env`やプラットフォーム固有の設定を介してアクセスされる）は、直接漏洩することはありません。なぜなら、脆弱性はソースを露出させるものであり、ランタイムメモリを露出させるものではないからです。APIキー、トークン、またはパスワードをサーバーのアクションにハードコーディングしなければ、それらの秘密は手の届かないところに保たれます。

失うものはビジネスロジックです：データベースクエリ、フィーチャーフラグ、独自のアルゴリズム、内部コメントがすべて見えるようになります。攻撃者はあなたのデータモデルをマッピングし、権限の仮定を推測し、よりターゲットを絞った攻撃を準備することができます。Reactのアドバイザリー「Reactサーバーコンポーネントにおけるサービス拒否とソースコードの露出」でも、この問題は知的財産およびアプリケーションマッピングの問題であり、直接的なRCEではないことが強調されています。

Reactの修正はほとんど恥ずかしいほど小さなものです。このパッチは、サーバー参照のデフォルトの`toString()`を、常に`"function /* emitted code */"`を返すスタブで上書きし、関数値とその元のソーステキストとのリンクを断ち切ります。

Reactの最近のRCE、新たなDoS、そしてソースコード流出は、すべて一つの重力の中心、「React Flight」を囲んでいます。3つの異なるCVE、3つの異なる影響—リモートコード実行、サーバーの完全なハング、そしてサーバーアクションの開示—それでも、すべてがFlightがHTTP経由でデータをデシリアライズする方法を悪用しています。Meta自身のアドバイザリーが「React Server Componentsパッケージ」を静かに指摘しているとき、それは実際にはFlightのワイヤーフォーマットを弱点として指摘しているのです。

React Flightは、コンポーネントツリーをHTMLではなくデータとしてストリーム配信するために存在します。サーバー上で、Reactはツリーを走査し、要素、プロパティ、および参照を説明する一連の「チャンク」を出力します。クライアントまたは別のサーバーでは、Reactがこれらのチャンクを取り込み、ツリーを再構築します。このストリーミング設計は、Next.js 15/16、React Router、WakuなどのReactサーバーコンポーネント（RSC）の土台となっています。

各チャンクにはIDと、特別な"$"表記を使用して他のチャンクを参照できるJSONのようなペイロードが含まれています。例えば、`"$1"`のような値は「このフィールドは実際にはチャンク1に存在するものです」、一方で`"$f1"`は「これはID1のサーバー関数の参照です」と解釈されることがあります。それからFlightはこれらの参照をたどり、それらを最終的なオブジェクトグラフに解決し、Reactがレンダーするか、サーバーアクションを呼び出すのに使用できるようにします。

その間接的な手法は非常に強力です。これにより、Reactは部分的なツリーをストリーミングしたり、コンポーネントを遅延的にハイドレートしたり、サーバー関数をそのコードを送信するのではなくIDで渡したりできます。しかしそれは、デシリアライザーがネットワークから来る任意の`"$"`参照を信頼し、追跡しなければならないことも意味します—まさに問題が発生した部分です。

DoSの脆弱性は、非常に小さなサイクルを作成することで悪用されます。チャンク0はチャンク1を指し、チャンク1は再びチャンク0を指します。12月11日のパッチ以前は、Flightはこれらの`"$"`ポインタを永遠に追い続け、Node.jsプロセスを無限ループに固定し、単一の認証されていないPOSTを完全なサービス拒否に変えてしまいました。Reactの修正では、サイクルトラッキングとハードリミット（1,000回のデリファレンス）を追加し、そこで中断します。

ソースコードの漏洩は同じメカニズムに基づいていますが、`"$f1"`というサーバー関数の参照を使用します。攻撃者は、ターゲットのサーバーアクションへの参照を自身の引数の位置に密輸することによって、Reactに文字列が必要な場所に関数オブジェクトを渡すよう強制します。JavaScriptの暗黙の`toString()`が関数に対して呼び出されると、その関数のソースコードが正しく返され、Flightはそれをクライアントにシリアライズして戻します。

先週のRCEと合わせて、これらのバグはFlightの`"$"`参照システムがRSCの魔法の中心である一方で、最も広範な攻撃面であることを示しています。すべてのクロスチャンクポインタは、サーバーが信頼し、遍歴し、防御しなければならないグラフを拡大します。

Reactの今回のバグに関するパッチの経緯は、実際のインシデント対応訓練のように展開しています。Metaのバグバウンティを通じてDoS脆弱性の報告が寄せられた後、チームは初期の修正を急いでリリースしました。この修正は巧妙なアプローチを試みたもので、React Flightのデシリアライズ中に探索されたすべてのチャンク参照を追跡し、再度見た参照に戻る際には、それを歩き続けるのを止め、既存のIDを再利用するというものでした。

最初のパッチがリリースされたが、研究者たちはそれが無限ループへのすべての道を閉じていないことをすぐに示した。「チャンク0 → チャンク1 → チャンク0」のような循環構造は、依然としてデシリアライザーを病理的な動作に追い込み、Node.jsプロセスを20秒以上占有する可能性があった。その結果、第2のアドバイザリー、第2のCVE、そしてNext.js、React Router、Wakuなどのエコシステムに新しいビルドを投入するための第2の緊急対応が必要となった。

Reactの第二の試みは洗練さを捨て、率直でテスト可能な保証を目指しました。最終的なDoS修正は、Flightリゾルバーの内部にハードコードされたサイクル保護カウンターを追加します。デシリアライズが参照を1000回以上繰り返すとエラーが発生し、リクエストが中止されます。この単一の整数制限—1000—は、無限のアルゴリズムリスクを予測可能な失敗モードに変えます。

対照的に、ソースコード漏洩のパッチはほとんど恥ずかしいほど簡単に感じられます。このバグは、サーバーアクション関数をその自身の引数として渡し、その引数を文字列に変換することで発生しました。JavaScriptでは、この操作により関数のソースが返されます。Reactは現在、サーバーリファレンスに対してデフォルトの`toString()`をカスタム実装でオーバーライドし、常に`function /* 省略されたコード */`のような汎用的な文字列を返すようにしています。

その一行の行動変化が、全体のエクスプロイトチェーンを無力化します。攻撃者はシステムを騙して参照を文字列化させることはできますが、彼らが見るのはプレースホルダーテキストだけで、独自のロジックやハードコードされた秘密は見えません。プロトコルの全面的な見直しや大規模なリファクタリングは不要で、ただ安全なデフォルトが提供されます。

これらのパッチは、リアクティブセキュリティとプロアクティブデザインの間の緊張を浮き彫りにしています。React Flightの複雑さは、圧力の下でエレガントで正式に検証された防御策の余地をほとんど残していなかったため、チームは実用的なガードレールを提供しました：マジックナンバーとより安全な`toString()`です。これは機能しますが、攻撃者がそれを実装の詳細ではなく攻撃面として扱い始めると、高い複雑性を持つシリアル化プロトコルがどれほど脆弱になるかをも強調しています。

React開発者は、これを通常のパッチではなく、火災訓練のように扱う必要があります。影響範囲は、`react-server-dom-webpack`、`react-server-dom-parcel`、または`react-server-dom-turbopack`を介してReact 19.0.0～19.2.0を使用しているすべてのアプリに及びます。あなたのスタックがReact Flightと連携している場合、他に証明するまで曝露していると見なしてください。

フレームワークから始めましょう。Next.js 15.x および 16.x の App Router と RSCs は、サーバーアクションを一度も書いていなくても対象となります。Waku、RedwoodJS（RSCを使用したRedwood SDK）、および実験的なReact Router RSCの統合も、同じ脆弱なプロトコルの上にあります。

このチェックリストを使って、リスクを迅速に評価してください： - 本番環境でReact 19.0.0–19.2.0を使用していますか？ - `dependencies`に`react-server-dom-*`パッケージがありますか？ `devDependencies`だけではありませんか？ - Next.js App Router (13.4+)、Waku、RedwoodJS、またはRSC対応のルーターを使用していますか？ - サーバーアクションまたはサーバー関数のエンドポイントを公開インターネットに公開していますか？ - 認証されていないクライアントがそれらのエンドポイントにPOSTリクエストを送信できますか？

RSCやApp Routerに「はい」と答えると、高リスクのDoS（CVE-2025-55184、CVE-2025-67779）にさらされることになります。この攻撃はRSCの逆シリアル化が有効になっているだけで、カスタムサーバーアクションを定義しているかどうかは関係ありません。サイクリックチャンク参照があれば、Nodeプロセスが停止し、他のすべてのリクエストが飢餓状態に陥ります。

ソースコード露出バグ（CVE-2025-55183）からのリスクはわずかに減少しました。サーバーアクションが必要で、攻撃者は特定のエンドポイントを狙って、サーバーに関数の本体を文字列化させる必要があります。それでも、独自のロジックや関数に直接ハードコーディングした秘密情報が漏洩します。

正確なアップグレードパスやパッチバージョンについては、Vercelのセキュリティ ブルテン: CVE-2025-55184 および CVE-2025-55183を、React Blogのサービス拒否とソースコード露出に関するアドバイザリーと併せてお読みください。次回のデプロイの前に両方を必ず目を通してください。

デシリアライズバグはめったに注目を集めないが、セキュリティチームは静かにそれらを現代ソフトウェアにおける最も厄介な欠陥の一つとして位置づけている。アプリが外部から構造化データ—JSON、バイナリブロブ、シリアライズされたオブジェクト—を受け取り、それを生きたオブジェクトに変換する際には、信頼できない入力が潜在的な実行経路となる。React Flightは、受信データが正しく動作すると仮定して焼き直されたシステムの長いリストに新たに加わった。

セキュリティベンダーは何年も前からこれについて警告しています。トレンドマイクロは、不正なデシリアライズを「主要な攻撃ベクター」と呼んでいます。なぜなら、それはしばしばフレームワークの深い部分に位置し、アプリケーションコードから遠く離れているため、攻撃者は混乱を引き起こすために奇妙なペイロードを一つ用意するだけで済むからです。OWASPは依然としてデシリアライズの問題を最上級のリスクとして挙げており、これはそれが定期的にRCEやデータ漏洩、または完全な障害につながるためです。

Java開発者はこれを辛い経験から学びました。Log4Shell 災害 (CVE-2021-44228) は、攻撃者が制御する文字列をJNDIルックアップにデシリアライズするロギング機能から始まり、最終的には何百万ものサーバーでの任意コード実行につながりました。それ以前には、Apache Commons CollectionsなどのライブラリにおけるJavaのシリアル化バグが、巧妙に作成されたオブジェクトを「信頼された」デシリアライザに与えることによって、数年にわたりガジェットチェーン攻撃を引き起こしていました。

ウェブスタックは同じパターンを繰り返しています。PHPのunserialize、Pythonのpickle、RubyのMarshal、.NETのBinaryFormatter、そして今のReact Flightのチャンクプロトコルはすべて、攻撃者が形作るデータから複雑なオブジェクトグラフを再構築するという根本的な問題を共有しています。そのグラフがコード、リソース、または再帰的な構造を参照できる場合、それを悪用する人が必ず現れます。

防御は敵対的な心構えから始める必要があります。クライアントが制御するペイロード（HTTPボディ、クッキー、ヘッダー、WebSocketフレーム）は、デフォルトで悪意のあるものと仮定してください。デシリアライズを行う前に、次のことを強制してください：

• 1厳格なスキーマ検証（型、許可されているフィールド、サイズ制限）
• 2整合性チェック（HMAC署名、ノンス、バージョンタグ）
• 3ネストの深さ、参照チェーン、及び総ペイロードサイズに対する厳格な上限

より安全な設計は、一般的なオブジェクトのデシリアライズを完全に避けます。任意のクラスや関数ではなく、シンプルなデータ型にマッピングされる、狭くバージョン管理されたフォーマットを優先してください。より複雑な構造をデシリアライズしなければならない場合は、そのコードパスを分離し、監査および計測を行い、誰かが次のLog4Shellや次のReact Flight CVEに変えてしまう前に奇妙なグラフを早期に発見できるように、十分に積極的なログ記録を行ってください。

セキュリティ研究はあまり華やかに見えることはありませんが、今回のバグの波には明確な主人公がいます：アンドリュー・マクファーソン、GMOフラットセキュリティのRyotaK、そしてビットフォレストの野村慎作の3人です。彼らは皆、12月初旬にMetaのバグバウンティパイプラインを通じて発見を報告しました。これは、ReactがReact Server Componentsの重大なRCEに対する修正を出した数日後のことでした。

CVE-2025-55182のRCEが2023年12月3日に公開されると、React Flightプロトコルへの注目が高まりました。12月7日から11日の間に、研究者たちは独自にサービス妨害ループ（CVE-2025-55184、後にCVE-2025-67779が追加）とソースコード露出バグ（CVE-2025-55183）を発見し、すべて同じデシリアライズ機構内で確認されました。

Reactの公式ポストモーテムは、Reactブログでこのパターンを直接認めています。「主要な脆弱性は、ほぼ常に同じ領域での第二の発見の波を引き起こします」とチームは述べており、1つの不変条件が破れた瞬間、研究者も攻撃者も近くのすべての糸を引っ張り始めると主張しています。

そのダイナミクスは、ここで高速で展開されました。マクファーソンは、サーバー機能が文字列に変わることでコードが漏れ出す可能性に焦点を当て、一方のリョータKとノムラは、Flightの参照解決を掘り下げて、プロトコルを話す任意のNode.jsプロセスをフリーズさせる可能性のある簡単な無限ループにぶつかりました。

オープンソースのダイナミクスはこの圧力を増幅させました。Reactのサーバー内部はGitHubに存在しており、RCEパッチが適用されると、セキュリティエンジニア、ツールベンダー、趣味者たちがコミットの差分を調べ、入力をファズテストし、Next.js 15.xおよび16.xアプリに対して不正なFlightストリームを再生し始めました。

バグバウンティの経済性は、そのエネルギーを正しい方向に向けさせるのに役立ちました。Metaのプログラムは、Reactのエコシステム内の問題に対して報酬を支払うため、研究者たちは最初のCVE以降もプロトコルに留まる経済的かつ評判上の理由を持っていました。この組み合わせ—透明なコード、公開されたインシデント、構造化された報酬—は、1つの壊滅的なバグをReactのサーバースタックが明らかに必要としていた完全な構造監査に変えました。

ステップ1は特定です。ステージングや「誰も使っていない」内部ツールを含め、どのアプリ、サービス、環境が脆弱なReact Server DOMの部分を実行しているかを正確に把握する必要があります。まずは、自分のリポジトリで`react-server-dom-`やそれをバンドルしているフレームワーク（Next.js 15.x/16.x App Router、Waku、RedwoodJS、またはカスタムRSC統合）を検索してください。

`package.json` とロックファイル（`package-lock.json`、`yarn.lock`、または `pnpm-lock.yaml`）を開いてください。もし `19.0.0` と `19.2.0` の間に `react-server-dom-webpack`、`react-server-dom-turbopack`、または `react-server-dom-parcel` が見つかった場合、リスクがあります。また、これらのバージョンに依存するフレームワークリリースも同様です。CIイメージやDockerfileは古いタグを固定することが多いので、それらも確認してください。

ステップ2はアップグレードです。ほとんどのNext.jsアプリでは、最新の15.xまたは16.xのパッチを適用することが重要で、これにより修正されたReact Server DOMパッケージやReact Flightデシリアライズ変更が取り込まれます。典型的なコマンドは次のようになります:

• 1`npm install next@latest react@latest react-dom@latest`
• 2`yarn add next@latest react@latest react-dom@latest`
• 3`pnpm add next@latest react@latest react-dom@latest`

モノレポでは、ワークスペース全体でのアップグレードを同期させる必要があります。一つのサービスを脆弱なマイナーバージョンのままにしておかないでください。Waku、RedwoodJS、またはVite/Parcel用のカスタムRSCプラグインを使用している場合は、セキュリティ助言に従い、2025年12月11日以降の日付でDoSおよびソースコード漏洩の修正が言及された最初のリリースにアップグレードしてください。早期のRCEに関する背景については、ReactチームがReact Server Componentsの重大なセキュリティ脆弱性で詳細を説明しています。

ステップ3は検証です。全テストスイートを実行しますが、サーバーアクション、ストリーミングレスポンス、およびPOSTエンドポイントに関わるカスタム`fetch`やミドルウェアをテストするエンドツーエンドフローを優先してください。特に複雑なオブジェクト、日付、またはカスタムクラスをReact Flightを通じて渡す場合、シリアル化に関する微妙な回帰に注意してください。

ステージングにデプロイし、サーバー機能のエンドポイントに対して負荷テストや合成POSTリクエストを実施してください。ロールアウト後は、少なくとも24〜48時間、CPU、レイテンシ、エラー率を監視し、予期しない「サイクル保護」や「サーバー参照」のエラーがログにないか確認してください。実際のトラフィックの下で本番が安定している場合のみ、このインシデントをクローズとしてマークしてください。

Reactサーバーコンポーネントは、データ取得のためのクリーンな思考モデル、クライアントバンドルの削減、ページの読み込み速度の向上を約束しました。しかし、わずか2週間でRCE（CVSS 10.0）、DoS（7.5）、およびソースリーク（5.3）が発生した結果、現在それらはインターネットスケールで運用されている高リスクの実験に見えます。

内部では、React Flightは単純なレンダリングプロトコルというよりも、カスタムRPCおよびシリアライゼーションレイヤーのように機能します。任意のPOSTボディをサーバー関数をハイドレートするための命令として扱うと、すべてのパースミスが潜在的なRCE、DoS、またはデータ露出の原因となります。

パフォーマンス面では、RSCは依然として優れた成果を上げています：クライアントのJavaScriptキロバイトを減少させ、水fallフェッチを減少させ、よりキャッシュ可能なHTMLを提供します。開発者の体験も向上し、サーバーアクションによってフェッチのボイラープレートが隠され、APIルートが関数呼び出しに統合されています。

セキュリティはその話をひっくり返します。サーバーファンクション、クロスチャンクリファレンス、ファンクションIDなど、新しい機能は攻撃対象の範囲を広げます。DoSループ（チャンク0 → 1 → 0）と関数を引数として使用するソースリークは、デシリアライズロジックにおける単一のガードの欠如が、認証されていない1回のPOSTリクエストでNext.js 16.0.8アプリ全体を崩壊させる可能性があることを示しています。

Reactは今や単なるビュー層ではなく、バックエンドインフラストラクチャとして機能しています。この変化は、バックエンドレベルの安全策を必要とします。具体的には、正式な脅威モデル、Flightパーサーのファジング、再帰、ペイロードサイズ、参照の深さに関する厳格な制限が求められます。ただのハードコーディングされた「1000サイクル」の逃げ道だけでは不十分です。

ReactとVercelはすでにDXテストとパフォーマンスベンチマークに大きく投資しています。セキュリティに対しても同様の強度が必要です。Flightプロトコルの定期的な第三者監査、Server Functionsエンドポイントに対するレッドチーム演習、および新しい機能がリリースされる前のアーキテクチャレビューが求められます。

フレームワークベンダーは、Flightをブラックボックスではなく重要な依存関係として扱うべきです。つまり、独立したパーサーやラッパーを用いてローカルの安全ポリシーを強制し、RSCエンドポイントにデフォルトのレート制限を設け、リスクの高い環境においてRSCの無効化やスコープを設定するための明確な設定フラグを提供する必要があります。

開発者は、エルゴノミクスが実際に効果をもたらし、パフォーマンスの数値が製品チームにとって重要であるため、RSCを引き続き採用し続けるでしょう。問題は、この未熟なローンチ期間を、繰り返されるCVEサイクルではなく、持続可能なセキュリティストーリーに変えることができるかどうかです。

もしReact、Vercel、そしてホスティングプロバイダーが持続的な投資に応じるならば—バグバウンティ、コミュニティレビューを通じて強化されたプロトコル仕様、安全なデフォルト設定—この厳しいCVEの連鎖はケーススタディとして記録されるかもしれません。サーバーサイドのReactは、置き換えようとしているアドホックなJSON APIよりも、単に速くなるだけでなく、測定可能に安全になる可能性があります。

申し訳ありませんが、その情報は提供できません。私のデータは2023年10月までのもので、2025年以降の情報にはアクセスできません。

それらは高Severityのサービス拒否（DoS）脆弱性（CVE-2025-55184、CVE-2025-67779）と、中程度のSeverityのソースコード露出脆弱性（CVE-2025-55183）であり、どちらもReactサーバーコンポーネントに影響を及ぼしています。

どのバージョンのNext.jsとReactが影響を受けていますか？

この脆弱性は、バージョン19.0.0から19.2.0までのReact Server Componentsパッケージに影響を与えます。これは、App Routerを使用するNext.js（バージョン15.xおよび16.x）、Waku、RedwoodJSなどのフレームワークに影響を及ぼします。

前回の重大なRCE脆弱性（CVE-2025-55182）に対するパッチは、これらの新しい脆弱性から保護されますか？

いいえ。前回のパッチでは、これらの新しい脆弱性は解決されませんでした。DoSおよびソースコード漏洩問題に対する特定の修正を受けるには、依存関係を再度アップグレードする必要があります。

これらの脆弱性からアプリケーションをどのように保護できますか？

主な解決策は、依存関係をすぐにアップグレードすることです。Next.jsユーザーにとっては、最新のパッチバージョンにアップグレードすることを意味します。具体的なバージョン番号については、Reactおよびフレームワークプロバイダーの公式セキュリティ速報を確認してください。