Reactの致命的脆弱性、React2Shellとは？ - CVSS 10.0のヤバすぎる穴を解説

Posted at 2025-12-13

ねらい

React Server Components（RSC）に発見された最大深刻度の脆弱性「React2Shell」について、技術的な仕組みから対策まで徹底解説

対象

Reactを使ったWebアプリ開発者、Next.js利用者、インフラエンジニア、セキュリティ担当者

ゴール

React2Shellの危険性を理解し、自分のプロジェクトが影響を受けるかどうか判断できるようになる

TL;DR

今すぐパッチを当てろ。デフォルト設定のNext.jsアプリは全部やられる。

はじめに - 2025年12月3日、Web開発界に激震が走った

「Log4Shell以来の最悪の脆弱性かもしれない」

そんな言葉がセキュリティ界隈を駆け巡った。2025年12月3日、Reactチームが公開した脆弱性「CVE-2025-55182」、通称「React2Shell」。CVSS（共通脆弱性評価システム）のスコアは10.0。これは最大値だ。つまり「これ以上ヤバい脆弱性は定義上存在しない」ということを意味している。

発見者のLachlan Davidson氏が11月29日にMetaのバグバウンティプログラムに報告してから、わずか4日でパッチがリリースされた。しかし、公開から数時間後には中国系の脅威アクターによる悪用が確認されている。

React使ってる人、これ他人事じゃないぞ。

React2Shellとは何か

公式による説明

まずはReact公式ブログからの引用を見てほしい。

There is an unauthenticated remote code execution vulnerability in React Server Components.

We recommend upgrading immediately.

On November 29th, Lachlan Davidson reported a security vulnerability in React that allows unauthenticated remote code execution by exploiting a flaw in how React decodes payloads sent to React Server Function endpoints.

出典: React公式ブログ

日本語にするとこうだ：

「React Server Componentsに、認証なしでリモートコード実行が可能な脆弱性が存在します。直ちにアップグレードすることを推奨します。11月29日、Lachlan Davidsonがセキュリティ脆弱性を報告しました。これは、ReactがReact Server Functionエンドポイントに送信されるペイロードをデコードする方法の欠陥を悪用することで、認証なしでリモートコード実行を可能にするものです。」

つまり、ログインすら不要で、悪意のあるリクエスト1発でサーバーを乗っ取れるという話だ。

なぜ「React2Shell」と呼ばれるのか

2021年に世界を震撼させた「Log4Shell（CVE-2021-44228）」を覚えているだろうか。Javaのロギングライブラリ「Log4j」に見つかった脆弱性で、これもCVSS 10.0だった。

今回の脆弱性は、Reactという超メジャーなフレームワークに見つかったこと、そして同じくリモートコード実行（RCE）を可能にすることから、「React2Shell」と名付けられた。「2」は「to」の語呂合わせ。ShellはUnixのシェル、つまりサーバーのコマンド実行環境を奪えるという意味だ。

技術的な仕組み - 何が問題なのか

React Server Components（RSC）とFlightプロトコル

React 19で本格的に導入されたReact Server Components（RSC）は、Reactコンポーネントの一部をサーバー側でレンダリングする仕組みだ。クライアントに送るJavaScriptを減らしてパフォーマンスを向上させる、という触れ込みで登場した。

このRSCがクライアントとサーバー間でデータをやりとりするのに使っているのが「Flight」プロトコル。コンポーネントツリーをシリアライズ（直列化）してHTTPで送受信する。

で、問題はここからだ。

安全でないデシリアライゼーション

Wizのセキュリティブログによると：

The vulnerability fundamentally resides in the react-server package and its handling of the RSC "Flight" protocol. It is characterized as a logical deserialization vulnerability where the server processes RSC payloads in an unsafe manner.

出典: Wiz Blog

日本語訳：「この脆弱性は根本的にreact-serverパッケージとRSC Flightプロトコルの処理に存在する。これはサーバーがRSCペイロードを安全でない方法で処理する、論理的なデシリアライゼーション脆弱性として特徴付けられる。」

もう少し噛み砕いて説明しよう。

サーバーがクライアントから受け取ったFlightペイロードをデシリアライズ（オブジェクトに復元）するとき、その中身をちゃんと検証していなかった。だから攻撃者は「見た目は普通のFlightペイロードだけど、中身に悪意のあるコードが仕込まれているもの」を送りつけることで、サーバー側で任意のコードを実行できてしまう。

具体的な攻撃の流れ

OffSecの技術分析によると：

The attacker submits a Flight payload containing a crafted object that looks like a Chunk. The fake Chunk defines a custom then method. When React deserializes the payload, its internal machinery attempts to resolve the Chunk as a promise. Promise resolution causes React to call the attacker-controlled then method.

出典: OffSec Blog

日本語訳：「攻撃者はChunkのように見える細工されたオブジェクトを含むFlightペイロードを送信する。偽のChunkはカスタムのthenメソッドを定義している。ReactがペイロードをデシリアライズするとReactの内部機構はChunkをPromiseとして解決しようとする。Promise解決により、Reactは攻撃者が制御するthenメソッドを呼び出すことになる。」

JavaScriptのPromiseを知っている人なら「なるほど」と思うはずだ。Promiseは「後で値を返すよ」という約束のオブジェクトで、.then()メソッドで結果を受け取る。攻撃者はこの仕組みを悪用して、自分が定義したthenメソッドをReactに実行させることで、サーバー内部の制御を奪っている。

これは「プロトタイプポリューション」と呼ばれるJavaScript特有の攻撃手法の変形版とも言える。

なぜこれほど危険なのか

JFrogのセキュリティブログは3つのポイントを挙げている：

1. デフォルト設定で脆弱

A standard project generated with "create-next-app" is immediately exposed, even if the developer hasn't written a single line of custom code.

出典: JFrog Blog

日本語訳：「create-next-appで生成された標準的なプロジェクトは、開発者がカスタムコードを1行も書いていなくても、即座に露出状態になる。」

npx create-next-appを実行して何もせずデプロイしただけで脆弱。これはヤバい。

2. 認証不要

The malicious payload targets the React Flight protocol which is processed before the application's custom authentication logic is executed.

日本語訳：「悪意のあるペイロードはReact Flightプロトコルを標的とし、これはアプリケーションのカスタム認証ロジックが実行される前に処理される。」

つまり、どんな堅牢な認証システムを実装していても関係ない。Flightプロトコルの処理は認証より先に実行されるから、認証をバイパスしてしまう。

3. 成功率ほぼ100%

Exploitability is near-100% against vulnerable systems, making the exploit a "set-it-and-forget-it" attack vector for threat actors.

日本語訳：「脆弱なシステムに対する悪用の成功率はほぼ100%で、脅威アクターにとって『設定したら放置』タイプの攻撃ベクトルとなる。」

攻撃者にとって夢のような脆弱性だ。

影響を受けるバージョンと環境

脆弱なパッケージ

React公式によると、以下のバージョンが影響を受ける：

Reactパッケージ（バージョン 19.0, 19.1.0, 19.1.1, 19.2.0）

react-server-dom-webpack / react-server-dom-parcel / react-server-dom-turbopack

これらのパッケージを直接使っていなくても、フレームワーク経由で使っている可能性がある。

影響を受けるフレームワーク

Next.js / React Router / Waku / @parcel/rsc / @vitejs/plugin-rsc / rwsdk（Redwood SDK）

特にNext.jsはReactをバンドルして配布しているため、通常の依存関係チェックでは検出されにくいという罠がある。

Lachlan Davidson氏の公式サイトによると：

Next.js does not include React as a traditional dependency - instead, they bundle it "vendored". So, if you're using Next.js, many dependency tools do not automatically recognise it as vulnerable.

出典: react2shell.com

日本語訳：「Next.jsはReactを従来の依存関係として含んでいない - 代わりにベンダー化してバンドルしている。そのため、Next.jsを使っている場合、多くの依存関係ツールは自動的に脆弱性を認識しない。」

npm auditやyarn auditでは検出されない可能性があるということだ。

どのくらいの環境が影響を受けるのか

Wizの調査データはかなり衝撃的だ：

Wiz data indicates that 39% of cloud environments contain instances of Next.js or React in versions vulnerable to CVE-2025-55182.

日本語訳：「Wizのデータによると、クラウド環境の39%がCVE-2025-55182に脆弱なバージョンのNext.jsまたはReactのインスタンスを含んでいる。」

クラウド環境の約4割が影響を受ける。そしてState of JavaScript 2024によれば、Reactは開発者の82%が使用している。影響範囲は計り知れない。

実際の攻撃事例

公開直後から始まった攻撃

AWSのセキュリティブログは衝撃的な事実を報告している：

Within hours of the public disclosure of CVE-2025-55182 (React2Shell) on December 3, 2025, Amazon threat intelligence teams observed active exploitation attempts by multiple China state-nexus threat groups, including Earth Lamia and Jackpot Panda.

出典: AWS Security Blog

日本語訳：「2025年12月3日のCVE-2025-55182（React2Shell）の公開から数時間以内に、Amazonの脅威インテリジェンスチームは、Earth LamiaやJackpot Pandaを含む複数の中国系脅威グループによる積極的な悪用試みを観測した。」

公開から数時間で国家レベルの攻撃者が動き出している。パッチを当てるまでの猶予は文字通りゼロだ。

観測された攻撃パターン

Palo Alto Networks Unit 42の報告によると、攻撃者たちは以下のような行動を取っている：

Unit 42 observed a threat actor leveraging a bash reverse shell to connect to a probable Cobalt Strike server.

出典: Unit 42

日本語訳：「Unit 42は、脅威アクターがbashリバースシェルを使用してCobalt Strikeサーバーと思われるものに接続しているのを観測した。」

Cobalt Strikeは本来はペネトレーションテスト用のツールだが、今や攻撃者御用達の「後期侵入フレームワーク」として悪名高い。

また、Huntressの報告では「PeerBlight」と名付けられたLinuxバックドアの展開も確認されている。攻撃者はまず脆弱性を突いて侵入し、その後マルウェアを仕込んで永続的なアクセスを確保するという流れだ。

攻撃後に何が起きるか

Qualysのブログは、侵入後の行動パターンを詳細に分析している：

Environment and identity discovery: executing commands like whoami, hostname, environment variable dumps, and browsing /etc/passwd to profile the host and execution context.

出典: Qualys Blog

日本語訳：「環境とアイデンティティの発見：whoami、hostname、環境変数のダンプ、/etc/passwdの閲覧などのコマンドを実行して、ホストと実行コンテキストをプロファイリング。」

要するに、まず「どこに侵入したか」を調べて、次の攻撃に備えている。環境変数にはAWSのアクセスキーやデータベースの接続情報が入っていることが多いから、これが漏れるとクラウド全体が危険にさらされる。

今すぐやるべき対策

パッチ適用

これが唯一かつ最優先の対策だ。

Reactパッケージ

修正版は 19.0.1、19.1.2、19.2.1 でリリースされている。

npm install react@latest react-dom@latest react-server-dom-webpack@latest

Next.js

使用中のバージョンラインに応じた修正版にアップデートする。

# 14.x系の場合
npm install next@14.2.35

# 15.0.x系の場合
npm install next@15.0.7

# 15.1.x系の場合
npm install next@15.1.11

# 15.2.x系の場合
npm install next@15.2.8

# 15.3.x系の場合
npm install next@15.3.8

# 15.4.x系の場合
npm install next@15.4.10

# 15.5.x系の場合
npm install next@15.5.9

# 16.0.x系の場合
npm install next@16.0.10

Vercelが提供している対話型ツールも使える：

npx fix-react2shell-next

自分が影響を受けるかどうかの確認

以下に該当する場合は影響を受ける：

React 19.x系を使用している
Next.js 15.x / 16.x でApp Routerを使用している
React Router、Waku、その他RSC対応フレームワークを使用している

重要な落とし穴

React公式は次のように警告している：

Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components.

日本語訳：「アプリがReact Server Functionエンドポイントを実装していなくても、アプリがReact Server Componentsをサポートしている場合は脆弱である可能性がある。」

「うちはServer Functionsを使ってないから大丈夫」という判断は危険だ。RSCをサポートしている時点でリスクがある。

WAFでの一時的な緩和策

すぐにパッチを当てられない場合、WAF（Web Application Firewall）による防御が一時的な緩和策になる。

AWS WAFを使っている場合：

The default version (1.24 or higher) of the AWS WAF AWSManagedRulesKnownBadInputsRuleSet now includes updated rules for CVE-2025-55182.

日本語訳：「AWS WAF AWSManagedRulesKnownBadInputsRuleSetのデフォルトバージョン（1.24以上）には、CVE-2025-55182用の更新されたルールが含まれるようになった。」

CloudflareもWAFルールを更新して無料プランでも保護を提供している。

ただし、WAFはあくまで一時しのぎだ。根本的な解決はパッチ適用しかない。

やってはいけないこと

「うちはReact 18だから関係ない」と安心する

確かにReact 18は直接の影響を受けない。しかし、Next.jsなど一部のフレームワークでは内部的にReact 19の機能を使っている場合がある。バージョン番号だけで判断せず、実際に使っているパッケージを確認すべきだ。

npm auditだけで安心する

前述の通り、Next.jsはReactをvendor化してバンドルしているため、通常の依存関係スキャンでは検出されないことがある。

「開発環境だから」と放置する

開発環境でもインターネットに公開されていれば攻撃対象になる。特にVercelやNetlifyなどのプレビューデプロイは、本番と同じくらいのリスクがある。

時系列まとめ

2025年11月29日 - Lachlan DavidsonがMeta Bug Bountyに報告
2025年11月30日 - Metaのセキュリティ研究者が確認、修正作業開始
2025年12月1日 - 修正完了、ホスティングプロバイダーとの調整開始
2025年12月3日 - パッチ公開、CVE-2025-55182として公開、同日数時間後に攻撃開始
2025年12月4日 - 公開PoCが出回り始める
2025年12月5日 - 大規模な自動化攻撃が観測される
2025年12月11日 - 追加の脆弱性（CVE-2025-55183、CVE-2025-55184、CVE-2025-67779）が公開