1. 概要

2025年12月、ReactおよびそのフレームワークであるNext.jsにおいて、極めて深刻な脆弱性が報告されました。通称「React2Shell」と呼ばれるこの脆弱性 CVE-2025-55182（注意1）は、攻撃者がリモートからサーバー上で任意のコードを実行可能にする（RCE）ものであり、CVSS基本値は最大値の10.0と評価されています。

米国CISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）による「既知の悪用された脆弱性カタログ（KEV）」への追加や、IPA、JPCERT/CCからの注意喚起が示す通り、組織的な対応が急務となっています。

本記事では、React2Shellがなぜ従来の脆弱性管理プロセスで見落とされやすいのか、その技術的要因とビジネスリスクを整理します。また、アプリケーションライブラリに起因するサプライチェーンリスクに対し、脆弱性管理サービス「FutureVuls」を用いてどのように検知・優先順位付けを行うべきか、具体的な運用手法を提示します。

• 注意1: CVE-2025-55182（React）および CVE-2025-66478（Next.js）のうち、Next.js側の CVE-2025-66478 は REJECTED となり、React側に統合して管理される場合があります。

2. Reactと現代Web開発のパラダイムシフト

React2Shellのリスクを正確に評価するためには、近年のフロントエンド開発におけるアーキテクチャの変化を理解する必要があります。

2.1 Reactとはそもそも何なのか？

React（リアクト）は、Facebook（現Meta）によって開発され、現在では世界中のWeb開発現場で標準的に利用されているJavaScriptライブラリです。

概念的理解：Webサイト構築の「レゴブロック化」

初期のWebサイト開発（HTML/CSSを直接記述する手法）を「粘土細工」に例えるならば、Reactによる開発は「レゴブロック」を用いた構築に例えられます。

• 従来の手法（粘土細工）： ページ全体を一つの大きな塊として作り込みます。デザインを変更したり、機能を修正したりする場合、全体に影響が及ばないよう慎重に作業する必要があり、大規模な修正は困難を伴いました。
• Reactの手法（レゴブロック）： 画面を構成する要素を「ボタン」「検索バー」「商品カード」といった独立した小さな部品（コンポーネント）として作成します。これらの部品を組み合わせることでページを構築します。一度作った「検索バー」という部品は、他のページでも再利用でき、修正が必要な場合はその部品だけを直せば、使われている全てのページに反映されます。

この「コンポーネント指向」と呼ばれるアプローチにより、開発スピードと保守性が劇的に向上しました。その結果、Airbnb、Netflix、Uberといった巨大テック企業から、一般的な企業のコーポレートサイトや社内システムに至るまで、Reactは爆発的に普及しました。このため、現代のWebインフラにおける「基礎部分」を担っていると言っても過言ではありません。

2.2 React Server Components (RSC) の登場とリスクの変化

Reactは当初、ユーザーのブラウザ（クライアントサイド）で動く技術として発展しました。しかし、近年ではパフォーマンス向上を目的として、サーバー側で処理の一部を行う「React Server Components (RSC)」という新しい技術が導入されました。

React2Shellの問題は、この「サーバー側で動くReact」において発生しました。本来、利用者の目に触れる画面を作るための道具であったReactが、サーバー内部の処理にも深く関与するようになった結果、「画面の表示を崩される」だけでは済まない、「サーバーそのものを乗っ取られる」リスクを抱え込むことになりました。

3. ライブラリとフレームワークの依存関係におけるリスク

今回の脆弱性が広範囲に影響を及ぼしている背景には、モダンなWeb開発における「ライブラリ（React）」と「フレームワーク（Next.js）」の密接な関係があります。

3.1 道具箱としての「ライブラリ」

ライブラリ（Library）とは、特定の機能を持ったプログラムの部品集です。React自体は、元々はこのライブラリに分類されます。

• イメージ：プロ用の電動工具セット
  • 主導権： ライブラリ（開発者）
  • 動作： 開発者が「棚を作りたい」と考えたとき、必要なタイミングで道具箱からドリルを取り出して使います。ドリルが勝手に動き出して棚を作り始めることはありません。
  • 利用者の責任： 道具の使い方を間違えなければ、基本的には安全です。制御の主体はあくまで人間（開発者）のコードにあります。

3.2 工場としての「フレームワーク」

フレームワーク（Framework）は、アプリケーション開発の骨組みや土台を提供する、より包括的なシステムです。今回の騒動で中心となっているNext.jsは、Reactをベースにしたフレームワークです。

• イメージ：全自動のプレハブ住宅製造工場
  • 主導権： フレームワーク（工場）
  • 動作： 「制御の反転（Inversion of Control）」と呼ばれる現象が起きます。人間（開発者）は工場のラインの前に立ち、工場（フレームワーク）から「ここに窓をはめ込んでください」と指示されたタイミングで部品を渡します。家全体の設計や製造工程は工場が決めており、開発者はそれに従います。
  • 利用者の責任： ここが最大の問題点です。工場の製造ライン自体（フレームワークの裏側の処理）に欠陥があった場合、開発者がどれだけ注意深く窓をはめ込んでも、欠陥製品（脆弱なアプリ）が出来上がってしまいます。

3.3 なぜReact2Shellは「Next.jsの脆弱性」として語られるのか？

React2Shellの根本原因は、React（ライブラリ）の中にある「React Server Components」という機能の不具合です。しかし、React単体ではこの機能を使うための設定が複雑であり、多くの開発者はReactを直接使うのではなく、関連機能がセットになったNext.js（フレームワーク）を通してこの機能を利用しています。
Next.jsは、標準設定でこの脆弱なReactの機能を有効にしているため、「Next.jsを使っていると危ない」という状況が生まれました。これが、ライブラリの問題がフレームワークを通じて広範囲に影響を及ぼした構造です。

4. React2Shell (CVE-2025-55182) のメカニズムと深刻度

4.1 脆弱性の正体：安全でないデシリアライズ

React2Shellは、専門的には「安全でないデシリアライズ（Insecure Deserialization）」に分類される脆弱性です。

郵便小包のイメージ

Webサーバーと利用者のブラウザの間では、常にデータのやり取りが行われています。これを郵便の配送に例えてみましょう。

1. シリアライズ（梱包）：ブラウザ側で、プログラムのデータを通信回線に乗せるために「文字列」という形式に変換して箱詰めします。
2. 通信（配送）：箱詰めされたデータがインターネットを通じてサーバーに届きます。
3. デシリアライズ（開封・復元）：サーバーは届いた箱を開け、中の文字列を読み取って元のプログラムデータに復元し、処理を実行します。

React2Shellの問題点は、この「開封・復元」のプロセスにおいて、サーバー側の確認係（ReactのFlightプロトコル）が、届いた荷物の中身を無条件に信用して組み立ててしまうことにあります。攻撃者は、一見普通の荷物に見せかけて、攻撃コードを送りつけます。そして、Reactのサーバー機能は、それが悪意あるものかを確認せずに復元（実行）してしまいます。その結果、攻撃者は認証を突破することなく、サーバー内部で任意の命令を実行（Remote Code Execution: RCE）できる状態になります。

• Flightプロトコル: Reactの内部用語。React Server Components (RSC) における内部的なデータ転送フォーマットの呼称。サーバー側でレンダリングされたUI構造（React要素ツリー）やClient Componentsへの参照情報を、テキスト形式にシリアライズしてクライアントへストリーミングするための独自のデータ形式を指す。

4.2 攻撃のメカニズム

より技術的に説明すると、攻撃者はFlightプロトコルのデータ形式を悪用します。Flightプロトコルでは、データの一部が他のデータを参照する（$記号などを使う）複雑な構造を持っています。
攻撃者は、この構造を巧みに操作し、サーバー内部の本来触れてはいけない機能（内部関数やモジュール）を呼び出すような「細工されたデータ（ペイロード）」を作成します。
サーバーがこのデータを読み込むと、意図せず内部のプログラムが連鎖的に反応し（ガジェットチェーン）、最終的に攻撃者が指定したOSのコマンド（例：パスワードファイルを盗む、バックドアを設置する）が実行されてしまうのです。

5. リスク評価：なぜ緊急対応が必要か

React2Shellが「Log4Shellの再来」として警戒される理由は、以下の4点に集約されます。

5.1 理由1: 影響範囲が広い（Ubiquity）

前述の通り、ReactとNext.jsは現代Web開発のデファクトスタンダード（事実上の標準）です。
大企業、スタートアップ、政府機関、個人のブログまで、この脆弱性の影響を受けるReactインスタンスが存在するとされています。インターネット上のあらゆる場所に「穴」が空いた状態です。

5.2 理由2: デフォルト設定で危険（Zero-Config Compromise）

多くの脆弱性は、「特定の設定をオンにしている場合のみ危険」という条件付きのものです。しかし、React2Shell（特にNext.jsを利用している場合）は、標準設定（デフォルト）のまま使っているだけで危険です。
開発者が「create-next-app」というコマンドでプロジェクトを作成し、何も設定を変更せずに公開しただけで、攻撃の対象となります。開発者がセキュリティ設定をミスしたわけではなく、最初から製品に欠陥があったという点が、問題の深刻さを際立たせています。

5.3 理由3: 攻撃の容易さと確実性（Reliability）

この脆弱性を悪用するのは非常に簡単です。認証（ログイン）も必要ありません。攻撃者はインターネット経由で特定のデータを送りつけることで攻撃が成立します。
さらに、攻撃の成功率の高さにも注目されています。複雑な条件が揃うのを待つ必要がなく、攻撃者によっては「投げれば当たる」状態です。すでに攻撃コード（PoC: Proof of Concept）が公開されており、高度な技術を持たない攻撃者（スクリプトキディ）でも容易に悪用可能です。

5.4 理由4: 2021年の悪夢「Log4Shell」の再来

セキュリティ専門家の間では、この状況が2021年に世界を大混乱に陥れた「Log4Shell」という事件に酷似していると指摘されています。Log4Shellも、「広く使われているライブラリ（Log4j）」の「入力データの処理（JNDI Lookup）」に問題があり、「世界中のサーバーが簡単に乗っ取られる」事態を引き起こしました。
React2Shellは、そのJavaScript/React版とも言える性質を持っており、長期的な被害が懸念されています。

6. 想定される被害シナリオとビジネスインパクト

本脆弱性への対応が遅れた場合、攻撃者による悪用リスクは極めて高く、すでに複数の攻撃キャンペーンが観測されています。ここでは、技術的な被害シナリオと、それがもたらすビジネスへの影響について整理します。

6.1 観測されている攻撃手法

脆弱性の公表直後より、以下のような悪用事例が報告されています。

• 標的型攻撃による侵害: Amazon AWSの脅威インテリジェンスチームは、特定の国家を拠点とする攻撃グループによる活発な悪用を報告しています。サーバーの制御権を奪取し、機密情報の窃取や、将来的な攻撃のための拠点構築（Persistence）が行われています。
• 計算リソースの不正利用（クリプトジャッキング）: 侵害したサーバーにマイニングマルウェアを展開し、仮想通貨の採掘を行わせる事例です。システムパフォーマンスの著しい低下や、クラウド利用料の高騰といった直接的な損害が発生します。
• ボットネット化と踏み台利用: C2（Command and Control）サーバーとの通信経路を確立し、DDoS攻撃などの踏み台として悪用されるケースです。自社が被害者となるだけでなく、加害者として他組織への攻撃に加担させられるリスクがあります。

6.2 ビジネスへの深刻な影響

技術的な侵害は、以下のような経営リスクに直結します。

• 機密情報の漏洩: 顧客の個人情報（PII）や決済情報、企業の知的財産が流出する恐れがあります。
• 事業継続性の喪失: ランサムウェアの展開によりデータが暗号化され、基幹システムが停止に追い込まれるリスクがあります。復旧までのダウンタイムは甚大な機会損失を招きます。
• コンプライアンス違反と信用の失墜: 個人情報保護法やGDPRなどの規制違反による制裁金に加え、セキュリティ対策の不備によるブランドイメージの毀損は、長期的なビジネスへの足かせとなります。

7. 既存の脆弱性管理プロセスにおける死角

一般的な脆弱性スキャンツールを導入していても、React2Shellのようなアプリケーションライブラリに起因する脆弱性は検知漏れを起こすリスクがあります。その構造的な要因は主に2点挙げられます。

7.1 OS管理とアプリケーション管理の分離

従来のインフラ管理や脆弱性診断は、OSのパッケージマネージャ（yum, apt等）で管理されるミドルウェア（Apache, OpenSSL等）を主な対象としてきました。
一方、ReactやNext.jsなどのモダンなWebアプリケーションライブラリは、言語固有のパッケージマネージャ（npm, yarn等）を用いて、プロジェクトごとのディレクトリ内で独立して管理されます。これらはOSの管理台帳には登録されないため、OS層のスキャンだけでは実態を把握できません。OSに最新パッチを適用していても、アプリケーション層に脆弱性が残留するという「管理の死角」が生じます。

7.2 推移的依存（Transitive Dependency）による隠蔽

さらに検知を困難にするのが、ライブラリ間の複雑な依存関係です。

開発者が作成した package.json にReactが明記されていなくとも、利用しているUIコンポーネントやユーティリティツールが内部的にReactに依存しているケース（推移的依存）が発生するケースがあります。
「今回の問題に対してウチは関係ない」という認識であっても、依存ツリーの深層に脆弱なバージョンが組み込まれている可能性があり、これを手動や簡易的な検索で網羅することは現実的ではありません。

8. FutureVulsによる脆弱性管理：何ができるのか？

このような高度化・複雑化する脆弱性に対し、システムの担当者はどのように立ち向かえばよいのでしょうか。ここで有効な解決策となるのが、脆弱性管理サービス「FutureVuls」です。

FutureVulsは、単なるスキャンツールではなく、検知から判断、対応までのプロセス全体を高度化・自動化する「脆弱性管理プラットフォーム」です。React2Shellのようなライブラリレベルの脅威に対し、FutureVulsが提供する強力な機能群を解説します。

8.1 Lockfileスキャンによる「React」の炙り出し

FutureVulsは、サーバー内のファイルシステムを取り込み、アプリケーションが使用しているライブラリの依存関係定義ファイル（Lockfile: package-lock.json, yarn.lock など）を直接解析する機能を持っています。

• できること: サーバー上のどこに、どのバージョンのReactやNext.jsが存在するかを特定します。開発者が明示的にインストールしたものだけでなく、他のライブラリとの依存によるインストールまで検出可能です。
• メリット: OSのスキャンだけでは見逃してしまうアプリケーション層の脆弱性を見つけ出すことができます。また、Node.jsのプロジェクトだけでなく、Java, Go, Ruby, Pythonなど多様な言語の依存関係にも対応しています。

8.2 SSVCによる「今すぐやるべき」の自動判断

システムの担当者には日々大量の脆弱性情報が届きます。そのすべてに対応するのは不可能です。FutureVulsは、カーネギーメロン大学が提唱するSSVC（Stakeholder-Specific Vulnerability Categorization）という最新のトリアージ手法を実装しており、対応の優先順位を自動で決定します。

SSVCの判断ロジック（React2Shellの場合）

FutureVulsは、脆弱性の深刻度だけでなく、以下のコンテキスト情報を組み合わせて判断します。

1. Exploitation（悪用の状況）:
   「攻撃コードが公開され、実際に攻撃が行われているか？」
   → React2Shellは 「Active（活発に悪用中）」
2. Exposure（露出度）:
   「そのサーバーはインターネットに繋がっているか？」
   → 公開Webサーバーであれば 「Open（開放）」
3. Human Impact（業務への影響）, 参考記事:
   「止まったら困るシステムか？」
   → 基幹システムであれば 「High（高）」

これらの要素を組み合わせ、FutureVulsはReact2Shellに対し、以下画面のように最高ランクの優先度である「Immediate（即時対応）」という判定を下します。

逆に、インターネットに繋がっていない社内検証環境のサーバーであれば、自動的に「Scheduled（定期メンテで対応）」や「Out-of-Cycle（急ぐが緊急ではない）」に分類されるケースもあります。
これにより、担当者は「理論上の危険」に惑わされることなく、「現実に攻撃されるリスクが高い場所」にリソースを集中させることができます。

8.3 生成AI（FutureVuls AI）による専門家レベルのサポート

セキュリティ専任者が不在の組織においても迅速な対応が可能となるよう、生成AI機能が実装されています。
脆弱性の技術的な詳細解説や、対象環境に応じた具体的な修正コマンド（例: npm update next react 等）の提示を行い、調査から修正までのリードタイムを短縮します。

9. 結論

React2Shellは、Webアプリケーションのサプライチェーンに潜むリスクが、OSやミドルウェアと同様にクリティカルな脅威となり得ることを示しています。

「自社のコード」だけでなく、依存する「ライブラリやフレームワーク」を含めた包括的な脆弱性管理体制が求められます。FutureVulsのようなツールを活用し、アプリケーション層まで可視化範囲を広げ、リスクベースで優先順位を判断する運用プロセスを確立することが、組織のセキュリティ態勢を維持する鍵となります。