React・Next.jsに発生した重大脆弱性とは何か？2025年に発覚した大規模脆弱性の概要と背景を解説

一方、Pages Routerは旧来のサーバーサイドレンダリング方式で、Reactはクライアント側のみ、サーバーとのやり取りはAPI RoutesやSSR用の関数を介するだけでした。そのためPages RouterのNext.jsにはRSCプロトコル自体が存在しないか、仮に存在しても使われません。これが、Next.jsでApp Router利用時のみ脆弱となる理由です。

Next.js公式も今回の脆弱性について「Pages RouterアプリケーションやEdge Runtime（Next.jsをEdge環境で動かす場合）は影響を受けない」と明言しています。App Routerか否か、という違いが脆弱性の有無を分ける大きなポイントでした。現在App Routerへ移行したプロジェクトは多いですが、もし依然Pages Routerを利用しているプロジェクトであれば、この脆弱性については直接の心配はありません（とはいえ将来App Router移行時にはアップデート対応が必要です）。

純フロントエンド環境の場合：サーバー機能を持たないReactアプリへの影響有無

Reactは必ずしもサーバーサイドで動かす必要はなく、静的サイトやクライアントサイドオンリーのSPAとして使われることもあります。そのような純粋なフロントエンド環境の場合、このRSC脆弱性はどうなるでしょうか。

結論から言えば、バックエンド（Nodeサーバー）を伴わない純フロントエンドReactアプリであれば、この脆弱性の直接的な影響は受けません。なぜならRSCはサーバーコンポーネント機能であり、サーバー上で動く部分がなければ攻撃者が入り込む余地がないからです。例えば、React + static HTMLとしてビルドしたサイトや、API通信はするがサーバーレンダリングはしない単純なクライアントSPAは問題ありません。

しかし注意したいのは、プロジェクトで使っている依存パッケージとして脆弱なRSCモジュールが含まれているケースです。たとえ現在使っていなくても、依存関係に脆弱なコードがある状態は好ましくありません。例えば将来的に誤って有効化してしまったり、他のモジュールから利用される可能性もゼロではないためです。したがって、たとえ純フロントエンド構成であっても、依存パッケージは安全なバージョンにアップデートしておくことが推奨されます。

想定される被害・リスクはどれほど深刻か？認証不要のリモートコード実行がもたらす脅威と被害シナリオ

次に、この脆弱性が引き起こしうる被害とリスクについて考えてみます。CVSS 10.0というスコアが示す通り、本脆弱性は最悪の場合システムに甚大な被害をもたらします。具体的にどんな攻撃が可能で、成功すると何が起こりうるのか、いくつかのシナリオを想定してみましょう。

リモートコード実行（RCE）の脅威：サーバー側で任意コードが実行される危険性

リモートコード実行（RCE）とは、遠隔から送られてきた命令（コード）がそのままターゲットのシステム上で実行されてしまう脆弱性や攻撃手法のことです。今回のReact/Next.jsの脆弱性はまさにRCEの一種であり、攻撃者は特別に細工したデータを送るだけで対象サーバー上で自分の用意した任意のコードを動作させることが可能になります。

サーバー上で任意コードが実行できてしまう危険性は計り知れません。通常、攻撃者が得られる権限はアプリケーションが稼働しているプロセスの権限範囲になりますが、それでもサーバー乗っ取りに近い行為が可能になります。例えばファイルを読み書きしたり、外部に通信したり、他のプロセスを起動するなど、プログラムで出来ることは何でも実行されてしまう恐れがあります。RCEはWebアプリケーションにとって最も致命的な脆弱性の一つであり、この脅威がReact/Next.jsという広く使われる基盤に存在したというのは非常に重大です。

認証不要の攻撃手法：ログイン無しでも不正リクエストが可能な深刻性

さらに悪いことに、今回の脆弱性を悪用するために特別な認証や事前準備が不要だという点が、攻撃の容易さと深刻性を高めています。例えば一部の脆弱性では、攻撃者が管理者権限でログインしていないと実行できないとか、特定ユーザーのCookieを盗まないと悪用できないといった条件があります。しかしReact2Shell（CVE-2025-55182）の場合、誰でもHTTPリクエストを送るだけで攻撃が成立する可能性があります。

攻撃者は標的のウェブサイトに対して、RSC用のエンドポイント（Next.jsであれば/_next/formactionなど）に悪意あるリクエストを投げればよいのです。このリクエストは通常のユーザーからの操作（例えばフォーム送信）のように見えるため、サーバー側では怪しまれずに受理してしまいます。ログインしていなくてもアクセスできる公開のWebページ上の機能を経由して攻撃可能であるため、防御側から見ると非常に対処が難しい部類の攻撃です。

要するに、この脆弱性は「インターネットに公開されているReact/Next.jsサーバーなら誰でも攻撃できる」という厄介さを持っています。認証や特別なトークンが要らないので、自動化された攻撃スクリプトがインターネット上の多数のサイトを狙い撃ちすることも技術的には可能でしょう。そのため早急な修正適用が強く求められるわけです。

攻撃成功時に可能となる悪意ある行為：データ漏洩からサーバー乗っ取りまで

では、攻撃がもし成功してしまった場合、具体的に攻撃者はどのような悪意ある行為を行えるでしょうか。RCEが成立すると、攻撃者はアプリケーションサーバー内で自由にコードを実行できます。想定される行為の例を挙げます。

• 機密データの窃取: データベースの接続情報やAPIキーなど、サーバー内に保存された秘密情報を読み取る。
• ファイルシステムへのアクセス: サーバー上のファイルを自由に読み書きし、例えばユーザーデータを盗み出したり改ざんしたりする。
• OSコマンドの実行: シェル経由で任意のプログラムを起動し、サーバーにバックドアを設置する、マルウェアをダウンロードさせるなど。
• 横方向への侵害拡大: 一つのサーバーを乗っ取った後、そこから同じネットワーク内の他のサーバーやサービスへの攻撃拠点にする。
• DDoSやサービス妨害: サーバー資源を消費させてサービスを停止させたり、別のターゲットへの攻撃トラフィック発信元にする。

このように、RCEが成功すれば攻撃者はやりたい放題です。特にNode.js環境ではOSのシステムコマンド呼び出しやファイル操作を行うAPI（child_processやfsモジュール等）が容易に使えるため、攻撃の自由度が高いです。実際、今回の脆弱性に関する技術的分析では、vmモジュールによるコード実行やchild_process.execSyncによるシェルコマンド実行など、多彩な攻撃手法が取り得ることが示唆されています。

考えられる被害シナリオ：サービス停止やマルウェア配布など最悪のケース

上記の攻撃手段を踏まえると、被害の具体的なシナリオも様々考えられます。最悪のケースをいくつか想定すると：

• 攻撃者がサーバー内の顧客データベースにアクセスし、大量の個人情報を漏洩させる。
• ウェブサイトのコンテンツを書き換えて、フィッシングページやマルウェア配布サイトに改造する。
• サーバー上にランサムウェアを仕掛けてファイルを暗号化し、サービスを麻痺させる。
• 乗っ取ったサーバーから他の企業システムへの攻撃を行い、二次被害をもたらす。
• 攻撃に気付かれないよう静かにバックドアを設置し、長期に渡り機密情報を抜き取り続ける。

これらはあくまで想定ですが、RCEの被害として実際に起こり得る内容です。特にReact/Next.jsはWebのフロントエンド系技術であり、「ユーザーに見える部分しか扱っていないから安全だ」と思っていた人にとって、サーバー側まで破られるというのは衝撃的でしょう。サービス運営者にとっては、サービス停止や顧客情報流出となれば甚大な信用失墜や損害賠償にも繋がります。

したがって、この脆弱性を「自分のところは大丈夫だろう」と軽視することは絶対にできません。万が一にも攻撃成功を許すと深刻な事態になるため、全力で対策すべきリスクだと言えます。

現時点での攻撃事例：PoC公開状況と実際の被害報告

では、公表から日が浅い現時点（2025年12月上旬）で、実際にこの脆弱性を突いた攻撃は報告されているのでしょうか。公式情報によれば、公表時点ではまだ本番環境での悪用報告は確認されていないとのことです。ただし、セキュリティコミュニティ内ではProof of Concept（概念実証、PoC）コードが作成され始めています。実際、GitHub上にはテスト用のリポジトリが公開され、脆弱な環境を再現してRCEが発生する様子を実演するコードが登場しました。

インターネット上では「既に攻撃が行われているらしい」という未確認情報が飛び交うこともありますが、公式にはまだ確証のある被害事例は挙がっていません。しかしながら、攻撃者が情報を得て手法を開発するまで時間の問題であることは間違いありません。CVEの公開から日が経つにつれ、攻撃コードが広まり実際の被害が報告される可能性が高まります。

特に注意したいのは、PoCが出回るとスクリプトキディ（既存の攻撃コードを利用するだけの攻撃者）でも簡単に攻撃できてしまう点です。そうなる前にアップデートを適用しておくことが重要です。現時点で被害が報告されていないからといって油断せず、先んじて防御策を講じましょう。

脆弱性の技術的な原因と仕組み：RSC（React Server Components）プロトコルに潜む問題点を解説

ここでは、今回の脆弱性がなぜ生じたのか、その技術的な原因と仕組みを掘り下げます。React Server Componentsの通信プロトコル（通称「Flight」プロトコル）にどんな問題が潜んでいたのか、そして攻撃者はどのようにその穴を突いたのかを解説します。

React “Flight”プロトコルの仕組み：サーバーコンポーネントのデータ通信方法

React Server Componentsでは、クライアントとサーバーの間でUIに関するデータ交換を行う特殊な通信プロトコルが使われています。これはReactの開発チーム内で「Flight（フライト）プロトコル」と呼ばれるものです。Flightプロトコルでは、クライアント側からサーバー側の関数（Server Action）を呼び出す要求や、サーバー側からコンポーネント描画用のデータをストリーム送信する際に、独自のシリアライズ形式でデータをやり取りします。

具体的には、Reactはコンポーネントのツリー構造や関数呼び出しを表現するメタデータをJSONに似た構造でパッケージ化し、HTTPリクエスト/レスポンスのボディに乗せて送受信します。クライアントが「このサーバー関数を実行して結果をちょうだい」というと、サーバーはそれを受けて処理し、結果としてUI更新に必要なデータ塊を送り返す、といった流れです。Flightプロトコルの目的は、UI更新に必要な最小限のデータを効率よくやり取りすることであり、開発者はその内部詳細を意識せずに済むよう抽象化されています。

ところが今回、そのFlightプロトコルの「データをシリアライズ/デシリアライズ（符号化/復号）する処理」に問題があることがわかりました。本来であれば信頼されたクライアントからの正当なデータがやり取りされることを前提にしていたためか、Reactはプロトコルデータの内容を厳密に検証せず処理を進めていた部分がありました。その結果、攻撃者が細工した異常なデータが来ても、Reactはそれを真に受けて処理してしまい、想定外の動きを許してしまったのです。

デシリアライズ処理の欠陥：不正な入力がコード実行に繋がるメカニズム

では、そのデシリアライズ処理の具体的な欠陥とは何でしょうか。技術的分析によれば、ReactのRSC関連コード中にあるモジュール読込用のヘルパー関数がポイントだったようです。ReactはFlightプロトコルで受け取ったメタデータを元に、サーバー側で必要なモジュールをrequireし、指定の関数や値を取り出す処理を行っています。この際、本来は取り出そうとしている対象（関数名や変数名）がモジュールに存在するかチェックすべきところを、チェックせずに直接アクセスしていたことが判明しました。

この挙動自体は一見些細なミスに思えますが、攻撃者からすると大きな抜け穴になります。なぜなら、モジュールに存在しない名前を指定してアクセスしようとするとJavaScriptの場合undefinedが返ります。しかしその先を辿ろうとする過程で、任意のプロパティ名を指定できるため、普通なら触れない内部プロパティにアクセスする手段になりえます。さらに工夫すると、そのプロパティにある関数を実行させる、といったことも可能になります。

例えば、Node.jsのモジュールには様々なプロパティや内部関数がありますが、攻撃者はメタデータを改ざんしてそれらにアクセスさせるよう細工できます。React側がチェックなくmoduleExportsのプロパティにアクセスする実装だったため、攻撃者の入力次第で本来呼ばれない関数（例えばシステム呼び出し系の関数など）を返すことができ、それをそのまま実行してしまう可能性が生まれました。これが不安全なデシリアライズによるコード実行に繋がったメカニズムです。

端的に言えば、Reactが「クライアントからの指示通りにモジュールのこの名前のエクスポートを返すよ」とやっていた部分が裏目に出て、悪意ある指示にも従ってしまったということです。本来なら「その名前のエクスポートは存在するか？不審な値ではないか？」とチェックすべきところを、チェックせず実行してしまっていたために起きたバグでした。

攻撃の流れ：特殊なペイロードがサーバーでコード実行に至るまで

ここまでの話を踏まえ、攻撃者がどのようにこの脆弱性を突くか流れを整理します。

1. 攻撃者は標的サイトに対し、RSC用のエンドポイント（例：Next.js App Routerでは/_next/formaction等）にHTTPリクエストを送る。
2. そのリクエストには、通常の利用では有り得ない特殊な形式のペイロード（Flightプロトコルデータ）が含まれている。内容には、Reactが特定のモジュールの特定のプロパティを読み出すよう仕向ける細工が施されている。
3. サーバー側のReact（あるいはNext.js）はそのペイロードを受け取り、正規のリクエストだと思い込んで処理を開始。ペイロード内の指示に従いモジュールをロードし、指定されたプロパティを参照する。
4. プロパティ名が本来ありえない値のため、React内部では意図していないモジュールのエクスポート（例えばNode.jsのvmやchild_process関連の関数）が選択されてしまう。
5. Reactは得られたエクスポートを本来の返り値としてクライアントに送り返そうとするが、その過程で攻撃者が仕込んだコードが実行される。これにより、攻撃者の任意コードがサーバー上で走ってしまう。

以上が簡単な攻撃の流れです。要は、「RSC通信→モジュール読込→コード実行」という一連の処理の中に、不正データが混入することで悪意あるコードまで実行されてしまうということです。Next.jsの検証では、特定のシナリオ（フォーム送信を模倣したPOSTリクエスト）でこれが再現されることが確認されています。

この攻撃はHTTPリクエスト一発で完結するため、防御側からすると通常のAPIコールとの区別が難しく厄介です。また、Flightプロトコルのデータは一見すると複雑なバイナリ/JSON混合のような形式で、人間の目では判断しづらいです。そのため、アプリケーションログに残っても気付きにくいという難点もあります。攻撃が成立すれば前述の様々な悪事を働かれてしまうため、本脆弱性はまさに「慎重に設計されたReactの処理フローにおいて見逃された盲点」を突いたものと言えるでしょう。

脆弱性が生まれた原因：新機能RSCにおける想定外の盲点と検証不足

なぜこのような脆弱性が生まれてしまったのでしょうか。根本的には、新機能導入時の想定外の盲点が原因だったと考えられます。Reactチームは開発当初、RSCのFlightプロトコルに関して「信頼されたフロントエンドからの通信である」という前提を置いていた可能性があります。つまり、悪意あるデータが飛んでくるとは想定せずに実装してしまった部分があったのでしょう。

また、RSC自体まだ新しい試みであり、従来のセキュリティテストでは網羅しきれなかった部分とも言えます。ReactはUIライブラリであってセキュリティに直接関わる機能は少ないというイメージがありました。しかし今回、サーバーとの境界に跨る処理をReact側が担うことで、「フロントエンドライブラリにもかかわらずサーバー側のセキュリティリスクを内包する」ことになりました。新技術の複雑さゆえに、従来の発想では見逃しがちな脆弱性が紛れ込んでしまったと言えます。

言い換えれば、RSCという強力な機能の導入に急ぐあまり、セキュリティ上の検証やレビューが十分でなかった可能性も指摘されています。もちろんReactチームは高い専門性を持って開発していますが、それでもゼロリスクにはできません。新しいパラダイムを導入する際には、今回のような予想外の攻撃ベクトルが生じ得ることを改めて示す結果となりました。

Log4Shellとの比較：広範な影響を及ぼした脆弱性との共通点と相違点

最後に、React2Shellが比肩されるLog4Shellとの比較に触れてみます。Log4Shell（CVE-2021-44228）はJavaのログライブラリLog4jにおけるRCE脆弱性で、任意のLDAPリファレンスをログに含めるだけで攻撃者がサーバーへ侵入できるというものでした。React2ShellとLog4Shellには共通点と相違点があります。

共通点としては、非常に広範囲のシステムに影響が及ぶ可能性がある点、攻撃難度が低く（データを送るだけ）、結果の深刻さが極めて高い点が挙げられます。どちらもインターネット全体で大騒ぎになるレベルのインパクトを持っています。また、ソフトウェア設計上の盲点を突かれたという点でも似ています。

相違点としては、Log4Shellはシステム外部から外部リソースを参照させることでコード実行するといういわばインジェクション系の攻撃でしたが、React2Shellはシステム内部のモジュールの扱い方の不備を突いた攻撃です。攻撃経路がテキストメッセージのログ vs 専用プロトコルデータという違いもあります。また、Log4Shellは既に攻撃コードが満ち溢れてしまったのに対し、React2Shellはまだ認知されて間もないため被害はこれから広がる可能性がある、という時間軸の違いもあります。

いずれにせよ、React2Shell（CVE-2025-55182）は「第二のLog4Shellになりかねない」と警戒されているわけです。これら過去の重大インシデントと比較することで、その危険性を我々開発者もしっかり認識し、対策に生かす必要があります。

今すぐ取るべき対策とアップデート手順：脆弱性を解消するための緊急対応ガイド

では具体的に、開発者や運用担当者が今取るべき対策について説明します。この脆弱性を根本的に解消するには問題の修正が施されたバージョンへのアップデートが不可欠です。また、それ以外に取り得る緩和策があるかについても触れます。早期に安全な状態へ移行するためのガイドラインを示します。

React側の修正：脆弱性が修正されたRSC関連パッケージのバージョン

React本体に関しては、前述の脆弱な各RSCパッケージに対して修正版がリリースされています。具体的には以下のバージョンで問題が修正されました。

• react-server-dom-webpack： 修正バージョン 19.0.1、19.1.2、19.2.1
• react-server-dom-turbopack： 修正バージョン 19.0.1、19.1.2、19.2.1
• react-server-dom-parcel： 修正バージョン 19.0.1、19.1.2、19.2.1

つまり、React 19系を利用している場合はそれぞれのパッケージを19.0.1以上、19.1.2以上、19.2.1以上にアップデートする必要があります。通常はnpm updateまたはnpm install [email protected]のようにして最新版へ上げればOKです。また、reactおよびreact-dom自体のバージョンも、最新のパッチが当たったものに更新しておくことが望ましいです（React 19.2.1など）。

これらパッケージの修正内容は、先ほど説明したチェック処理の追加などコードレベルの修正が含まれています。アップデートさえすれば潜在的な脅威は解消されるので、React側パッケージについては速やかにバージョンを上げてください。

Next.js側の修正：パッチが適用されたバージョンと具体的なアップデート手順

Next.jsに関しても、各メジャーバージョン向けにパッチがリリースされています。Next.js公式が発表した安全なバージョンは以下の通りです。

• Next.js 15系： 15.0.5、15.1.9、15.2.6、15.3.6、15.4.8、15.5.7
• Next.js 16系： 16.0.7

自分が使っているNext.jsのメジャーバージョンに応じて、上記いずれかの最新パッチバージョンにアップデートしてください。例えば15.2.x系を使っているならnpm install [email protected]と指定して更新します。同様に15.3系なら@15.3.6、16.0系なら@16.0.7です。15系の各バージョンラインで複数修正リリースが出ていますが、基本的にそれぞれ最新のものを適用すれば問題ありません。

もしNext.jsの14系カナリア（14.3.0-canary.77 以降）を使用していた場合は、Next.jsチームは一旦14系安定版にダウングレードすることを推奨しています。具体的にはnpm install next@14とすることで、14系最新安定版に切り替えられます。これはカナリア版でRSCを試験利用していたケース向けの緊急措置です。

Next.jsのアップデート後は、アプリケーションを再ビルドし、動作確認を入念に行ってください。大きなメジャーバージョンアップではないので機能破壊的変更はないはずですが、それでも依存関係が変わる可能性があります。特にApp Routerを使っている場合、React側のパッケージも同時に更新されるため、挙動が変わらないか注意深く見る必要があります。

その他ツールの対応：React RouterやExpoなど関連プロダクトのアップデート情報

React/Next.js以外にも、React Server Componentsを取り巻くエコシステムの様々なプロダクトが今回の脆弱性の影響を受けています。それらについても対応策が講じられています。

• React Router（RSC対応版）: React Routerの実験的なRSC統合機能を使っている場合、reactとreact-dom、そしてRSC関連パッケージを最新にアップデートするよう案内されています。
• Expo（React Native開発環境）: Expo SDK自体は直接影響しませんが、ExpoでWeb向けにビルドする際にreact-server-dom-webpackを利用している場合があります。Expo開発者にはreact, react-dom, react-server-dom-webpackの最新版への更新が推奨されています。
• RedwoodJS: RedwoodJSでは内部でRSCを扱うrwsdkパッケージが影響を受けました。対策としてrwsdkをバージョン1.0.0-alpha.0以降へアップデートすること、およびReact関連パッケージを最新にすることが推奨されています。
• Viteプラグイン (@vitejs/plugin-rsc): ViteでRSCを取り込むための公式プラグインも脆弱でした。こちらも@vitejs/plugin-rsc@latestへ更新が必要です。
• Parcel RSC: ParcelバンドラでRSCを利用するパッケージもアップデートがリリースされています。

このように、Reactに連なる周辺ツールもほぼ軒並みアップデートが必要でした。React公式ブログでは、これら各プロダクトごとの詳細な更新手順やバージョンについて触れられているので、該当する環境を使っている場合は公式情報を参照して確実に対策を行ってください。

暫定的な回避策はあるか：設定変更や機能無効化で防げない理由

脆弱性が発覚した際、アップデートまでの間に何か設定で無効化してしのげないか、と考えることもあります。しかし今回のケースでは、React/Next.js共に明確な回避設定は用意されていません。Next.jsのアドバイザリでも「脆弱なコードパスを無効化する設定オプションはない」と明記されていました。

つまり、RSC機能をビルド時にオフにするといった簡易的なスイッチは用意されておらず、またRSC関連のコードはNext.jsのApp Routerでは根幹に組み込まれているため、特定部分だけ避けるということが困難なのです。React側でも、RSCをサポートしている以上根底の実装が影響するため、実質避けようがありません。

そのため、唯一の確実な解決策は「アップデートを適用すること」です。アップデート以外の回避策を模索するより、できるだけ早く公式パッチを取り入れる方がはるかに安全です。どうしてもアップデートがすぐ適用できない事情がある場合、Web Application Firewall (WAF)等で特定の怪しいリクエストパターンを遮断するなどの緩和策は考えられますが、根本的な防御ではありません。後述するように一部サービスではWAFルールが提供されていますが、あくまで時間稼ぎに過ぎない点に注意が必要です。

ホスティングサービスの対応：Vercel等による一時的緩和策とアップデートの重要性

ReactやNext.jsの関係者は、主要なホスティングプロバイダやクラウドサービスとも連携して今回の脆弱性に対処しています。例えば、Next.jsの開発元であるVercelは、ユーザーにメールで注意喚起を行うとともに、自社プラットフォーム上でホストされているNext.jsアプリに対して一時的な防御策を実施したとされています。また、CloudflareはWAF（Webアプリケーションファイアウォール）のルールセットを更新し、CVE-2025-55182の攻撃パターンを検出・ブロックする規則を即座に全ユーザーに適用したと発表しています。

これらホスティング側の対応は非常に心強いものです。特にCloudflare WAFはグローバルに広く使われているため、一定の攻撃トラフィックは遮断されるでしょう。しかし、これらはあくまで緩和策であり、万能ではありません。攻撃パターンが高度化すればすり抜けられる可能性もありますし、全ての環境がWAFで守られているわけでもありません。何より、ホスティング事業者の対処があるからといって、開発者側がアップデートを怠って良い理由にはなりません。

したがって、ホスティングサービス側の措置に安心せず、最終的な責任は開発者・運用者側にあると考えてください。WAF等で猶予を得ている間に速やかに自分たちのアプリケーションをアップデートし、根本的に脆弱性を除去することが何より重要です。

自分の環境が影響を受けるか確認する方法：脆弱性の有無をチェックする手順とポイント

ここまでで脆弱性の内容と対策は理解できたかと思います。しかし、そもそも「自分のプロジェクトはこの脆弱性の影響下にあるのか？」を確認することも大切です。以下に、自分の環境が該当するかどうかをチェックする方法やポイントをまとめます。

パッケージバージョンの確認方法：ReactとNext.jsの現在使用中バージョンを調べる

まずは、自身のプロジェクトで使用しているReactおよびNext.jsのバージョンを確認しましょう。最も簡単なのはpackage.jsonを見ることです。dependenciesまたはdevDependenciesに記載されている"react", "react-dom", "next"のバージョン番号をチェックします。ここで、先述の脆弱なバージョン範囲（React 19.2.0以下、Next 15.x/16.0.6以下など）に該当していれば要注意です。

他にも、ターミナルでnpm list reactやnpm list nextとコマンドを打てば現在インストールされているバージョンを確認できます。npm lsコマンドを使うと依存ツリー上でどのバージョンが入っているか一覧が表示されるので便利です。とにかく、自分のReact/Next.jsのバージョンが安全圏かどうか、まず現状を把握することが出発点となります。

RSC関連パッケージの有無チェック：依存関係から脆弱性影響を判断する

次に、プロジェクト内でRSC関連の脆弱なパッケージが含まれていないか確認します。直接react-server-dom-webpack等をインストールしていなくても、Next.jsや他のフレームワーク経由で依存として入っている場合があります。npm ls react-server-dom-webpackなどのコマンドで、依存関係に該当パッケージが存在するかを調べてみましょう。

もしreact-server-dom-***系のパッケージが表示され、そのバージョンが19.2.0以下であれば脆弱なバージョンです。ただしnpm lsでは開発環境の依存など全て表示されるため、利用していない場合も載ることがあります。重要なのは、本番環境で実際に使われているかどうかですが、判断が難しければ念のためアップデートしておくのが安全策です。

また、Next.js 13系以前を使っているからといって安心せず、依存ツリー上にRSCパッケージが紛れ込んでいないか確認しましょう。例えば他のモジュールが誤ってRSCパッケージに依存している可能性もゼロではありません。プロジェクト全体の依存関係を洗い出し、脆弱性関連のパッケージが無いかチェックすることが肝要です。

セキュリティスキャンの活用：npm auditや専用ツールで脆弱性を検知

現代の開発環境には脆弱性検出のためのツールが多数用意されています。これらを活用するのも手です。例えばnpm auditコマンドを実行すると、依存パッケージに既知の脆弱性がある場合警告を表示してくれます。実際、Next.jsのCVE-2025-66478はGitHubのAdvisoryデータベースにも登録されているため、npm auditやGitHub Dependabotなどで検知可能です。プロジェクトのGitHubリポジトリの「セキュリティ」タブに脆弱性アラートが出ていた、というケースも多いでしょう。

さらに商用の脆弱性スキャナ（Tenable, Qualysなど）を利用している場合は、それらの製品向けにも今回のCVE検出プラグインが迅速に提供されています。例えばTenableやQualysはReact2Shell検出用のシグネチャをリリースしており、自社のサーバー群をスキャンして脆弱なシステムがないか調べることができます。企業で大規模にReact/Next.jsを使っている場合、このような専用ツールも駆使して見逃しを防ぐと良いでしょう。

RSC機能の利用状況確認：アプリがサーバーコンポーネントを使用しているか判断する

プロジェクト内で実際にRSCの機能を使っているかどうかも把握しておく必要があります。例えばNext.jsの場合、プロジェクトのディレクトリ構成にapp/フォルダがあり、そこにServer Component（\"use client\"を付けていないコンポーネント）やServer Actions（サーバー関数）が実装されていれば、RSCを活用している証拠です。React Routerの場合はunstable版のRSC対応APIを使っていないか確認します。

RSCを使っていなくても、Next.js 15以降でApp Routerがデフォルト有効であれば、内部的にはRSCサポートがロードされています。ですから、表向き使っていなくてもモジュールは含まれているケースが多いでしょう。それでも、自分のアプリが例えばフォームのServer Actionを実装しているかなどは把握しておくと、攻撃経路がどこにあり得るか想定できます。

もしRSC/Server Actionを積極的に使っているなら、そのエンドポイントが直接インターネットからアクセス可能かを考えてみます。Next.jsの場合、フォームからPOSTされるActionは認証が無ければ通常全ユーザーが叩けてしまいます。そうした部分には特に注意を払い、必ずアップデート対応を行いましょう。逆に言えば、RSC/Action未使用でPages Router中心のサイトなら緊急度は若干下がりますが、依然パッケージ更新自体は必須です。

攻撃兆候のモニタリング：ログやトラフィックから不審なリクエストを検出

最後に、既に攻撃されていないか、また今後攻撃の試みがないかをモニタリングすることも重要です。具体的にはサーバーログやトラフィックの中に不審なリクエストが来ていないかを確認します。Next.jsの場合ですと、POST /_next/formactionといったURLへのアクセスが頻繁に試みられていないか、また通常ではあり得ないペイロード（サイズが異常に大きい、意味不明なバイナリデータが含まれる等）が送られてきていないかをチェックします。

もし怪しいリクエストを見つけた場合、それは攻撃の前触れかもしれません。WAFやログ監視ツールを導入している場合は、CVE-2025-55182関連のシグネチャが提供されていないか確認し、適用しましょう。Cloudflare WAF等では自動的に遮断される例もありますが、自前の環境ではそのような保護が無いこともあります。

とはいえ、攻撃兆候を見つけた頃には既に遅い場合も多々あります。やはり「攻撃されていないか？」を気に病むより、「攻撃されても大丈夫なようアップデートする」ことが最善策です。モニタリングは補助的な検出策と割り切り、基本的には脆弱性の除去（アップデート）を完了させるまでの参考情報源と捉えるのが良いでしょう。

本脆弱性が与える影響と開発・運用上の注意点：エンジニアが留意すべきセキュリティ上のポイント

最後に、今回の脆弱性が我々エンジニアにもたらした教訓や、今後の開発・運用で注意すべき点をまとめます。単に「アップデートして終わり」ではなく、広くソフトウェア開発におけるセキュリティ意識向上につなげることが大切です。

開発プロジェクトへの影響：緊急アップデート対応による進行への影響

今回の件では、多くの開発プロジェクトが緊急のアップデート対応を迫られました。突然降って湧いた脆弱性情報により、予定していた機能開発やリリースを一時中断し、まず脆弱性修正を適用する作業を優先したチームも多いでしょう。開発スケジュールに影響が出るのは痛手ですが、セキュリティインシデントでは素早い対処が何より重要です。

このような緊急対応は短期的には生産性を下げるかもしれませんが、長期的に見ればプロダクトとユーザーを守るために不可欠なプロセスです。開発チームは今回の経験を踏まえ、脆弱性情報を常にウォッチする体制や、いざという時に即応できる手順書などを整備しておくことが望まれます。また、依存関係のアップデートを定期的に行い、日頃から最新の安全な状態を保つようにしておくことも、アップデート対応をスムーズにする秘訣でしょう。

運用面での影響：サービス停止リスクとインシデント対応体制の重要性

運用の観点でも、本脆弱性は重要な示唆を与えました。もし脆弱性が悪用されていれば、サービス停止やデータ漏洩といったインシデントに直結する恐れがありました。幸い迅速な対処のおかげで大事には至っていませんが、運用チームは常に最悪の事態を想定して備える必要があると再認識されたでしょう。

具体的には、インシデント発生時の影響範囲調査や対応手順をあらかじめ決めておくこと、バックアップ体制の見直し、監視アラートが上がった際の連絡フロー確認等が考えられます。また、WAFの導入やログ監視強化など、普段からセキュリティの多層防御を取り入れておくことも運用上のリスク軽減につながります。React/Next.jsのようなアプリでも、突き詰めればサーバーサイド技術なので、セキュリティは運用上の最優先事項であることに変わりはありません。

セキュリティ意識向上の機会：脆弱性対応から学ぶ安全な開発習慣

今回の出来事は、開発者にとってセキュリティ意識を高める良い機会となったはずです。普段フロントエンド開発に注力しているエンジニアにとって、Reactの脆弱性がこれほど大事になるとは想像していなかったという声もあるでしょう。しかしソフトウェアはどんな部分にも脆弱性が入り込む可能性があります。

この経験から、日頃から安全なコーディング習慣を身につけることや、セキュリティに関する勉強を怠らないことの重要性を改めて感じた人も多いでしょう。例えば、入力を信用せず検証するという原則はバックエンドのみならずフロントエンドのライブラリ開発にも当てはまるのだ、という教訓です。また、依存するOSS（オープンソースソフトウェア）のセキュリティアドバイザリをチェックする習慣、脆弱性公表時に速やかにプロジェクト内で情報共有する文化づくりなども大切です。

一つの脆弱性対応を乗り越えるたびに、開発チーム全体のセキュリティリテラシーが向上していくのが理想です。その意味でReact/Next.jsユーザーコミュニティは今回貴重な経験を積んだと言えるでしょう。

新技術採用時の注意：RSC導入におけるリスク評価と事前検証の必要性

React Server Componentsのような新技術は開発を前進させる原動力になりますが、同時に今回のような思わぬリスクを伴うことがあります。新しいパラダイムをプロダクションに導入する際には、事前のリスク評価と十分な検証が不可欠です。

具体的には、実験的機能やメジャーアップデートを安易に本番適用しない、適用するにしてもセキュリティレビューを挟む、想定される脅威モデルを洗い出しておく、といった対策が考えられます。RSCの場合、クライアントからサーバーを操作できるという点で、従来になかった攻撃パターンが生まれる可能性は理論上想定できました。そうした潜在的な危険にどれだけ気づけていたかが問われます。

もちろん、新技術を積極的に取り入れること自体は悪いことではありません。しかし、導入後もしばらくは警戒を怠らず、脆弱性情報に敏感になること、問題があれば素早くアップデートできる体制を作っておくことが重要です。今回の件を教訓に、今後は新機能採用時にセキュリティ面のチェックリストを用意するなどの工夫をしてみると良いでしょう。

早期発見と迅速対応：Reactコミュニティの対処から得られる教訓

最後に、Reactコミュニティおよび関係者の迅速な対応から学ぶべきことがあります。Lachlan氏による通報からわずか数日のうちにパッチが作成・リリースされ、各社も連携してユーザーへの通知・防御策適用を行いました。これだけの早期発見と素早い対処がなければ、悪意ある攻撃者に先手を取られて被害が広がっていたかもしれません。

このことから、コミュニティ全体でセキュリティ情報を共有し協力して対応する重要性が再確認できます。オープンソースの強みは、多くの目がコードを見て問題を見つけ、そして直していける点です。Reactチームと外部研究者や他フレームワーク開発者が一丸となって動いた今回のケースは、それを体現しています。

我々個々の開発者も、単に待ち受けるのではなく積極的に情報収集し、必要があれば報告・協力する姿勢を持ちたいものです。また、脆弱性公表後は可能な限り早くパッチを適用し、コミュニティの呼びかけに応えることも大切です。早期発見・早期対応の文化を育むことが、長い目で見て自分たちの開発プロジェクトを守ることにつながるでしょう。

React・Next.js以外の関連フレームワークやサービスへの波及：周辺エコシステムへの影響範囲と対応状況

ReactとNext.jsの話題が中心でしたが、今回の脆弱性はそれ以外のツールやサービスにも少なからず影響を与えました。最後に、周辺エコシステムでどのような波及があったか、そして各プロダクト・サービスがどのように対応したかについて触れておきます。

React Routerへの波及：不安定版RSC機能の影響とアップデート対応

React公式が提供するルーティングライブラリReact Routerも、この脆弱性とは無関係ではありませんでした。React Router自体はクライアントサイドのルーティングを行うライブラリですが、2023年頃から将来のReact Server Components対応を見据えた実験的APIを提供していました（未成熟な機能で、利用していない開発者も多い状況）。このReact RouterのRSC対応部分もReactの脆弱なコードに依存しているため、潜在的に影響を受けています。

React Routerの開発チームは、脆弱性公表後に推奨対応をアナウンスしました。それによれば、React RouterでRSCを試していた場合には、react, react-dom, react-server-dom-webpack等の関連依存をすべて最新にアップデートする必要があります。要するにReact自身のアップデートに追随する形です。幸いReact RouterのRSC機能はまだ一般利用されていなかったため、大きな混乱には至りませんでしたが、React Router利用者でRSCに関する設定を入れていた場合は忘れずにアップデートしてください。

Expoへの波及：React Native環境におけるRSC対応状況と対策

ExpoはReact Native向けの開発プラットフォームですが、ExpoアプリをWebに展開するケースや、Expoエコシステム内でReactの機能を使う部分があります。直接的にはExpoはReact Native（モバイル）なので今回のRSC脆弱性の影響はほとんどありません。ただ、一部Expo SDKでWebレンダリングを行う際に、内部でreact-server-dom-webpackなどを参照している可能性があるとの指摘がありました。

Expoチームからは公式な声明は出ていませんが、React公式の案内ではExpoユーザーも念のためreact, react-dom, react-server-dom-webpackを最新に上げるよう推奨されています。これは、Expoで裏側にNext.jsやWebサーバー機能を組み込んでいるケースに備えた措置と言えます。多くのExpoユーザーには無関係かもしれませんが、ExpoでWebサポートを有効にしている場合は一応アップデートするに越したことはないでしょう。

RedwoodJSへの波及：Redwood SDKにおける脆弱性対応状況

RedwoodJSはReactとGraphQLなどを組み合わせたフルスタックフレームワークです。そのRedwoodJSに付属するRedwoodJS SDK (rwsdk)というパッケージでも、RSCの仕組みを取り入れた部分があり、今回のReact脆弱性の影響を受けました。RedwoodJSチームは、脆弱性公表に合わせて開発版で対応を行っています。

具体的には、rwsdkの1.0.0-alpha.0以降でReact側の修正を取り込む形になっており、Beta版/Stable版についても順次対策が入る見通しです。RedwoodJS利用者に対しては、「もしAlpha版を使えるなら上げておくこと、難しければReactとreact-server-dom-webpackを最新にせよ」といった注意喚起がされています。RedwoodJSコミュニティもまだ比較的小規模ですが、フルスタックフレームワークであるだけに、この種のセキュリティ問題への対応は極めて重要です。RedwoodJSを採用しているプロジェクトでは、この脆弱性に関するアップデート情報をフォローしておくべきでしょう。

ViteやParcelへの波及：RSCプラグインのアップデートと影響範囲

モダンフロントエンドのビルドツールであるViteやParcelも、React Server Components対応のプラグインを提供しています。@vitejs/plugin-rscや@parcel/rscといったプラグインがそれで、ReactプロジェクトでRSCを利用する際に使われます。これらもReactのRSCパッケージに依存しているため、脆弱性の影響を受けました。

Vite公式からは、@vitejs/plugin-rscの最新版へアップデートすることが推奨されています。Parcel側も同様に、RSC機能のパッケージを更新する案内が出ています。ビルドツール自体（Vite本体やParcel本体）は今回の脆弱性とは関係ありませんが、プラグインレベルで依存している以上、無視できません。ViteやParcelユーザーは、自分のプロジェクトでこれらRSCプラグインを使っているか確認し、該当するならアップデートしましょう。

影響範囲としては、これらプラグインを使ってRSCを試していた開発者は限られるため大規模な混乱にはなりませんでした。しかし将来的にRSCが普及していけば、ビルドツールへの組み込みも一般的になるでしょう。そうなった際には、今回のような問題もより広範に波及しうることを念頭に置く必要があります。

ホスティングサービスへの影響：Vercel等のプラットフォームによる対策と今後の課題

最後に、ホスティングサービスやクラウドプラットフォームへの影響についてです。今回特にクローズアップされたのは、VercelとCloudflareでしょう。VercelはNext.jsの開発元かつホスティング提供者であり、多くのNext.jsアプリがVercel上で動いています。Vercelは発覚直後にユーザーへメールで通知を行い、また自社側でも何らかの緩和策（詳細は公開されていませんがおそらくWAF的なフィルタリング）を取った模様です。

Cloudflareは前述の通りWAFルール適用で迅速に動きました。その他、FastlyといったCDNプロバイダも自社ブログでReact RCEへの対策を紹介するなど、プラットフォーム側でも動きが見られました。これらは歓迎すべき対応ですが、一方で課題も残ります。全てのサービスがこんなに速く動けるわけではありませんし、そもそも単純なホスティング（例：自社サーバーや小規模VPS等）では自分で対処するしかないからです。

今後の課題として、クラウドサービス上で新機能（今回で言えばRSC）を使う際のベストプラクティスを共有したり、サービス提供側がユーザーの設定に応じて自動防御できる仕組みを整えるといったことが考えられます。例えば、Next.jsのApp Routerを有効にしてデプロイした場合は自動的にWAFルールも有効になる、などの仕組みがあれば被害はかなり防げるでしょう。現状そうした連携は始まったばかりですが、今回の一件を機に議論が進むかもしれません。

いずれにせよ、React・Next.js以外の周辺への波及も、最終的には各開発者がきちんとアップデートすることで収束します。エコシステム全体で協力し、適用可能な全てのプロダクトで脆弱性が除去されるよう努めていくことが重要です。