React2Shell（CVE-2025-55182）の脆弱性とは？生成AI時代の攻撃と対策

はじめに：React2Shell（CVE-2025-55182）がDXと生成AIにもたらすインパクト

React2Shellとして知られるCVE-2025-55182は、React Server Componentsに潜むリモートコード実行（RCE）の脆弱性を指します。生成AIを活用する企業が増える中、この問題はDX推進に幅広い影響を及ぼします。特に自動化やクラウド活用が進む現場では、わずかなセキュリティ欠陥が業務や信頼性に重大な損失をもたらす可能性があります。

本記事では、React2Shell（CVE-2025-55182）の技術的背景や攻撃シナリオ、パッチ適用や運用上のポイントを体系的に解説します。生成AI時代のセキュリティとして、どのように脆弱性を管理し、DX戦略を安全かつ効率的に展開できるかを考える参考にしてください。

React2Shell（CVE-2025-55182）の技術的概要と影響範囲

脆弱性の本質とReact Server Components・Flightプロトコル

React2Shell（CVE-2025-55182）の根本原因は、React Server Components（RSC）で信頼できないデータを不適切にデシリアライズしている点にあります。RSCはサーバー側でUI部品を動かし、クライアントには軽量化された出力を返す設計です。そのトランスポート層として用いられるのがFlightプロトコルで、複雑なデータをストリーミング形式でシリアライズ・デシリアライズする仕組みを備えています。デシリアライズ時の検証が不十分な場合、攻撃者が細工したHTTPペイロードを送り込み、RSCの内部処理を乗っ取ってリモートコード実行を果たせる可能性があります（参照*1）。RSCサーバーは自動的に渡されたデータを複数のオブジェクトへ連結するため、プロトタイプチェーンの仕組みを悪用されると任意のコードを呼び出せる脆弱性につながります。実際、Reactチームによれば、Flightプロトコルのデコードロジックは2025年11月末に指摘されており、サーバー機能を利用していない場合でも影響を受けるケースがあるとされています（参照*2）。

影響を受けるバージョンとコンポーネント構成

CVE-2025-55182の影響対象は、Reactの19.0系、19.1系、19.2系のほか、“react-server-dom-webpack”や“react-server-dom-parcel”、“react-server-dom-turbopack”などRSCを扱うパッケージが含まれます（参照*3）。これらのパッケージはJavaScriptバンドラーであるWebpackやParcel、Turbopackと連携し、フレームワーク全体のサーバー側処理に深く組み込まれます。そのため、React Server Componentsを直接呼び出していなくても、依存関係によって脆弱部分がロードされる場合があります（参照*4）。Next.jsの15〜16系や一部19系のReact Router、Wakuなども例外ではありません。実際のコードがServer Functionエンドポイントを使わないように見えても、フレームワーク側のモジュール依存によって脆弱部分がロードされる可能性が指摘されています。こうした広範囲な影響から、複数のセキュリティ機関が緊急対策を促しており、攻撃者による自動スキャンも多数確認されています（参照*5）。

CVSSスコアと公表・対応のタイムライン

本脆弱性のCVSSスコアは10.0とされ、危険度は最大級です。2025年12月3日にCVE-2025-55182として公表されると同時に、主要なセキュリティベンダーやOSSコミュニティが注意喚起を発信し、5日にはPoC（概念実証コード）が一般公開されました（参照*6）。12月10日には国内でも実際の攻撃が報じられ、12月12日までに国家支援型グループの悪用が明るみに出て、追加の脆弱性（CVE-2025-55184、CVE-2025-67779など）やソースコード漏洩リスク（CVE-2025-55183）への警戒も高まりました（参照*3）。多くの国内外機関はこれらを最優先で対処すべきとし、ファーストパーティだけでなく依存関係まで含めたアップグレードを推奨しています。

React2Shellを悪用した攻撃シナリオと生成AI時代のリスク

未認証リモートコード実行とクラウド環境の攻撃シナリオ

React2Shell脆弱性を悪用する攻撃者は、単純なHTTPリクエストを用いて認証なしにサーバー上でコード実行を試みます。攻撃が成功した場合、サーバー環境変数や機密情報の取得、さらにはクラウドリソースへの水平展開も可能です。調査機関によれば、脆弱なRSCエンドポイントの多くがコンテナやクラウド上に展開されており、資格情報の窃取や仮想通貨マイニングツール（XMRigなど）の設置が確認されています（参照*7）。AWSによるハニーポット観測でも攻撃が活発化しており、侵入の難易度が極めて低いことが示唆されています。また、パブリッククラウドでリスキーな権限設定が残されている場合、ワークロードを乗っ取られるリスクが一段と高まります。

生成AI・業務自動化ワークフローへの攻撃チェーン

DX推進の一端として、自然言語処理モデル（LLM）などの生成AIを活用した業務自動化が増えています。React2Shellを悪用してサーバー内部に侵入されると、AIモデルの学習データや推論エンジンそのものが外部から改ざんされるリスクが高まります。ユーザーがAI導入のみに着目していても、裏側でRSC機能を組み合わせている場合、攻撃チェーンの一部として狙われる可能性があります（参照*8）。特に業務プロセスを自動化する際に外部とのAPI連携やクラウドリソース管理を行うと、コードが漏えいまたは改ざんされた時点で大規模な業務停止やデータ改ざんが発生するおそれがあります。生成AIのクラウドサービスは重要データのやり取りが頻発するため、脆弱性悪用をきっかけとした情報漏洩リスクに十分な対策が必要です。

国家支援型グループを含む攻撃事例と被害動向

最新の報道では、中国系とされる「Earth Lamina」や「Jackpot Panda」などがReact2Shellを利用し、世界的な無差別攻撃を進めていると発表されています。Palo Alto Networksの観測データによると、30以上の組織が攻撃を受け、AWS構成情報の窃取やリモートコード実行が確認されました（参照*9）（参照*10）。また、FBIはこの脆弱性を急ぎ修正するよう呼びかけており、急速な悪用が見られる状態と報じています。Wizの調査によれば、クラウド環境全体の約4割が脆弱なインスタンスを内包している可能性があるとのことで、2021年のLog4j問題に匹敵する深刻度だと指摘されています。韓国のTioriが「ReactGuard」なる検知ツールを無償提供し、パイオリンク社が自社WAF向けの防御モジュールを配布するなど、急ピッチでの対策提供が進んでいます。

React2Shellに対する基本対策：パッチ適用と構成管理

ReactおよびNext.jsの修正版バージョンと適用優先度

本脆弱性に対処する最も重要なステップは、早急なパッチ適用です。Reactでは19.0.1、19.1.2、19.2.1が修正版として公開されており、Next.jsでは15.0.5、15.1.9、15.2.6、15.3.6、15.4.8、15.5.7、16.0.7などが脆弱性解消に対応するバージョンです（参照*11）。これらの修正版では、react-server-dom～系パッケージのRSC実装が強化され、デシリアライズの欠陥が修正されています。今後新たな脆弱性が発見される可能性もあるため、単なるパッチ適用だけでなく、短期間でアップデートを繰り返す管理体制が求められます。特にクラウド上で自動デプロイを行っている場合、思わぬコンポーネントが脆弱性を含むライブラリにリンクしているケースを見落とさないよう注意が必要です。

サードパーティフレームワークと依存関係管理

ReactやNext.js本体だけでなく、周辺ツールやプラグイン、サードパーティ製フレームワークにも注意が必要です。例えばExpo、React Router、Waku、@parcel/rsc、@vitejs/plugin-rscなど、RSCサポートを含むさまざまなパッケージが脆弱性の影響を受ける可能性があります（参照*12）。依存ツリーを可視化し、問題のあるライブラリが含まれていないかを常に確認することが大切です。npm auditなどのコマンドで脆弱性レポートを活用し、アップデートできるものは速やかに更新しましょう。さらに、CI/CDパイプラインに自動テストとセキュリティスキャンを組み込み、本番環境にリリースする前にアラートを受け取れる体制を整えることで、DX推進の高速化とセキュリティ対策を両立できます。

DX推進・開発スピードとパッチ運用の両立

DXの取り組みはスピードが重視されますが、安全な開発体制なしに拡大を続けると脆弱性の温床となる可能性があります。パッチ適用が急がれる脆弱性が公表された場合、古いバージョンを運用し続けるチームがいると組織全体が危険に晒されます。刷新したアーキテクチャへの移行時には、最新のセキュリティパッチを前提としたコンテナテンプレートやイメージを使用し、ローリングアップデートを自動化する方法が有効です（参照*3）。社内で複数のアプリケーションを同時開発している場合、Reactのバージョンアップが後回しになりがちですが、脆弱性の修正は最優先事項です。手間のかかるパッチ適用を効率化し、現場の抵抗感を最小限に抑えることが組織的課題となります。

React2Shellに備える検知・監視とインシデント対応

IoCとログ監視の具体的なチェックポイント

攻撃に早期対応するためには、インジケータ（IoC）を把握し、ログ監視を強化することが重要です。ApacheやNginxなどのアクセスログを定期的に分析し、next-actionヘッダやrsc-action-idヘッダなど不審なHTTPリクエストが発生していないか確認します（参照*5）。さらに/tmp以下へのファイル書き込みや、/etc/passwdの読み取り試行が検出された場合、リモートコード実行に成功している可能性が高いと考えられます。企業の内部ネットワークへ不正リクエストが流入していないか、侵入検知システム（IDS）やエンドポイント側のログ、クラウド上の認証ログなど複数ソースをクロスチェックし、潜在的な被害範囲を見逃さないようにしましょう。

Surface Scannerなど検出ツールの活用

React2Shellへの事前対応策としてSurface Scannerのような専用ツールも公開されています。PythonベースのスクリプトでRSCエンドポイントが露出しているかどうかを検出し、脆弱性の有無を大まかに判定する仕組みです（参照*13）。ただし、固定ペイロードだけではバンドラーや最適化の影響で検出しきれない場合があるため、検知ツールの結果を過信せず、網羅的な管理やパッチ適用を怠らないことが大切です。実際の環境でPoCレベルの攻撃を試す場合は、安全な検証環境を用意するなど運用上の配慮も必要です。

クラウドWAFと多層防御による緩和策

React2Shellの緩和策として、クラウドWAFの導入や境界セキュリティの強化が推奨されます。AWSはマネージドルールのバージョンアップによって一部の攻撃パターンをブロックする機能を提供しているほか、AzureやGoogle Cloudでも独自のWAFルールを発行しています（参照*14）（参照*15）。ただし、WAFは追加防御であり、根本的対策であるパッチ適用とアプリケーションコードの修正を置き換えるものではありません。複数の防御レイヤーを重ねることで、万が一脆弱なエンドポイントにアクセスを許してしまっても、リスクを最小化できる可能性があります。CISAのKnown Exploited Vulnerabilitiesカタログに本脆弱性が登録され、連邦機関はBOD 22-01に基づく修正期限が設定されるなど、世界的に多層対策が進んでいます（参照*16）。

生成AI・DXプロジェクトにおけるReact2Shellリスク管理の実践

AIサービス設計におけるRSC利用とセキュリティ要件定義

生成AIを組み込むプロジェクトでは、ユーザーとの対話をリアルタイムに処理するため高度なサーバーサイド技術を活用します。React Server Componentsを利用したアプリケーションは、クライアントへのデータ量を減らす利点がある一方、デシリアライズがセキュリティホールとなる事例も見られます。AI導入フェーズからセキュリティ要件定義を行い、RSCを使う各モジュールでのデータ処理フローを明確化することが重要です（参照*15）。さらに、耐障害性の観点で脆弱性が顕在化した際でも業務継続ができるよう、負荷分散やサーバー分離などのアーキテクチャ設計を見直すことが効果的です。

LLMエージェント・業務自動化基盤への影響評価プロセス

ローカルのLLMエージェントを動かす場合や業務自動化のフレームワークを管理する際、内部的にReactやNext.jsを採用するケースが増えています。React2Shellは認証なしでのRCEという致命的な属性を持つため、業務自動化ワークフローに組み込む要素がある場合、影響評価の優先度が高まります（参照*17）。評価プロセスとしては、（1）RSCが有効化されているコンポーネントの洗い出し、（2）AI関連モジュールへのデータ送信経路、（3）クラウドサービスとの連携箇所、（4）パッチ＆依存関係管理の担当割り当て、の順で影響範囲を確認します。特にリソースへのアクセス権限が大きい自動化基盤は、外部からの不正コード実行を許すと被害が広範に及ぶ可能性がある点に注意が必要です。

組織的な脆弱性管理と改善サイクルの確立

React2ShellがDXや生成AIの文脈まで波及したように、組織全体のシステム設計に潜むリスクを把握する姿勢が今後さらに重要になります。パッチ適用を技術担当だけに任せるのではなく、経営層も重要度を理解した上で必要なリソースを確保し、組織的に脆弱性管理を運用することが求められます。継続的な改善サイクルを回すためには、脆弱性情報の早期把握、リリース管理手順の自動化、インシデント時の報告フローの最適化がポイントです。DX推進においてはスピードと安全性のバランスをとることが重要であり、React2Shellのような致命的脆弱性を教訓に、定期的なパッチ作業やAI・業務自動化の検証環境整備を進めていくことが推奨されます。

おわりに：React2Shell対応を起点とした安全な生成AI・DX推進へ

React2Shell（CVE-2025-55182）は、React Server Componentsの脆弱性から生じる重大なリスクですが、早期のパッチ適用と多層防御によって対応が可能です。国内外で攻撃事例が相次ぎ、DX推進に向けたプラットフォームそのものを脅かす事態となっています。

この課題を契機として、依存ライブラリの棚卸しやパッチ管理の仕組みを再点検する機会にもなります。生成AI時代においては、アプリケーション構成を正しく理解し、各種リスクを総合的に判断することが不可欠です。安全なDXと効率的なAI活用を実現するため、本記事を参考に対策を強化してください。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、82万部（2025年3月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））