React2Shellに学ぶReact Flightプロトコルの脆弱性と防御策

React2Shellに学ぶReact Flightプロトコルの脆弱性と防御策

WordPressをヘッドレスCMSとしてReactやNext.jsでフロントエンドを構築するプロジェクトが増えている。その中核となるReact Server Components（RSC）では、サーバーとクライアントの通信にFlightと呼ばれる独自のストリーミングプロトコルが使われる。しかし2025年12月、このFlightプロトコルにCVSS 10.0のリモートコード実行の脆弱性（CVE-2025-55182、通称React2Shell）が発見され、大きな話題となった。

本記事では、Flightプロトコルの仕組みと、なぜこれほど深刻な攻撃が可能になるのかを解説する。さらに、React2Shellの詳細な攻撃手法と、WordPressのヘッドレス構成でもすぐに実践できる防御策をランキング形式で紹介する。

Flightプロトコルとは何か（仕組みと危険性）

React Server Componentsがブラウザに送るのはHTMLでもJSONでもない。サーバーコンポーネントがレンダリングされると、text/x-componentというContent-Typeで行区切りのテキストストリームが流れる。このフォーマットをFlightと呼ぶ。各行は「行ID:タグ+ペイロード」の形式で、Reactランタイムがストリームを読みながらクライアント側のUIを再構築する。

例えば、次のような単純なペイロードを見てほしい。行1はIタグでクライアントコンポーネントの読み込みを指示し、行2はJタグで仮想DOMを組み立てる。行0のDはサーバー側の実行コンテキストだ。これだけでも複数の役割と参照が絡み合っていることがわかる。

Flightプロトコルは、単なるJSON形式ではない。$接頭辞によってクライアントサイドで実行するコードやモジュール読み込み、サーバーアクションのRPC呼び出しを再構成する。この仕組みが強力であるほど、入力が攻撃者に操作された場合の危険性も増す。

具体的には、$Fは呼び出し可能なサーバー関数を表し、$Lは遅延読み込みコンポーネント、$@は内部的なPromiseラッパーへの参照を返す。中でも$:は$1:user:nameのようにコロン区切りでオブジェクトのプロパティをたどる機能で、もしパスに__proto__やconstructorが含まれるとプロトタイプチェーンを遡ることになる。これが設計上の重大な問題の始まりだ。

React2Shell（CVE-2025-55182）の攻撃メカニズム

2025年12月に公表されたCVE-2025-55182は、Flightのデシリアライゼーション処理に潜むCVSS 10.0のリモートコード実行の脆弱性だ。認証不要の1回のHTTPリクエストでサーバーにシェルアクセスを許す。CISAは直ちに「悪用が確認された脆弱性カタログ」に追加し、北朝鮮の国家支援ハッカーが数時間以内に攻撃を開始したとSysdigが報告している。

根本原因はgetOutlinedModel関数にある。この関数は$1:user:nameのような参照を解決する際、コロンでパスを分割し、単純にparentObject[segment]でプロパティアクセスを繰り返す。hasOwnPropertyによるチェックは一切なかった。

このガジェットチェーンは、Flightの持つ機能を悪用し、1回のHTTPリクエストでサーバーを乗っ取る。ログインも認証も不要だ。最終的に攻撃者はNode.jsプロセスの権限で任意のコマンドを実行できる。

SYSDIGの調査では、この脆弱性を利用した「EtherRAT」と呼ばれるファイルレス型インプラントが、イーサリアムブロックチェーンをC2通信に使う「EtherHiding」手法で展開され、テイクダウンが極めて困難だった。またPalo AltoのUnit 42は、感染Linuxシステムで正規のカーネルスワップデーモン（kswapd0）に偽装するバックドア「KSwapDoor」を確認している。

修正パッチの内容と限界

Reactチームはモジュールロード時にObject.prototype.hasOwnPropertyをキャッシュし、以後すべてのプロパティチェックでこれを使うパッチを適用した。これにより、攻撃者が__proto__を経由する試みはブロックされる。修正はReact 19.0.1、19.1.2、19.2.1に含まれており、既知のガジェットチェーンを完全に無効化する。

しかし、パッチはプロパティ探索のモデルそのものは維持している。$:プレフィックスは依然としてコロン区切りのパスを走査し、所有権を検証するようになっただけだ。設計上の根本問題は残っており、今後の新たなバイパスがこの領域から出てくる可能性は否定できない。Smashing Magazineの筆者も「プロパティ探索をネットワークプロトコルに露出させたこと自体が設計ミスだ」と指摘している。

実践的な防御策（影響度順ランキング）

Reactのパッチに頼るだけでなく、アプリケーションレベルで複数層の対策を取ることが肝心だ。以下は、実際の攻撃を防ぐ効果が高い順に並べた防御策である。

1. Server Actionの厳格な入力バリデーション（Zod、Valibot）

最も即効性があるのは、すべてのサーバーアクションの先頭でスキーマバリデーションを行うことだ。Flightデシリアライザはアプリケーションロジックより先に生データを処理するため、バリデーションが唯一の事前防御になる。ZodやValibotを使い、型、文字列長、数値範囲、列挙値を厳密にチェックする。

特に注意すべきは、引数を分割代入する前にバリデーションを済ませることだ。分割代入の時点で未検証のオブジェクトにアクセスしているため、まさにその操作が悪用される可能性がある。またエラーハンドリングでは.safeParse()を使い、内部情報が漏れないようにする。

2. server-only パッケージ

データベース接続やAPIキーを含むファイルの先頭にimport "server-only"を入れるだけで、クライアントコンポーネントへのトランスパイル時エラーを発生させる。バレルファイル（複数のエクスポートをまとめるindex.ts）による意図しないエクスポートには細心の注意が必要だが、コードの境界を強制するシンプルで強力な手段だ。

3. CSRF対策の強化

Next.js 16.1.7で修正される前に発見されたCVE-2026-27978は、サンドボックス化されたiframeから送られるOrigin: nullをNext.jsがクロスオリジンとみなさないバグだった。対策として、セッションクッキーにSameSite=Strictを設定し、重要な操作には独自のCSRFトークンを実装する。またexperimental.serverActions.allowedOriginsに'null'を絶対に追加しないこと。これだけでCSRFバイパスを再び開放してしまう。

4. パッチ適用バージョンの維持

React2ShellのRCE修正は19.0.1、19.1.2、19.2.1で行われたが、それ以降にDoSの脆弱性（CVE-2025-55184、CVE-2025-67779、CVE-2026-23864）も複数回修正されている。最新のセキュリティリリース（19.0.4以上、19.1.5以上、19.2.4以上）に追随することが不可欠だ。

5. Taint API（実験的）

experimental_taintObjectReferenceやtaintUniqueValueは、オブジェクトや文字列が誤ってクライアントにシリアライズされるのを防ぐ。しかしこれはオブジェクト参照を追跡する仕組みであり、スプレッド構文や個別プロパティの受け渡しで追跡が途切れる。あくまで開発時のフェイルセーフとして捉え、セキュリティ境界にはしない方がよい。

6. WAF（Web Application Firewall）

WAFはNext-Actionヘッダー付きのPOSTリクエストを検査し、__proto__やconstructor:constructorを含むペイロードをブロックするルールを追加できる。しかし、攻撃者が検査バッファを超えるパディングを前につけることで簡単にすり抜けられるため、あくまでノイズ低減層と割り切るべきだ。

React2Shell以降の脆弱性と今後の課題

React2Shellの修正後も、Flightのデシリアライゼーション面では複数のCVEが報告されている。特に、入れ子になったPromiseによる無限再帰（CVE-2025-55184）とその不完全な修正（CVE-2025-67779）、zipbomb的なメモリ枯渇を起こすDoS（CVE-2026-23864）は、デシリアライザーのパッチがいかに難しいかを示している。また、サーバー関数が引数を文字列化するだけでソースコードが流出するCVE-2025-55183は、デバッグ用途のJSON.stringifyが裏目に出る好例だ。

さらに、パッチでは塞がれていない構造的なリスクも残る。Flightストリームは平文で、CDN改ざんやキャッシュポイズニングによる中間者攻撃を受けやすい。攻撃者が行単位で$Iや$Fを書き換えれば、任意のモジュールをロードさせたり、隠しRPCエンドポイントを埋め込んだりできる。また、server-reference-manifest.jsonが公開されていると、すべてのサーバーアクションIDが漏洩し、IDOR攻撃に直結する。暗号化されたクロージャ引数を複製するために静的キーが使われている場合も、ファイル読み取り権限さえ奪取できれば改ざん可能だ。

根本的には、ネットワーク越しにプロパティ探索や実行可能な参照を再構成させる設計が、今後も攻撃者に利用される可能性をはらんでいる。Reactチームは既知のガジェットを塞いだが、これまでの歴史が示すように、シリアライゼーションフレームワークの脆弱性は根絶が難しい。

この記事のポイント

• React FlightプロトコルはJSONの延長ではなく、$接頭辞でクライアント側の実行可能コードやモジュール読み込みを指示する「振る舞いのシリアライゼーション」である。
• CVSS 10.0のReact2Shellは、プロトタイプ汚染とChunkオブジェクト操作を組み合わせ、認証なしでRCEを達成した。
• パッチはhasOwnPropertyチェックを追加したが、プロパティ探索の根本設計は変わっておらず、新たな攻撃が生まれる余地がある。
• 実務では、Server Actionの先頭で必ずスキーマバリデーションを実施し、server-onlyでコード境界を強制し、CSRF対策を二重化することが最も効果的な防御となる。
• Taint APIやWAFは補助的な防御に過ぎず、過信せずに多層防御を組み立てる必要がある。

海田 洋祐

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験