2025年12月、React Server Components（RSC）のコア部分において、**CVSS 10.0（Critical）**を記録する極めて深刻な脆弱性 CVE-2025-55182（通称: React2Shell） が報告されました。
この脆弱性は、RSCのデータ転送プロトコルである「Flight」のデシリアライズ処理に起因しており、リモートからの任意コード実行（RCE）を可能にします。すでに日本国内を含む広範囲で、マルウェア 「ZnDoor」 を用いた組織的な攻撃が観測されています。
本記事では、この脆弱性の技術的背景から、攻撃の痕跡（IoC）の調査方法、そして恒久的な対策までを、実務エンジニア向けに体系的に解説します。
1. 脆弱性の核心：Flightプロトコルのデシリアライズ不備#
CVE-2025-55182 の本質は、**「信頼できないデータの安全でない復元」**にあります。
Flightプロトコルとは#
RSCでは、サーバーでレンダリングされた結果をクライアントに送る際、Flight と呼ばれるJSONを拡張したような特殊な形式を使用します。
クライアントからサーバーへのアクション（Server Actions）時にも、引数やメタデータがこの形式でシリアライズ・デシリアライズされます。
なぜRCEが起きるのか#
脆弱なバージョンのReactでは、このシリアライズされたデータをデコードする際、特定の予約されたキーワードや構造体に対して適切なバリデーションを行わずに動的なオブジェクト生成（および関数のバインド）を許容していました。
攻撃者は、巧妙に細工した Flight ペイロードを HTTP POST リクエストとして送信することで、サーバー上のランタイムで意図しないコードパスを実行させることが可能です。
2. 実効攻撃：マルウェア「ZnDoor」による侵害#
この脆弱性を突いた攻撃の多くは、最終的に ZnDoor（RAT: Remote Access Trojan） の設置を目的としています。
ZnDoor の挙動と特徴#
- 侵害の足がかり: RSCの脆弱性を突き、
wgetやcurlを介して ZnDoor 本体をダウンロード・実行します。 - ステルス性: Linuxのデーモンプロセスやシステムサービスに擬態し、ファイルタイムスタンプの偽装（タイムスタンピング）を行って検知を逃れます。
- 機能:
- 対話型リバースシェルの提供
- 任意ファイルのアップロード・ダウンロード
- SOCKS5プロキシの構築（社内ネットワークへの横展開の拠点化）
調査に役立つ IoC (Indicators of Compromise)#
もし侵害が疑われる場合は、以下の痕跡を確認してください。
- 不審なプロセス:
/tmpや/dev/shm以下で実行されている、一見システム標準に見える名称のプロセス。 - ログの異常:
POST /や特定の Server Action エンドポイントに対して、異常に長い、またはバイナリが含まれる Flight レスポンスヘッダーを持つリクエスト。 - 外部通信: 既知のC2（コマンド＆コントロール）サーバーへの不審な HTTPS 通信。
3. 影響範囲と修正済みバージョン#
以下のパッケージおよび、これらを内部で利用しているフレームワーク（Next.js, React Router等）が対象です。
| パッケージ名 | 脆弱なバージョン | 修正済みバージョン |
|---|---|---|
react-server-dom-webpack | 19.0.0, 19.1.0, 19.1.1, 19.2.0 | 19.0.1, 19.1.2, 19.2.1 |
react-server-dom-parcel | 19.0.0, 19.1.0, 19.1.1, 19.2.0 | 19.0.1, 19.1.2, 19.2.1 |
react-server-dom-turbopack | 19.0.0, 19.1.0, 19.1.1, 19.2.0 | 19.0.1, 19.1.2, 19.2.1 |
Next.js ユーザーへの注意:
Next.js 15 系統を利用している場合、内部で上記のパッケージに依存しています。npm updateを実行し、package-lock.json内の React 関連パッケージが上記修正済みバージョンになっていることを必ず確認してください。
4. 対策ロードマップ#
ステップ1：パッケージの即時更新（最優先）#
依存関係をスキャンし、直ちにパッチを適用してください。
npm install next@latest react@latest react-dom@latestステップ2：WAFによる一時的な保護#
パッチ適用までの間、WAF（Cloudflare, AWS WAF, Google Cloud Armor等）で以下のリクエストを制限することを検討してください。
x-middleware-subrequestヘッダーを悪用した Middleware 迂回試行のブロック。- 特殊な RSC ペイロード（
__RSCパラメータ等）を含む異常に大きなリクエストの検知。
ステップ3：多層防御の再構築#
今回の脆弱性の教訓は、**「フレームワークの防御（Middleware等）だけに依存してはいけない」**ということです。
- 認可の二重化: Middlewareでのチェックに加え、Server Action 内でも必ずユーザー権限を再検証する。
- 入力値の厳格な検証: Zod などのスキーマ検証ライブラリを用い、RSCに渡されるデータが期待通りの構造であるかをチェックする。
まとめ：便利さと引き換えの「信頼境界」の消失#
RSCは、フロントエンドとバックエンドの境界をシームレスにする素晴らしい技術ですが、それは同時に 「クライアントからの入力が直接サーバーのレンダリングエンジンに届く」 という大きなリスクを孕んでいます。
「フレームワークがよしなにしてくれる」という前提を捨て、データが境界を超える瞬間（シリアライズ/デシリアライズ）に何が起きているのかを理解することが、これからのエンジニアには不可欠です。
