フロントエンドはもはや単なるフロントエンドではない
一部の脆弱性はパッチが適用され、ほどなく忘れ去られます。一方で、私たちが使うアーキテクチャのリスクモデルを考え直させるものもあります。CVE-2025-55182は後者のカテゴリに入ります。
2025年12月3日、Reactチームは、React 19およびReact Server Componentsを使用するNext.jsバージョンに影響するクリティカルなリモートコード実行の脆弱性を発表しました。研究者たちはほどなく、この脆弱性にReact2Shellという名前を付けました。Log4Shellになぞらえる呼び方もこの時点で登場しました。この比喩は大げさに見えるかもしれませんが、根拠のないものではありません。
React2Shellをクリティカルなものにしている特徴は3つあります。広く使われている現代のWebフレームワークに影響する。認証を要さずにリモートからトリガーできる。「フロントエンド」と見なされているフレームワークを通じて、サーバー側でコードを実行するリスクを生む。最後の点が特に重要です。
Reactは長らくインターフェース層として考えられてきました。しかしReact Server Componentsと現代のSSRアーキテクチャによって、この区別は変わりました。いまや一部のReactコンポーネントはサーバー側で直接動作します。これにより、フロントエンドフレームワークはアプリケーションセキュリティの観点からbackendの面の一部となります。React2Shellはこの移行のセキュリティ上の帰結を可視化しました。
攻撃者が、細工したHTTPリクエストでサーバー側のRSCハンドラーを標的にできるなら、問題はもはやブラウザで動作するJavaScriptだけではありません。問題は、アプリケーションプロセス、環境変数、データベース接続、ファイルシステム、内部サービスへのアクセスです。だからこそReact2Shellは単なるReactの脆弱性ではなく、現代のWebアーキテクチャが誤って分類してきたセキュリティ面なのです。
脆弱性の概要
この脆弱性とは？
React Server Componentsは、React 19および現代のNext.jsアーキテクチャで使われる重要なモデルです。このモデルでは、一部のコンポーネントはクライアント側で、一部はサーバー側で動作します。サーバー側で動作するコンポーネントは、クライアントに従来の意味でのHTMLだけを送るわけではありません。その代わりに、Reactツリーを再構築できるようにするための特別なシリアライゼーション形式が使われます。この形式は高速で、表現力が高く、フレームワークに柔軟性をもたらします。しかしこの柔軟性は同時にリスクを生みます。
CVE-2025-55182は、影響を受けるバージョンにおいて、このシリアライゼーションとデシリアライゼーションのプロセスが悪用されうることに関係します。特別に細工されたRSCリクエストは、サーバー側のハンドラーが攻撃者の制御するデータを安全でない形で処理する原因となりえます。このプロセスの中で、攻撃者はアプリケーションプロセス内でコードを実行する機会を得うるのです。
この種の脆弱性はセキュリティの世界にとって新しいものではありません。Java RMI、Python pickle、.NET BinaryFormatterなどの技術で何年も見られてきた「信頼できないデータのデシリアライゼーションによるコード実行」というクラスの、現代のWebフレームワーク世界における新たな一例です。新しいのは、このパターンがReact Server Componentsのようなフロントエンド由来と見なされるアーキテクチャに現れたことです。
脆弱性の影響を高めるクリティカルな点はこうです。RSCハンドラーは、一部のデプロイメントにおいて、認証や認可が適用される前に攻撃者の制御するデータを処理しうる。これにより、この脆弱性は従来の「認証済み管理パネルのバグ」というカテゴリから外れます。インターネットに公開されたRSCエンドポイントがあれば、攻撃者が必要とするのは適切に細工された1つのリクエストだけです。
Log4Shellは現代のソフトウェアセキュリティにおける転換点となりました。その理由は、単にLog4jにクリティカルな脆弱性が見つかったことではありません — 本当の理由は、Log4jがほぼあらゆる場所で使われていたこと、そして攻撃が極めて低い閾値でトリガーできたことでした。攻撃者の制御する1つの文字列が、正しいコード経路に到達すれば、リモートコード実行につながりえたのです。React2Shellは、現代のWebスタックに置き換えられた同じ特徴を共有しています。Reactは現代のWeb開発で最も広く使われるフレームワークの1つであり（業界推計では新規Webアプリケーションの約40%）、Next.jsはReactベースの本番アプリケーションで強い地位を占め、RSCは現代のNext.jsアーキテクチャのデフォルトです。細工されたHTTPリクエスト1つ、認証なし、完全なサーバー乗っ取り。多くのチームはいまだにReactを「フロントエンド」と分類します — その反射はもはや不十分です。アプリケーションコードの一部はサーバーで動作し、攻撃者にとってのbackend的影響を生みます。「フロントエンドのLog4Shell」は単に印象的な見出しではありません。より深いアーキテクチャ上の警告です。フロントエンドフレームワークはもはやbackendセキュリティの規律から免除されません。
攻撃チェーンはどのように機能するか
React2Shellクラスの攻撃は、外から見るとかなり単純に見えることがあります。しかしその影響は、サーバー側の実行コンテキストゆえに大きいのです。
ターゲットの特定
攻撃者はまず、React 19またはRSCを使用する最近のNext.jsアプリケーションを特定しようとします。このフィンガープリンティングのプロセスはたいてい難しくありません。RSCエンドポイントは、特徴的なURLパターン、コンテンツタイプ、レスポンス形式、フレームワークの振る舞いによって特定できます。インターネット全体のスキャナーや自動偵察ツールは、この種の面を大規模に列挙できます。脆弱性が発表された後の最初のリスクは、標的型攻撃に先立つ自動スキャンの波です。
細工されたRSCリクエスト
攻撃者はRSCエンドポイントに、特別に形成されたHTTPリクエストを送信します。このリクエストは外から見て完全に異常に見える必要はありません。コンテンツタイプ、ヘッダー構造、エンドポイントのターゲットは、正当なRSCトラフィックに似ていることがあります。危険な部分はペイロードの中にあります — サーバー側のデシリアライゼーションプロセスを悪用するように細工されます。異なるガジェットチェーン、異なるエンコーディング手法、異なるフレーミング形式で、同じ効果を生み出せます。これが検出を難しくします。
サーバー側のデシリアライゼーション
影響を受けるバージョンでは、サーバー側のRSCハンドラーが受け取ったペイロードを安全でない形で処理します。デシリアライゼーションが認証や認可のチェックより前に行われる場合、攻撃者が認証されていないことは攻撃を妨げません。この段階で、攻撃者はアプリケーションが動作するプロセス内でコードを実行する機会を得うるのです。攻撃の本当の決壊点はここです — 攻撃者はもはやブラウザではなく、サーバー上で影響を生むからです。
アプリケーション権限での前進
サーバー側でのコード実行は、単一のコマンドを実行することだけを意味しません。攻撃者はアプリケーションプロセスが持つ権限にアクセスできます — 環境変数、データベース接続情報、APIキー、ファイルシステムアクセス、内部サービスアクセス、ログとキャッシュのシステム、queue/storage/messagingのインフラ、cloud metadataエンドポイント、サービスアカウントのトークン。ここから先、攻撃は従来のポストエクスプロイテーションの段階へと移ります。シークレットの収集、永続化、横方向の移動、データの持ち出しです。
痕跡の隠蔽
React2Shellのような脆弱性では、最初のリクエストは正当なRSCトラフィックに似ていることがあります。攻撃者はエクスプロイトの試行を通常のトラフィックパターンの中に紛れ込ませようとしうるものです。アプリケーションレベルで十分なロギングがなければ、最初のトリガーとなったリクエストを見つけるのは難しくなります。インシデント後の調査には、アクセスログだけでは不十分なことがあります — RSCエンドポイントに来たペイロード構造、異常なシリアライゼーションパターン、認証不要のPOST試行、異常なエラーコードを併せて精査すべきです。
WAF検出はなぜ難しいのか
WAFは多くの攻撃クラスにおいて強力な第一防御層です。SQL injection、XSS、path traversal、既知のエクスプロイトペイロード、プロトコル違反といったパターンを大規模に捕捉できます。一方でReact2Shellクラスの脆弱性は、WAF検出の観点からより難しいものです — 3つの理由によります。
トラフィックが正当なRSCトラフィックに似ていることがある
エクスプロイトのリクエストは、同じエンドポイント、同じコンテンツタイプ、類似のヘッダー構造を使えます。URLやコンテンツタイプだけでブロックすると高い誤検知を生みうるものです。RSCトラフィックを完全に遮断すると機能を損ないます。WAFが単に「RSCリクエストを見た、ブロックしよう」というアプローチでは不十分です — ペイロード構造、リクエストパターン、エンドポイントの振る舞い、アプリケーションコンテキストを併せて評価する必要があります。
ペイロードは多形的である
デシリアライゼーションのエクスプロイトは、異なる形で表現できます — 異なるガジェットチェーン、異なるエンコーディング、異なるネスティング構造、異なるシリアライゼーションのバリエーション。同じ悪用の目的を、多くの異なるペイロード形式で達成できます。これは静的なシグネチャの寿命を縮めます。あるシグネチャが特定の変種を捕捉している間に、攻撃者は同じ脆弱性を異なるペイロード構造で再び試みうるのです。
アプリケーションコンテキストが必要である
React2Shellの効果的な検出は、プロトコルレベルだけでは行えません。ペイロードがRSCフローの中で何を意味するのか、どの構造が通常は受け入れられるべきでないのかを理解する必要があります。このアプリケーションコンテキストなしには、WAF検出は部分的なものにとどまります。恒久的な解決策はフレームワークのパッチです — WAFは、パッチ適用の期間中にスキャンと低スキルのエクスプロイト試行を軽減しますが、パッチ適用の代わりにはなりません。
企業は何をすべきか
React2Shellのような脆弱性に対する正しい対応はパニックではなく、優先順位付けされた対処です。以下の手順は順番に取り組むべきです。
React 19およびNext.js RSCアプリケーションをインベントリ化する
最初のステップは、どのアプリケーションが影響を受けるかを把握することです。主要な本番アプリケーションだけでなく、ステージング環境、パートナーポータル、社内管理パネル、デモ環境、一時的な公開、edgeデプロイメント、serverless関数、preview環境、そして古くてもインターネットに公開されているNext.jsアプリケーションもインベントリに含めるべきです。所有権の情報もインベントリの一部であるべきです。優先順位：インターネットに公開されているか、RSCを使用しているか、認証前のエンドポイントがあるか、機密データや内部サービスへのアクセスがあるか、高権限のサービスアカウントで動作しているか。
公式パッチを適用する
恒久的な解決策は公式パッチの適用です。Reactセキュリティアドバイザリと関連するフレームワークの告知を、影響を受けるバージョンとアップデート経路についてフォローすべきです。依存関係の衝突、テストの破損、デプロイメントのプロセスのために遅れている場合でも、通常のメンテナンスサイクルに委ねるべきではありません。このクラスの脆弱性については、パッチの優先度を最高レベルにすべきです。インターネットに公開され、RSCを使用し、機密データを扱うアプリケーションでは、パッチ適用の期間は時間あるいは日の単位で考えるべきです。
RSCエンドポイントの検証を厳格化する
パッチが遅れている場合や、移行の過程で追加の防御が必要な場合、RSCエンドポイントに追加の検証を適用すべきです。期待されるコンテンツタイプの強制、ペイロードサイズの制限、スキーマ検証、不正な形式のシリアライゼーションシーケンスの拒否、認証前のRSCアクセスの削減、予期しないHTTPメソッドの遮断、エンドポイント単位のrate limit、異常なヘッダーとボディの組み合わせのフラグ付け。これらの制御はパッチを代替しませんが、攻撃面を狭めます。
2025年11月以降のログを精査する
脆弱性が発表される前にも、一部の攻撃者がエクスプロイトの試行を行っていた可能性を評価すべきです。2025年11月以降、RSCエンドポイントに来たトラフィックを精査してください。認証不要のPOSTリクエスト、異常なペイロードサイズ、予期しないシリアライゼーション構造、不正な形式のリクエスト、通常のユーザーフローと関連しないRSC呼び出し、単一IPからの多数の変種試行、エラーコードの増加、アプリケーションのクラッシュや再起動の事象、RSCエンドポイントでの異常なlatencyの増加。悪用成功の可能性がある場合は、シークレットのローテーション、サービスアカウントの見直し、container imageの検証、ファイルシステムの変更分析、内部ネットワークの移動の調査を行うべきです。
WAFマネージドルールを有効にする
TR7を含む主要なWAFプロバイダーは、React2Shellの攻撃パターンに向けたマネージドルールを公開しています。これらのルールは、自動スキャンの波を軽減し、既知のエクスプロイト変種を捕捉し、低スキルの攻撃を遮断し、RSCエンドポイントのトラフィックにおける異常の可視性を提供し、パッチが適用されるまでの追加の保護層を作るのに役立ちます。WAFルールを絶対的な保証と見なすべきではありません — ペイロードの多形性とアプリケーションコンテキストのために、WAFが捕捉できない変種があるかもしれません。正しい順序：まずパッチ、次にWAFによる多層防御。
次のフレームワーク脆弱性に備える
React2Shellは単一のCVEではありません。現代のフレームワークアーキテクチャが、セキュリティテストを経るべき新たな面を生んでいることを示しています。React Server Components、SSR、edge rendering、server actions、streaming response、フレームワーク内のシリアライゼーションプロトコルは、従来のフロントエンドセキュリティモデル以上のものを要します。これらの面をbackendのように脅威モデリングしてください。どのフレームワークコードがサーバーで動作しているか、どのエンドポイントが自動生成されているか、デシリアライゼーションやシリアライゼーションはどこで行われているか、認証はどの段階で適用されているか、server actionはどの権限で動作しているか、フレームワークのエンドポイントはロギングされているか、rate limitはあるか、preview/staging環境はインターネットに公開されているか。
React2Shellの最も重要な教訓は、脆弱性のクラスが新しいことではありません。むしろ逆に、脆弱性のクラスは非常になじみ深いものです。信頼できないデータがデシリアライズされ、コード実行につながること。新しいのは面です。この脆弱性は、従来のbackendセキュリティの問題が、フロントエンド由来のフレームワークアーキテクチャの中に現れうることを示しました。2つの帰結があります。第一に、フロントエンドフレームワークのチームは、いまやbackendフレームワークのチームが担うセキュリティ上の責任の一部を担います — サーバー側で動作するコンポーネント、フレームワークプロトコル、server actions、シリアライゼーション層は、攻撃者の目でテストされなければなりません。第二に、企業のセキュリティチームは、React、Next.js、Remix、Astroなどの現代のフレームワークを、クライアント側技術としてだけ分類すべきではありません — これらのフレームワークはほとんどのデプロイメントでbackend的な振る舞いを生みます。セキュリティアーキテクチャ上のカテゴリは変わるべきです。サーバーで動作するフロントエンドコードは、backendコードです。
TR7の各層はReact2Shellクラスの脅威にどう応えるか
React2Shellのような脆弱性では、第一の解決策はパッチです。しかしパッチが適用されるまでの間、そしてパッチ適用後も、類似クラスのリスクに対しては多層防御が必要です。TR7のWAAPアプローチは、この種の脅威に複数の層で応えます。
WAFマネージドルール
TR7 WAFは、React2Shellの攻撃パターンをプロトコル、エンドポイント、ペイロード構造のレベルで検出するように調整されたマネージドルールを提供します。新しいエクスプロイト変種が現れるたびに、ルールセットが更新されます。インターネット全体で始まる自動スキャンと低スキルのエクスプロイト試行に対する第一防御層です。
RSCエンドポイントでのレート制限
アプリケーションを認識するレート制限は、自動偵察とエクスプロイト変種の試行を軽減します。攻撃者は多数のターゲットで多数のペイロードを試みます — エンドポイント単位のrate limitはスキャン速度を下げ、攻撃の経済性を崩します。
AGSによる認証
TR7 AGSは、内部アプリケーションや管理パネルに対して、リクエストがアプリケーションに到達する前に認証を強制できます。RSCエンドポイントが認証不要のままインターネットに公開されるのを防ぎます。最小権限と条件付きアクセスのポリシーが適用されます。
リアルタイム分析
RSCエンドポイントのトラフィックにおける異常なペイロード構造、予期しないリクエストパターン、異常なエラー率、通常とは異なるリソース分布は、リアルタイム分析でフラグ付けできます。個々のリクエストは正当に見えることがあります。セッションやリソースのレベルで攻撃の試行が浮かび上がります — この可視性は多形的なペイロードにおいて特に重要です。
フォレンジックロギング
RSC経路のリクエスト/レスポンスの詳細、セッションコンテキスト、WAFの判断、異常シグナルが、インシデント後の再構成のために利用できるようになります。セキュリティチームは「どのペイロードが来たか、どのエンドポイントが影響を受けたか、どのセッションコンテキストで起きたか、どのデータがリスクにさらされたか」という問いを調査できます。
ZeroLeakによる高価値の分離
一部のReact/Next.jsアプリケーションは、ありふれたWebアプリケーションではありません — 金融パネル、顧客PIIコンソール、法務文書ポータル、管理者インターフェース。これらのアプリケーションには、ZeroLeakのビジュアルブラウザ分離が追加のアーキテクチャ上の制御を提供します。ユーザーはピクセルストリームのみを見ます。DOM、JavaScript、APIレスポンス、セッショントークンは送信されません。
結論：まずパッチ、次に恒久的なアーキテクチャの教訓
React2Shellに対する第一かつ最も重要な対応は明快です。影響を受けるReact 19およびNext.js RSCアプリケーションを見つけ、公式パッチを適用すること。このステップは先延ばしにすべきではありません。認証を要さないリモートコード実行の脆弱性は、とりわけ広く使われるフレームワークの面においては、最優先のセキュリティインシデントです。
しかしこの脆弱性は、単なるパッチ適用のタスクとして片付けるべきではありません。React2Shellは現代のWebアーキテクチャについてのより大きな教訓を与えます。フロントエンドフレームワークはもはや、ブラウザで動作するUIコードだけではありません。Server Components、SSR、server actions、edge runtimeといったモデルは、フロントエンドとbackendの間の境界を曖昧にします。
そのため、セキュリティチームの脅威モデルも変わるべきです。React、Next.jsなどのフレームワークにおいて、サーバーで動作するすべての経路は、backendセキュリティの規律で扱われるべきです。シリアライゼーションとデシリアライゼーションの層は精査されるべきです。フレームワークによって自動生成されるエンドポイントはインベントリ化されるべきです。認証の順序とエンドポイントの露出は明確にテストされるべきです。
React2Shellの短い教訓はこうです。サーバーで動作するフロントエンドコードは、backendのリスクである。
出典
CVE-2025-55182 React2Shellを含む2025年12月のクリティカルCVEの業界分析。https://strobes.co/blog/top-cves-of-december-2025/
React2Shellの発表と攻撃の状況に関する独立した報道。https://securityboulevard.com/2026/01/top-cves-of-december-2025/
CISAによる実環境での悪用の追跡。https://www.cisa.gov/known-exploited-vulnerabilities-catalog
まずパッチ、次に多層防御
Reactセキュリティアドバイザリのパッチを、影響を受けるすべてのアプリケーションに適用してください。RSCエンドポイントをインベントリ化し、過去のトラフィックを精査し、パッチ適用の期間中はWAFマネージドルールで追加の保護を確保してください。TR7 WAF、AGS、リアルタイム分析、フォレンジックロギング、ZeroLeakの分離は、React2Shellクラスの脅威に対して多層防御を提供します。
TR7 WAFを見る