React Server Components（RSC）の脆弱性とは？DoSとソースコード露出のリスクと対策を徹底解説

2025年12月、React公式チームは「React Server Components（RSC）」の実装に、サービス拒否（DoS）とソースコード露出という2種類のセキュリティ上の問題が存在すると発表しました。React Server Componentsは、Next.jsをはじめとする多くのモダンなReactフレームワークが採用しているアーキテクチャであり、サーバー側でコンポーネントをレンダリングし、その結果をクライアントへストリーミングする仕組みです。今回の問題は、この「サーバー関数（Server Functions）」へのリクエストを処理する過程に起因しており、該当する構成でアプリケーションを運用している場合は、内容を正しく理解したうえで速やかな対応が必要です。

本記事では、React公式ブログのアナウンスをもとに、脆弱性の性質・技術的な背景・影響範囲・具体的な対策手順を整理します。エクスプロイトの実行方法やPoC（概念実証）コードには触れず、あくまで防御・運用の観点から解説します。狙いキーワードは「React Server Components 脆弱性」とし、関連語として「RSC DoS」「ソースコード露出」についても扱います。

React Server Components 脆弱性の概要
1. 何が発表されたのか
2. 深刻度と公表の経緯
技術的背景：RSCの仕組みとリスクの関係
影響を受ける条件
実践的な対策手順
対応状況を確認するためのチェックリスト
まとめ

React Server Components 脆弱性の概要

何が発表されたのか

Reactチームは公式ブログにおいて、React Server Componentsのバンドラ向け実装パッケージであるreact-server-dom-webpack、react-server-dom-parcel、react-server-dom-turbopackに、複数のセキュリティ上の問題が見つかったことを公表しました。内容は大きく分けて次の2系統です。

サービス拒否（DoS）：悪意のあるHTTPリクエストをサーバー関数のエンドポイントに送りつけることで、サーバープロセスを無限ループ状態に陥らせ、CPUを異常に消費させたり、プロセスをハングさせたりできる問題。結果としてサーバークラッシュやメモリ不足、過剰なCPU使用につながる可能性があるとされています。
ソースコード露出：特定条件を満たすサーバー関数に対して細工したリクエストを送ることで、本来クライアントに返されるべきではないサーバー関数のソースコード自体が応答として返ってしまう問題。

深刻度と公表の経緯

これらの問題には複数のCVE識別子が割り当てられており、DoS関連の問題は高深刻度（CVSSスコア7.5相当）、ソースコード露出は中程度の深刻度（CVSSスコア5.3相当）に分類されています。発見・報告は複数のセキュリティ研究者によって行われ、Reactチームはホスティングプロバイダーとも連携しながら一時的な緩和策を講じたうえで、2025年12月11日に最初の修正版を公開しました。その後も追加のDoS関連の問題が報告され、2026年1月26日には追加の修正が行われています。つまり本件は一度きりのパッチで完結したものではなく、段階的に修正が積み重ねられてきた経緯がある点に注意が必要です。

技術的背景：RSCの仕組みとリスクの関係

サーバー関数とシリアライズ処理

React Server Componentsの大きな特徴のひとつが「サーバー関数（Server Functions、旧称Server Actions）」です。クライアントから呼び出されたサーバー関数の引数は、ネットワーク越しに送るためにシリアライズ（直列化）され、サーバー側で受け取った際にデシリアライズ（復元）されます。RSCのプロトコルは、通常のJSONでは表現しにくいReact固有のデータ構造（Promiseやストリーム、循環参照を含むオブジェクトなど）もやり取りできるよう、独自の仕組みを持っています。

なぜDoS（無限ループ・CPU枯渇）が起きるのか

今回報告されたDoSの問題は、クライアントから送られてくるリクエストの内容を、サーバー側が信頼した形で処理してしまう点に起因しています。攻撃者が細工したペイロードを送信すると、Reactのデシリアライズ処理がその入力を正常なリクエストとして扱おうとし、結果として処理が終わらない無限ループに入ってしまう、というのが公式発表から読み取れる基本的な構図です。Webアプリケーションのサーバー関数エンドポイントは外部から到達可能であることが前提のため、入力値の検証や処理の仕組みそのものに問題があると、単純なリクエスト送信だけでサーバーリソースを消耗させられてしまいます。

なぜソースコードが露出してしまうのか

ソースコード露出の問題は、引数を文字列化（stringify）する処理を持つサーバー関数が存在する場合に発生し得るとされています。本来であればサーバー関数の実装コードはクライアントに一切渡されるべきではありませんが、細工されたリクエストによって、エラーメッセージやレスポンスの一部として関数の実装そのものが返却されてしまう経路が存在していました。公式の説明では、ソースコード中にハードコードされたシークレット（APIキーなどを直接コードに書いてしまっているようなケース）は漏洩のリスクがある一方、process.env.SECRETのように実行時に環境変数から読み込むランタイムシークレットは、この問題の直接の影響を受けないとされています。この違いは、後述する緩和策を検討するうえでも重要なポイントです。

影響を受ける条件

対象パッケージとバージョン範囲

今回の問題は、React本体そのものというより、React Server Componentsをバンドラと接続するための以下のパッケージに存在します。

react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack

公式発表によれば、19.0系・19.1系・19.2系のそれぞれで複数のバージョンが影響を受けるとされており、修正済みバージョンとして19.0.4、19.1.5、19.2.4が案内されています。なお、これ以前に19.0.3・19.1.4・19.2.3といった段階的な修正版が出ていましたが、その修正が不完全であったため、追加の更新が必要になったという経緯がある点は必ず押さえておきましょう。

対象となるフレームワーク・ツール

React Server Componentsをサポートするフレームワークやビルドツールを経由してこれらのパッケージが使われている場合、間接的に影響を受けます。公式ブログでは、Next.js、React Router、Waku、Parcel RSC、Vite RSC Plugin、RWSDKなどが対象として挙げられています。これらを利用している場合は、フレームワーク自体のアップデートを通じて依存パッケージが更新されるケースが多いため、フレームワークのリリースノートも合わせて確認することをおすすめします。

影響を受けないケース

一方で、React Server Componentsの仕組みを使っていない、つまり「サーバーを介したレンダリングやサーバー関数の呼び出しを行っていない」構成のReactアプリケーションは、今回の問題の影響を受けないとされています。従来型のクライアントサイドレンダリング中心のSPAや、サーバー関数を一切定義していないアプリケーションであれば、緊急度は相対的に低いと考えられます。ただし、フレームワークのバージョンによっては意図せずRSC関連の機能が有効化されている場合もあるため、自分たちの構成を正しく把握することが第一歩になります。

実践的な対策手順

ステップ1：現在のバージョンを確認する

まずは自分のプロジェクトが該当パッケージをどのバージョンで利用しているかを確認します。

npm ls react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack

# もしくはyarnの場合
yarn why react-server-dom-webpack

# pnpmの場合
pnpm why react-server-dom-webpack

Next.jsやReact Router、Wakuなどのフレームワークを利用している場合は、フレームワーク自体のバージョンと、そのフレームワークが依存するReact関連パッケージのバージョンをあわせて確認しましょう。

ステップ2：修正済みバージョンへアップグレードする

該当パッケージが修正前のバージョンであった場合は、react・react-dom・react-server-dom-*系のパッケージをまとめて最新の安定版に更新します。

# npmの場合
npm install react@latest react-dom@latest

# yarnの場合
yarn add react@latest react-dom@latest

# pnpmの場合
pnpm add react@latest react-dom@latest

Next.jsなどフレームワーク経由で管理している場合は、フレームワーク側のパッケージを最新化することで、内部的に依存する react-server-dom-* 系も追従して更新されるのが一般的です。アップグレード後は、必ずロックファイル（package-lock.json / yarn.lock / pnpm-lock.yaml）を確認し、実際に修正済みバージョン（19.0.4、19.1.5、19.2.4のいずれか、あるいはそれ以降）が解決されていることを確認してください。

ステップ3：モノレポ・React Native環境での注意点

React Nativeを含むモノレポ構成のプロジェクトでは、reactやreact-domそのものを更新する必要はなく、react-server-dom-webpack・react-server-dom-parcel・react-server-dom-turbopackのいずれかがインストールされている場合に、それらのパッケージのみを更新すれば十分とされています。無関係なパッケージまで一括更新すると、思わぬ互換性の問題を招くこともあるため、影響範囲を正しく絞り込んだうえで対応することが望ましいでしょう。

ステップ4：即時アップデートが難しい場合の緩和策

本番環境の都合上、すぐにバージョンアップできない場合は、以下のような一時的な緩和策を組み合わせて検討してください。

サーバー関数エンドポイントの前段にリバースプロキシやWAF（Web Application Firewall）を配置し、異常に大きい・複雑な構造のリクエストボディを遮断する。
リクエストサイズの上限やタイムアウト値を適切に設定し、単一リクエストが処理を占有し続けないようにする。
ハードコードされたAPIキーやトークンなど「秘密情報をソースコードに直接埋め込む」実装を洗い出し、環境変数経由の読み込みに置き換える（ソースコード露出時の被害を最小化するため）。
サーバー関数のリクエストログ・エラーログを監視し、CPU使用率の急上昇や同一エンドポイントへの異常なリクエストパターンを検知できる体制を整える。

これらはあくまで恒久対応ではなく、修正済みバージョンへのアップグレードまでの「つなぎ」として位置づけるべきものです。

対応状況を確認するためのチェックリスト

自社プロダクトがReact Server Components（サーバー関数・Server Actions）を利用しているかを確認したか
react-server-dom-webpack / react-server-dom-parcel / react-server-dom-turbopack のいずれかを使っているかを確認したか
該当パッケージのバージョンが19.0.4・19.1.5・19.2.4（またはそれ以降）に達しているかを確認したか
Next.js・React Router・Waku・Parcel RSC・Vite RSC Plugin・RWSDKなど利用フレームワークの対応バージョンを確認したか
ソースコードにAPIキーなどのシークレットを直接埋め込んでいる箇所がないかを棚卸ししたか
本番環境のアップデート後、正常にビルド・デプロイできることをステージング環境で確認したか
アップデート後もサーバー関数エンドポイントへの異常なリクエストがないか監視体制を確認したか

まとめ

今回のReact Server Componentsの脆弱性は、DoSとソースコード露出という2つの側面を持ち、RSCのサーバー関数をやり取りする基盤部分に起因するものでした。Next.jsをはじめとする主要フレームワークを介して間接的に影響を受けるプロジェクトも多く、公式が案内する修正済みバージョン（19.0.4・19.1.5・19.2.4）への更新が最優先の対応となります。過去に一度パッチが当たっていても、それが不完全であったために追加の修正が必要になったという経緯があるため、「以前対応したから大丈夫」と判断せず、現在のバージョンを再確認することが重要です。

RSCのようなサーバーサイドの新しいアーキテクチャは利便性が高い一方で、サーバーとクライアントの境界を扱う複雑な仕組みであるがゆえに、今回のような問題が起こり得ます。日頃から依存パッケージのバージョン管理を徹底し、公式のセキュリティアナウンスを定期的にチェックする体制を整えておくことが、React Server Componentsを安全に活用するための第一歩になります。