メインコンテンツまでスキップ

【メモ】React2Shellはアプリ検証ロジック前に作用する

目的​

React2Shell（CVE-2025-55182）は、「アプリの入力検証ロジックを頑張っていても、その前段で踏まれ得る」タイプの脆弱性です。12

本記事では、なぜ“入力検証より前”に実行され得るのかを、Webサーバの基本構造（リクエスト処理の順序）から初学者向けに整理します。攻撃手順やペイロードの具体には触れません。3

0. まずWebサーバの基本構造（ざっくり）​

Webアプリの「入力検証」が効く前提は、リクエストが“アプリのコード（コントローラ等）”まで到達して、そこで検証が走ることです。

典型的な流れは次の通りです。

  1. クライアント（ブラウザ等）がHTTPリクエストを送る
  2. Webサーバ / アプリサーバが受け取る（例：Nginx、Node.js、Java）
  3. フレームワークの前処理が走る（ルーティング、ボディのパース、認証ミドルウェア、CSRF、デコード等）
  4. その後にアプリ固有の処理（入力検証、ビジネスロジック、DBアクセス）

重要なのは、3) の“フレームワーク前処理”は、アプリの入力検証より前に必ず走るという点です。

「どこで何が守られるか」を表で把握する​

位置づけ例主担当ここで効きやすい対策ここが壊れると何が起きるか
HTTP受信〜ルーティングパスでハンドラ決定Webサーバ/フレームワーク経路制御、WAF、ACL想定外の入口へ到達
ボディのパース/デコードJSON/フォーム/独自形式の復元フレームワーク形式検査、サイズ制限検証前に例外/脆弱性が発火
認証/認可ミドルウェアログイン必須化アプリ/フレームワーク認証、認可“pre-auth”になる余地
入力検証（アプリ）文字種/長さ/スキーマアプリバリデーションただし前段が安全であることが前提

React2Shellは、この表でいう 「ボディのパース/デコード（復元）」が先に走る領域に論点がある、という理解が近道です。45

1. React Server Components（RSC）で何が増えるのか​

RSCを使うと、従来の「HTML/JSON APIを返す」だけでなく、RSC専用の通信（Flight）を処理するサーバ側ロジックが増えます。16

イメージ：

  • 従来

    • /api/login → JSON
    • /page → HTML

  • RSCあり

    • /api/login → JSON
    • /page → HTML
    • （追加）RSC/Flight用の通信（POST等） → RSCのデータ形式をやりとり（フレームワーク内部で処理）

この「追加された入口（＝フレームワークが受け持つ処理）」が、今回の主役です。1

2. 「入力検証が効く場所」と「効かない場所」​

入力検証は通常、アプリが“意識して作った入口”で書きます。

  • フォーム入力の型チェック、文字数、文字種、正規表現
  • JSONスキーマ検証
  • 業務ルール検証

これは「アプリが想定した入力」を「アプリが想定した入口」で受け取ることが前提です。

一方でRSC/Flightは、開発者が直接触らないことも多い **フレームワーク内部の“特殊な入口”です。ここで内部的に受け取ったデータを復元（デシリアライズ）**して、コンポーネントやサーバ機能の呼び出しに変換します。12

3. React2Shellのポイント​

React2Shell（CVE-2025-55182）は、信頼できないデータ（Flight等のペイロード）をフレームワークが先にデシリアライズしてしまうことが核で、その過程が危険だと **任意コード実行（RCE）**につながり得る、というタイプです。42

IPAも論点を「信頼できないデータのデシリアライズ」として整理し、悪用されると任意コード実行のおそれがあると注意喚起しています。4

4. では「なぜ入力検証ロジック前」なのか（処理順で理解）​

処理順を「どこで何が起きるか」に分解します。

A) 通常のAPI（入力検証が効く典型）​

[HTTP受信] → [ルーティング] → [認証/認可] → [JSONパース] → [アプリの入力検証] → [ビジネスロジック] → [レスポンス]

この経路では、「JSONパースの後」にアプリ検証が入ることが多く、入力検証が守りとして機能しやすいです。

B) RSC/Flight（React2Shellの論点側）​

[HTTP受信] → [RSC/Flightとしてルーティング] → [Flightペイロードのパース] → [モデルの復元（デシリアライズ）] ★ここが危ない → （脆弱だと、アプリ検証に到達する前にRCEへ） → [その後にアプリ側の処理へ到達する場合もある]

つまり危ないのは、**「入力検証の前にある、フレームワーク内部のパース/復元処理」**です。ここが脆弱だと、アプリがその後段でどれだけ厳密に検証しても、手前で事故が起き得ます。21

5. 「アプリがServer Functionを実装してなくても危ない」理由​

React公式は、アプリが明示的にServer Functionのエンドポイントを実装していなくても、RSCをサポートしているだけで影響し得ると注意しています。1

理由はシンプルで、RSCを有効にした時点で **フレームワークがFlight受信→復元（デシリアライズ）**を担当するためです。
その内部に脆弱性があれば、アプリの検証コードとは独立に踏まれ得ます。17

6. “事前認証（pre-auth）”になり得る理由​

JPCERT/CCは、細工したHTTPリクエスト（不正なFlightペイロード等）により、認証不要でコード実行につながる可能性があると説明しています。3

「pre-auth」になり得る構造は、次のどちらか（あるいは両方）が起きる時です。

  • 認証ミドルウェアに到達する前に、フレームワークの復元処理が動く
  • 認証を要求しない経路（設定・実装都合）で、Flight処理が動く

NVDも「pre-auth RCE」であり、Server Function向けリクエストのデシリアライズが問題と説明しています。2

7. 影響範囲の要点​

React側（RSC関連パッケージ）​

React公式とGitHub Advisoryは、影響を受けるRSC関連パッケージとバージョン、および修正版を明記しています。17

コンポーネント影響バージョン修正版（例）
react-server-dom-webpack19.0 / 19.1.0 / 19.1.1 / 19.2.019.0.1 / 19.1.2 / 19.2.1
react-server-dom-parcel同上同上
react-server-dom-turbopack同上同上

※「修正版へアップデート」が第一優先、というのが公式の立場です。1

Next.js側（下流への影響）​

Next.jsは、上流（React）の問題としてCVE-2025-55182を参照しつつ、App Router利用時の影響と修正版を提示しています。8

対象影響条件（概略）影響が小さい/ない例（概略）
Next.jsApp Router + RSCを利用する構成Pages Router、Edge Runtime などは影響外と説明

（※詳細な対象バージョン・修正版はNext.jsのアドバイザリに従ってください）8

8. まとめ​

  • 入力検証は強いが、それが動くのは通常「アプリの入口」の後段
  • RSCは、フレームワーク内部に「追加の入口（Flight処理）」を持つ
  • React2Shellは、その入口で「信頼できないデータのデシリアライズ」が先に走り、RCEにつながり得る
  • だから、アプリの検証ロジックの前に発火し得る

このため対策の基本は、

  1. 修正版へ迅速にアップデート（最優先）
  2. 短期的な緩和として WAF等で当該経路・特徴のあるリクエストを抑止（ただし根本解決ではない）
    という順序になります。143

補足（安全側の理解）​

本記事は仕組み理解を目的に、攻撃手順や具体ペイロードには触れていません。
実務では、まず **影響判定（RSC利用有無、該当パッケージとバージョン確認）**を行い、パッチ適用を最優先に置くのが安全です。14

参考資料（出典）​

Footnotes​

  1. React, Critical Security Vulnerability in React Server Components（2025-12-03 / 更新: 2026-01-26）。影響パッケージ、影響バージョン、修正版、さらに「Server Functionを実装していなくてもRSC対応なら影響し得る」点を明記。https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11

  2. NIST NVD, CVE-2025-55182 Detail（2025-12-03 受領）。pre-auth RCEであり、HTTPリクエスト由来ペイロードの「unsafe deserialization」が問題と説明。https://nvd.nist.gov/vuln/detail/CVE-2025-55182 ↩ ↩2 ↩3 ↩4 ↩5

  3. JPCERT/CC, React Server Componentsの脆弱性（CVE-2025-55182）について（最終更新: 2026-01-07）。細工したHTTPリクエスト（不正Flightペイロード）により認証不要RCEの可能性がある旨を説明。https://www.jpcert.or.jp/newsflash/2025120501.html ↩ ↩2 ↩3

  4. IPA, React Server Componentsにおける脆弱性について（CVE-2025-55182）（公開: 2025-12-09 / 最終更新: 2025-12-12）。「信頼できないデータのデシリアライズ」が論点で、任意コード実行のおそれがあると注意喚起。https://www.ipa.go.jp/security/security-alert/2025/alert20251209.html ↩ ↩2 ↩3 ↩4 ↩5

  5. MITRE, CWE-502: Deserialization of Untrusted Data。デシリアライズの概念と、信頼できないデータを復元することの一般的リスクを定義。https://cwe.mitre.org/data/definitions/502.html ↩

  6. Vercel, React2Shell Security Bulletin（最終更新: 2025-12-26）。React/Next.js等への影響と対応の要点をまとめたセキュリティブリーフ。https://vercel.com/kb/bulletin/react2shell ↩

  7. GitHub Advisory Database / React, React Server Components are Vulnerable to RCE (GHSA-fv66-9v8q-g76r)（2025-12-03）。影響パッケージと影響バージョンを明記し、即時アップグレードを推奨。https://github.com/advisories/GHSA-fv66-9v8q-g76r ↩ ↩2

  8. Next.js, Security Advisory: CVE-2025-66478（2025-12-03）。上流CVE-2025-55182に起因する下流影響を整理し、影響条件（App Router等）と修正版を提示。https://nextjs.org/blog/CVE-2025-66478 ↩ ↩2

に最終更新