React2Shell（CVE-2025-55182） – React Server Componentsの重大な脆弱性解説と対策

導入

2025年12月、Web開発コミュニティに大きな衝撃が走りました。Reactの最新機能「React Server Components (RSC)」に、CVSSスコア10.0（最高深刻度）という極めて危険な脆弱性が見つかったのです。この脆弱性は「React2Shell」と呼ばれ、わずか1回の悪意あるリクエストでサーバーを乗っ取れる未認証のリモートコード実行（RCE）を引き起こします。発見者の報告（11月29日）からパッチ公開（12月3日）までたった数日でしたが、その数時間後には早くも攻撃が開始され、国家規模のサイバー攻撃集団も動き出したと報告されています。

「Log4Shell」をご記憶でしょうか。2021年末に問題となったJavaライブラリLog4jの深刻な脆弱性です。React2ShellはReactという超メジャーなフレームワークに関わるRCEである点や、被害の広範さから「第二のLog4Shell」とも称されます。名前の「2（to）」は「Shell（シェル）＝サーバーの操作権」を奪うことを意味し、それほど深刻な影響を持つことを示唆しています。本記事では、React2Shellの背景と技術的な原因、実際の攻撃事例、影響範囲、そして多層的な対策までを、専門的な内容も平易に説明しながら解説します。前提知識がない経営層の方でも理解できるよう心がけています。最後には経営層向けの要約も掲載しています。

背景

Reactは世界中で使われているWebフロントエンドのライブラリです。そのReactが提供する新機能がReact Server Components (RSC)で、これは一部のUIコンポーネントをサーバー側で実行・レンダリングし、クライアントに必要な結果だけを送る仕組みです。RSCによりクライアント側のJavaScript負荷を減らし、パフォーマンス向上を図れると期待されていました。このサーバー・クライアント間でコンポーネントデータをやり取りする方式を「Flightプロトコル」と呼びます。

有名なフレームワークNext.js（ReactベースのWebアプリケーションフレームワーク）は、バージョン15以降でこのRSCを本格採用しました。Next.js 15.xおよび16.x系では、新しい「App Router」を用いると内部的にRSCが有効となります。標準設定ではRSCがデフォルトでオンになっているため、特別な設定やコードを追加しなくてもRSC機能が組み込まれたアプリが構築されます。実際、npx create-next-appで生成したばかりのアプリをそのままデプロイした場合でも、この脆弱性の影響を受ける状態になります。言い換えれば開発者が1行もコードを書いていなくても、既定の構成で脆弱性が内在しているのです。

Next.jsだけでなく、React RouterやExpo、Redwoodといった他のフレームワーク/ライブラリもRSCを試験的にサポートしており、同様の脆弱性影響下にあります。つまりReact 19系のRSC機能を利用するあらゆるアプリケーションが潜在的に危険にさらされました。React自体の利用率は極めて高く、全世界のフロントエンド開発者の約82%がReactを使用しているとの調査もあります。クラウド環境で見ても、約39%もの環境に脆弱なReact/Next.jsインスタンスが含まれていたとのデータがあります。このように影響範囲は非常に広範で、企業や組織にとって他人事ではありません。

なお、Next.jsではReactを内部にバンドルしている（vendoring）ため、npm auditなど一般的な脆弱性スキャンではReactのバージョン脆弱性を見逃す恐れがあります。「自社はReact 18だから関係ない」と油断するのも禁物です。Next.jsなど一部フレームワークでは裏でReact 19系モジュールを組み込んでいる場合があり、表面的なバージョン番号だけで安全とは判断できません。現にReact公式も「たとえReact Server Functions（RSCの一部機能）を使っていなくても、アプリがRSCをサポートしていれば脆弱性の影響を受ける可能性がある」と警告しています。自社システムで直接React 19を使っていないように見えても、間接的な依存によりリスクが潜んでいないか注意が必要です。

発生原因

React2Shell脆弱性の本質は、React Server Componentsの「Flightプロトコル」における不適切なデシリアライズ処理にあります。デシリアライズとは、通信で受け取ったデータ（シリアライズされた構造）を元のオブジェクトやプログラム内データ構造に復元する処理です。今回、サーバーがクライアントから送られたRSC用データ（Flightペイロード）を復元する際に、入力の検証が不十分だったために、悪意あるデータまでそのまま実行してしまうという論理的欠陥がありました。Reactの脆弱なコードでは、本来なら無視すべき特殊なプロパティまで展開して処理してしまい、結果として攻撃者が用意したスクリプトをサーバー側で実行させてしまいます。これは「安全でないデシリアライゼーションの脆弱性」と呼ばれる典型的なバグの一種で、外部から渡されたデータを信頼しすぎて処理することで起こります。

この問題をもう少し噛み砕いて説明しましょう。ReactのFlightプロトコルでは、サーバー→クライアント通信時やクライアント→サーバー通信時にデータをシリアル化・デシリアライズします。脆弱性が発生したのは、クライアント→サーバー方向の流れ（例えばブラウザからサーバー関数へのリクエスト）でした。サーバー側の実装では、受け取ったデータをJavaScriptのオブジェクトや配列に復元する際、オブジェクトのプロパティ名を適切にチェックせずに処理していました。攻撃者はここに目を付け、通常は含まれない特殊なキーを仕込んだデータを送りつけることで、サーバーのコード実行フローを乗っ取ることに成功したのです。具体的には、攻撃者はペイロード内に__proto__やconstructorといったプロパティ名を含めました。これらはJavaScriptのオブジェクトのプロトタイプ（雛形）が持つ特別なプロパティです。例えばconstructorプロパティは元々オブジェクトの生成元（関数）を指しますが、これを悪用して**Functionオブジェクト（任意のJavaScriptコードを実行できる関数コンストラクタ）**への参照を取得できてしまいます。

つまり、攻撃者はオブジェクトの「設計図」そのものを書き換えるような手法で、Reactのデシリアライズ処理に介入しました。JavaScript特有のこの攻撃テクニックは「プロトタイプ汚染（Prototype Pollution）」と呼ばれます。今回のケースはプロトタイプ汚染の一種ではありますが、より正確には「オブジェクトのプロトタイプ上のconstructorなどのプロパティに不正アクセスできてしまう」ことが根本原因でした。攻撃者は特殊なオブジェクト構造を送りつけることで、React内部で本来呼ばれるはずのない関数コンストラクタ（Function）を呼び出させ、任意コードを生成・実行させることに成功します。コード上のミスとしては、Reactの復元処理でhasOwnProperty（オブジェクト自身がプロパティを持つか確認する安全策）を使うべき所で使っていなかったことが挙げられます。その結果、攻撃者定義の偽のプロパティを見逃して実行してしまったのです。開発チームはこの点に気づき、パッチではhasOwnPropertyを正しく用いて外部データを検証するよう修正が加えられました。

もう一つ、研究者による分析例を挙げます。OffSec社はReact2Shellの攻撃フローを次のように説明しました。

攻撃者はChunk（RSC内部で使われるデータ片）に見せかけた細工オブジェクトを含むペイロードを送信します。偽のChunkオブジェクトにはカスタムのthenメソッド（Promiseの結果受け取り関数）が定義されています。Reactがペイロードをデシリアライズする際、そのChunkをPromise（非同期処理結果）として解釈し、Promiseの解決処理で攻撃者が制御するthenメソッドを呼び出してしまいます。

JavaScriptにおけるPromiseを知っていれば、この説明の怖さがわかるでしょう。Promiseオブジェクトは通常.then()で結果処理を登録しますが、攻撃者は偽のthenを仕込むことでReactにその関数を実行させ、サーバー内部の操作権を奪ったのです。これも実態としてはプロトタイプ汚染の変形技ですが、いずれにせよデシリアライズ時のチェック漏れが招いた問題です。

まとめると、この脆弱性は「サーバーが受け取ったデータを無防備に復元した結果、攻撃者の用意したコードをそのまま実行してしまう」というロジックの欠陥でした。技術的には高度な手法が使われていますが、本質は「入力データの検証不足」というソフトウェア開発で頻出する問題の一つです。

なぜこれほど危険なのか

React2Shellが最大深刻度(Critical)と評価されている理由は以下の点にあります：

デフォルト設定で脆弱
- 開発者が特別な設定をしていなくても、前述の通り標準的なNext.jsアプリは脆弱性を抱えています。つまり「うちはカスタムなことはしていないから安全」という油断が通用しません。
認証不要
- 攻撃にログインやトークン等の認証は一切不要です。脆弱性を突くリクエストはアプリケーション固有の認証ロジックが実行されるより前に処理されるため、どんなに堅牢な認証機構もバイパスされてしまいます。
成功率が極めて高い
- 脆弱なシステムに対してはほぼ100%の確率でRCE攻撃が成功すると報告されています。一度攻撃内容を作ってしまえば、細工リクエストを送るだけで確実に侵入できるに等しいため、攻撃者にとって「仕掛けたら放置でOK」な夢のような攻撃手段となっています。

これらの要因が重なり、React2Shellは「非常に簡単かつ確実にサーバーを乗っ取れる」重大インシデントとなったのです。技術的背景を知らない経営層の方も、この脆弱性が自組織のサービスに即座に深刻なリスクを及ぼしうることを認識する必要があります。

脅威と被害の実態

React2Shellの脆弱性公開後、その危険性の高さから世界中の攻撃者が即座に飛びつきました。実際、Amazon AWSの脅威インテリジェンスチームは「公開から数時間以内に、中国政府系ハッカー集団（Earth Lamia、Jackpot Pandaなど）による積極的な悪用を観測した」と報告しています。国家レベルのAPT（高度持続的脅威）だけでなく、多数のサイバー犯罪者集団もこの脆弱性を迅速にスキャン・悪用し始めました。専門家によれば、脆弱性発表直後から多数のインターネットスキャンが行われ、React/Next.jsを使った公開サイトが次々と探索されたといいます。特にNext.js特有のアプリ識別情報（アイコンのハッシュ、SSL証明書のパターン、URLパスなど）を手がかりに、自動化ツールで効率よく標的リストを絞り込む動きもあったようです。

実際に観測された攻撃パターンも多様です。いくつか具体例を紹介します。

リバースシェルによる侵入とC2接続
- Palo Alto Networks Unit 42は、ある攻撃者が脆弱性を突いてサーバー内でbashのリバースシェル（サーバーから攻撃者の端末へ接続を張るシェル）を起動し、Cobalt StrikeとみられるC2（コマンド＆コントロール）サーバーに接続していたことを報告しています。Cobalt Strikeは元々ペンテスト用のツールですが、今や攻撃者がネットワーク内に潜伏・制御を維持するためによく使う後期侵入フレームワークです。このケースでは、侵入後すぐに高度な攻撃基盤を導入して継続的に操作しようとしていたことがわかります。
マルウェア（バックドア）の展開
- セキュリティ企業Huntressの調査では、「PeerBlight」と名付けられたLinux用バックドア型マルウェアがReact2Shell経由で設置された事例も確認されています。攻撃者はまず脆弱性を使って初期侵入し、その後このマルウェアをサーバー上にインストールして**恒常的な遠隔アクセス手段（バックドア）**を確保していました。
侵入直後の情報収集（クラウド認証情報の窃取）
- 攻撃に成功した後、最初に行われる典型的な動きは環境情報の収集です。Qualys社の分析によれば、多くの攻撃でwhoami（実行ユーザー確認）、hostname（ホスト名確認）、環境変数のダンプ、/etc/passwdの閲覧などが即座に実行されていました。これは「自分が侵入したのはどんなサーバーか」「どんな権限で動いているか」を把握し、次のステップ（横展開や重要情報窃取）に備える目的があります。特に環境変数にはクラウドサービスの認証キー（例: AWSのアクセスキー）やデータベース接続情報など機密情報が含まれることが多く、これを盗まれるとクラウド全体が危険にさらされる恐れがあります。実際、Wiz社の調査でも攻撃者が環境変数やファイルシステム、クラウドインスタンスのメタデータサービスから資格情報を収集しようとしていた事例が報告されています。あるケースではAWSのクレデンシャル（アクセスキー）を見つけ出し、それらをBase64エンコードして外部に持ち出そうとした形跡も確認されました。また別のケースでは、侵入直後にSliverというマルウェア（攻撃者用の遠隔操作ツール）をインストールしようとするスクリプトが動いていた例もありま。
暗号通貨マイニング（クリプトマイナー）の実行
- 金銭目的のサイバー犯罪者にとって、侵入したサーバーで真っ先に行うのが暗号通貨の不正マイニングです。React2Shellでも例外ではなく、XMRigというMoneroコインのマイニングプログラムを複数の被害者環境に仕込むキャンペーンが観測されています。Wiz社は少なくとも6件の独立した暗号通貨マイナー攻撃キャンペーンを確認しており、最初のものは12月5日午前6時(UTC)に遡るとしています。ある攻撃ではUPXでパックされた（難読化された）XMRigを落として実行し、別の攻撃ではGitHub上から標準的なXMRigセットアップスクリプトをダウンロードして独自のマイニングプールに接続していました。暗号通貨マイニングはサーバーリソースを大量消費しサービス性能を劣化させるだけでなく、マイナー自体が他のマルウェアを持ち込む踏み台になる可能性もあり危険です。

以上のように、React2Shellの悪用により機密データの窃取からマルウェア感染、リソース搾取まで様々な被害シナリオが現実に起きています。幸い2025年12月時点では国内企業の具体的被害事例は大きく報じられていませんが、世界規模での自動スキャン・攻撃は日本の組織にも例外なく向けられていると考えるべきです。実際、国内のセキュリティ専門家も「日本でも影響が出ていてもおかしくない」と注意喚起しています。脆弱なサーバーは公開からほんの数日でボットネットや攻撃者に捕捉・侵入されている恐れがあり、「自社は大丈夫だったか？」を確認する時間的猶予はほとんど無かったと言えます。

攻撃手法の詳細

では、このReact2Shell攻撃は具体的にどのように行われるのでしょうか。その一連の流れを、技術的な観点と分かりやすさの両面に配慮して説明します。

脆弱なサーバーの探索（スキャン）
- 攻撃者はまずインターネット上でReactまたはNext.jsを使ったアプリケーションを探し出します。前述の通り、Next.js特有の識別情報（HTML内の特殊なタグやレスポンスヘッダ）などをキーに自動スキャンツールで脆弱なターゲットを絞り込みます。数多くのシステムを一斉にチェックし、反応があったサーバーをリストアップします。この段階では単に「脆弱な可能性があるサイトの特定」をしているに過ぎませんが、公開直後から世界中で大規模なスキャン活動が行われたことが報告されています。
悪意あるリクエストの送信（初期エクスプロイト）
- 標的が定まると、攻撃者はそのサーバーに対し特殊に細工されたHTTPリクエストを送りつけます。具体的には、通常はアプリ内部でしか使われないRSC用の通信エンドポイント（Next.jsの場合HTTPヘッダnext-actionや特定のURLパス）に対し、攻撃用ペイロードを含むリクエストを直接発行します。このリクエストは認証やユーザー操作なしに受け付けられ、Reactのサーバー側ロジック（Flightプロトコルのデシリアライズ処理）まで到達します攻撃ペイロードには先述の通り__proto__やthenメソッドなど不正なデータが含まれており、サーバーはそれを無害なデータと誤認して復元→実行してしまいます。その結果、攻撃者が用意したスクリプトがサーバー上で動き、例えばシステムコマンドを起動することが可能になります。実質的にここで攻撃者はサーバーへの侵入（シェル取得）を果たしたことになります。
サーバー内での攻撃コード実行
- 攻撃リクエストが成功すると、サーバー内部で攻撃者のコマンドが走ります。多くの場合、攻撃者はまず簡単なコマンド（例: idコマンドでユーザー権限を確認）を実行し、その出力を攻撃者側で受け取ることでコード実行に成功したことを確認します。次に、より便利な操作のためにリバースシェルを仕掛けることが一般的です。リバースシェルとは、サーバー側から攻撃者のPCに向けてシェル（コマンドライン）セッションを確立する手法で、攻撃者は自分の手元からサーバー上のコマンドを自在に実行できるようになります。こうして攻撃者はサーバーを遠隔操作下に置いた状態になります。
内部情報の収集と横展開の準備
- シェルアクセスを得た攻撃者は、直ちにサーバー内部の情報収集を開始します。典型的には、先に述べたようなwhoamiやhostnameで基本情報を、envコマンドや設定ファイルを読んで認証情報を、netstatやクラウドのメタデータサービス（例えばAWSならhttp://169.254.169.254/latest/meta-data/...）へのアクセスでネットワーク・クラウド環境を調べます。特にクラウド環境の場合、ここで得たキーを使ってその組織のクラウド管理権限を乗っ取ることが可能になるため、攻撃者は躍起になって資格情報を探します。また、サーバー内に他のシステムへの接続情報（DBのパスワードなど）があればそれも窃取し、**攻撃の次の標的（横方向への展開）**に利用します。
追加マルウェアの実行・恒常的なバックドア設置
- 情報収集が終わるか並行して、攻撃者は何らかのペイロード（追加の攻撃ツール）をサーバー上で実行します。具体例として、前述のCobalt Strikeビーコンや独自のバックドア（PeerBlight等）を設置して持続的なリモートアクセスを確立する動きがあります。また、暗号通貨マイニング用のマルウェアをダウンロードして実行し、サーバー資源を勝手に採掘に使う攻撃もしばしば見られます。高度な攻撃者はさらに、root権限昇格を狙って既知のローカル脆弱性（例: CVE-2021-4034「pkexec」の問題）を突き、サーバー内でより高い権限を奪取しようと試みることもあります。権限昇格に成功すれば、サーバー内のあらゆるデータにアクセスできるだけでなく、検知の回避や破壊的な行為も容易になります。
痕跡消去とさらなる攻撃展開
- 最後に、攻撃者は自身の痕跡（ログやコマンド履歴）を消去しようとします。例えばシェルの履歴(history -c)を消したり、改ざんしたタイムスタンプを元に戻してファイル改変を隠蔽したりする動きが報告されています。こうして侵入の形跡を薄めた上で、盗んだクラウド認証情報を使ってクラウド上の他のサーバーやデータストアに攻撃を広げたり、あるいは企業ネットワーク内でさらなる標的を物色したりします。被害は単一サーバーに留まらず、クラウドアカウント全体や関連システム全般に波及する恐れがあります。

以上が一般的な攻撃フローですが、攻撃者の目的によって多少の違いはあります。重要なのは、この脆弱性が初期侵入の起点として非常に容易かつ強力であり、その後の被害シナリオも多岐にわたるという点です。つまり、一度侵入を許すと情報漏洩・サービス停止・金銭被害など様々な損害に繋がりかねないため、初期侵入そのものを全力で防ぐ必要があります。

影響範囲

React2Shell（CVE-2025-55182）の影響範囲は、React Server Componentsを実装またはサポートするすべての技術スタックに及びます。具体的には:

React本体
- 脆弱なバージョンはReact 19.0.0、19.1.0、19.1.1、19.2.0で提供されたRSC関連パッケージ（react-server-dom-webpack、react-server-dom-parcel、react-server-dom-turbopack）です。これらのReact 19系を直接使っている場合はもちろん影響を受けます。
Next.js
- Next.js 15.xおよび16.x（正式リリース）でApp Routerを使っているアプリは影響下にありま。特にNext.js 15系はReact 19を内部にバンドルしているため、プロジェクトでReactを直接指定していなくても脆弱性を抱えているケースがあります。一方、Next.js 13.xや14.x（安定版）および旧来のPages Routerを使ったアプリ、Edge Runtime上で動くアプリには直接の影響はないとされています。ただし14.x系の一部開発版（canary）はRSCを含んでいたため注意が必要です。
他のフレームワーク/ツール
- React Router（v6.14で試験的にRSC対応）、Waku（Reactのフレームワーク）、Expo（React Native/Web統合環境の一部機能）、RedwoodJS（RSCに対応したSDK）など、RSCを組み込んでいる他のプロダクトも同様に脆弱です。また、ViteやParcelといったビルドツール向けのRSCプラグインを使用している場合も注意が必要です。
クラウドサービス環境
- ReactやNext.jsを使ったWebアプリがデプロイされているクラウド環境全般が対象となります。Wizの調査では、クラウド上の約39%の環境で脆弱なReactもしくはNext.jsのインスタンスが稼働していたとのことです。言い換えれば、約10環境中4環境で何らかの対応が必要な状態だったわけです。特にNext.jsは人気が高く、様々な企業のウェブサービスで採用されています。国内企業でもNext.js製のWebサイトは多数稼働しており、それらが一斉に危険に晒された可能性があります。
ユーザー影響
- 最終的な被害が及ぶのはエンドユーザーや企業のビジネスです。React2Shell自体はサーバー側の脆弱性ですが、侵入された攻撃者はそのサーバー経由で個人データを盗み出したり、Webサイトの改ざん（マルウェア埋め込み）を行ったりできます。例えばECサイトが乗っ取られれば顧客の個人情報やクレジットカード情報が漏洩する恐れがありますし、Webサービスが停止させられれば業務継続に支障が出ます。サーバーの乗っ取りは即、サービス利用者と企業双方に深刻な影響を与えます。

このように、技術的な影響範囲はソフトウェアからクラウドインフラ、さらには事業継続性まで広がります。組織として自分たちが該当するかどうかを速やかに判断し、対策を講じることが重要です。特にNext.js 15/16を使ったWebアプリを公開運用している場合は100%影響を受けると考えて差し支えありません。また、「小規模なサイトだから狙われないだろう」という考えも危険です。今回の攻撃は自動スキャンにより無差別的に行われており、大小問わず脆弱なサイトは軒並み攻撃対象となりました。事実、攻撃開始から数日で数百IPアドレスもの攻撃元が検出されたとの報告もあります。したがって、自社システムが少しでも該当する可能性があるなら、他社より先に対策するくらいの意識が求められます。

対策まとめ

React2Shellへの対策は、何よりまず脆弱性そのものを解消すること（アップデート）が最優先です。その上で、完全に修正が行き渡るまでの間の防御策や、仮に侵入された場合の被害を最小化する施策も講じる必要があります。ここでは多層防御の観点で、組織として取るべき対策をいくつかのレイヤーに分けて整理します。

ソフトウェアアップデート（パッチ適用）
- 最優先で実施すべき対策です。ReactおよびNext.jsの開発チームから既に修正版がリリースされています。Reactの場合は19.0.1、19.1.2、19.2.1へのアップデートでこのRCE脆弱性が修正されています。Next.jsの場合、各メジャーバージョン向けに修正版（例: 15.0.5、15.1.9、15.2.6、15.3.6、15.4.8、15.5.7、16.0.7 など）が公開されています。最新安定版への更新を行うか、Vercel社提供の自動ツール（npx fix-react2shell-next）を使って確実にバージョンアップしてください。この脆弱性にワークアラウンド（設定変更等で無効化する方法）は無く、アップデート以外に根本解決策はありません。まだパッチ適用が済んでいない場合は、サービス影響を考慮した計画を立て一刻も早く適用することが必要です。
WAFによる一時防御
- パッチ適用までの緊急措置として、WAF(Web Application Firewall)で悪用リクエストをブロックする方法があります。主要クラウドベンダー各社はReact2Shell公開直後にWAFルールのアップデートを行いました。例えばAWSではマネージドルール集 (AWSManagedRules) のバージョン1.24に本脆弱性向けのシグネチャが追加されています。Cloudflareも無料プランを含む全ユーザーに向けReact2Shell検知・遮断ルールをデプロイ済みです（ルールIDが公開されておりカスタムWAFでも参照可能）。これらを有効化することで、既知の攻撃パターンについてはある程度防御可能です。ただしWAFは万能ではなく、新たな攻撃バリアント（回避手法）には対応できない恐れがあります。WAF適用はあくまで「猶予を稼ぐ」ための暫定策と心得て、最終的にはバックエンドのパッチ適用で安心できる状態に持っていく必要があります。
侵入検知・監視の強化
- 脆弱性対応とは別に、攻撃の兆候や被侵入の痕跡を見逃さない体制づくりも重要です。具体的には以下のような点に注意します。
  - サーバーのログ監視
    - HTTPアクセスログに通常現れないような特殊なリクエスト（例: next-actionヘッダ付きのPOST）がないか確認します。もし同様のリクエストが過去に来ていれば、攻撃の試行を受けていた可能性があります。またサーバーのエラーログに不審なスタックトレースやE{"digest"という文字列が出力されていないか調べます（これは脆弱性を突かれた際の典型的なエラーパターンです）。
  - ネットワーク通信のモニタリング
    - サーバーから外部への異常な通信がないかを監視します。特にReact2Shellではcurlやwgetが使われてペイロードを外部ダウンロードするケースが多く報告されています。サーバー内部のプロセスからこれらコマンドが実行され、外部の見慣れないホスト（例: windowserrorapis.comといった怪しいドメイン）にアクセスしていないかログを確認しましょう。またDNSクエリやHTTPリクエストで、先述したような攻撃者インフラのIOC（Indicator of Compromise：例えば図に挙げたドメインやIP）への通信が無いかも調べます。
  - サーバー内の挙動分析
    - 攻撃を受けると、サーバー上で普段行わないプロセス実行やファイル改ざんが発生します。具体例として、$HOME/.systemd-utilsのような隠しディレクトリの新規作成、ntpclientなど特定プロセスの強制終了、~/.bashrcなどシェル設定ファイルへの不正なコマンド挿入が確認されています。これらはMINOCATや他のマルウェアが仕掛けられた兆候です。サーバー内の変更監視やプロセス監視を行い、怪しい動きを検知したら直ちに調査・対処しましょう。
クラウド権限の見直し（被害の最小化）
- 侵入を完全に防ぐのが理想ですが、万一攻撃を許してしまった場合でも被害を局所に留める工夫が必要です。React2Shellでは攻撃者が環境変数やメタデータ経由でクラウド資格情報を狙うことが分かっています。ここで漏洩したキーに過剰な権限（例: IAM管理者権限）が付与されていると、攻撃者はクラウド全体を操作できてしまいます。したがって、Webアプリケーションが利用するIAMロールやAPIキーには必要最小限の権限だけを与え、万一それらが漏れても致命的な操作はできないようにしておきます。例えば、フロントエンドサーバーからはデータベース読み書きやストレージアクセスだけ許可し、ユーザー管理やネットワーク設定変更の権限は持たせない、といった設計が望まれます。また、環境変数や設定ファイルに平文で秘密情報を置かないことも重要です（できれば外部のシークレットマネージャーを使い、サーバー上には一時トークンのみ配置する等）。クラウド側にも異常な操作を検知するアラート（例: AWS ConfigやCloudTrailによるIAM権限変更検知）を設定し、万一アカウントが乗っ取られかけても迅速に気づけるようにしておきましょう。
ポストエクスプロイト対策（エンドポイント防御） – 最後の砦として、サーバー内で不審な挙動が起きた際に自動遮断・防御する仕組みも検討すべきです。例えばEDR（Endpoint Detection & Response）やホスト型IPS/IDSを導入しておけば、典型的なマルウェア活動（ファイルの大量暗号化、プロセスインジェクション、暗号通貨マイニングの既知シグネチャなど）を検知してブロックできます。またDockerやKubernetes上で動くアプリであれば、コンテナセキュリティ製品によってコンテナ内の挙動を監視・制御することも可能です。React2ShellではNode.jsプロセスからシェルが起動されたりcurlで外部と通信したりといった異変が発生するため、これらを検出して管理者に通報・隔離する仕組みがあれば被害拡大を防げます。特に重要システムでは、多層的な検知・防御機能を導入し「万一侵入されても被害ゼロ」に抑えられるよう準備しておくことが望まれます。

上記を整理すると、第一にアップデート、次に（アップデート完了までの）WAF防御、並行して監視体制の強化、そして平時からの権限管理・防御策整備という優先順位になります。もちろん自社のリソースや体制によって実施可能な対策は異なりますが、「パッチ適用できないから後回し」だけは避け、可能な限りの手段でこのクリティカルな脆弱性に対処してください。

最後に、やってはいけない対応も念のため触れておきます。「React 18だから大丈夫」と放置するのは危険です。前述の通り、React 18自体は脆弱ではなくてもNext.jsなどで密かにReact 19機能が使われている場合があります。自分のシステム構成を過信せず確認しましょう。また**npm auditの結果だけ見て安心するのも誤りです。Next.jsのように依存関係に現れない形でバンドルされているとスキャンから漏れます。さらに「テスト環境だから後回し」**も禁物です。テスト中でもインターネットに公開されていれば攻撃は来ますし、VercelやNetlifyのプレビュー環境などは実質本番と同等に狙われます。すべての公開環境で一律に対策を適用するようにしてください。

経営層向けまとめ

脆弱性の概要

「React2Shell」はReactという広く使われるソフトウェアに潜む深刻な欠陥です。これを悪用されると、外部からのわずか1回の通信でサーバーを乗っ取られ、自由に操作されてしまいます。技術評価指標で最高のCVSS 10.0と判定されており、過去に大騒動となった「Log4Shell」に匹敵する危険性を持つとされています。

ビジネスへの影響

攻撃者にサーバーを乗っ取られると、そこに保存された顧客データや機密情報の漏洩、サービスの改ざんや停止といった被害に直結します。加えて、サーバー経由でクラウド認証情報が盗まれれば、弊社全体のクラウド資産（データストレージ、他のサーバー群等）まで連鎖的に侵入されかねません。実際に本脆弱性は公表直後から悪用が始まり、海外の政府系ハッカーやサイバー犯罪グループが多数の企業システムに攻撃を仕掛けたと報告されています。日本企業も例外ではなく、同様のスキャン攻撃の標的となった可能性があります。対策が遅れれば、業種問わず顧客信頼の失墜や法的・金銭的損失に繋がるリスクが高いといえます。

◆現状と緊急度

脆弱性判明後、開発元から修正アップデートが既に提供されています。しかし攻撃のスピードが非常に速く、パッチ公開前後から被害が出始めている状況です。もし自社で該当するシステム（React 19系、Next.js 15/16系など）を利用している場合、対策の猶予はほとんど残されていません。公的機関も注意喚起を行っており、米国CISAはこの脆弱性を特に危険な「知られた攻撃対象の脆弱性 (KEV)」リストに即日追加しました。経営層としてもこの問題を重大インシデントと捉え、緊急対応を指示する必要があります。

奨される対策

最も重要なのは対象システムのアップデートです。開発チームやIT部門に対し、Reactおよび関連フレームワークを最新の安全なバージョンへ速やかに更新するよう指示してください。また、更新が適用されるまでの間、可能であればWAF（ファイアウォール）で一時防御策を講じ、攻撃をブロックする設定を行います。加えて、システムログの監視強化や、不審な挙動がないかの点検を実施し、既に侵入されていないか確認することも重要です。万一過去に侵入されていた場合に備え、環境変数やAPIキーのローテーション（再発行）も検討すべきです。クラウド上の権限設定も見直し、仮に認証情報が漏洩しても被害が広がらないよう最小権限の原則を適用します。

◆ 経営層への報告と今後の対応

本脆弱性への対応状況（該当システムの洗い出し、パッチ適用計画、暫定措置の内容、監視結果など）を速やかに報告させ、必要ならリソースを投入してでも迅速な対処を行ってください。特にサービス提供企業においては、万一の情報漏洩に備えた顧客対応計画も視野に入れるべき重大性です。今回のケースはゼロデイ攻撃（公表と同時に攻撃開始）の側面があり、今後も類似の緊急事態が起こり得ます。経営層として、平時からのセキュリティ投資（脆弱性管理体制や検知・対応力の強化）の重要性を改めて認識し、社内のセキュリティ文化を推進していくことが肝要です。今回のReact2Shell対応を教訓に、組織全体で防御力を向上させましょう。

MENU