2025年12月、React Server Components関連パッケージに存在する認証不要のリモートコード実行（RCE）脆弱性「CVE-2025-55182」が公開された直後から、セキュリティベンダーLACのJSOC（Security Operations Center）が実際の攻撃通信を多数検知したと注意喚起を発表しました。単なる技術的な脆弱性情報にとどまらず、公開からわずか数日で攻撃が観測されたという事実は、開発チームだけでなく情報システム部門・経営層を含めた「組織としての対応」が問われる事案であることを意味します。本記事では、LACの注意喚起で示された事実関係を踏まえたうえで、企業がとるべき対応をフェーズごとに整理し、平時からの備えまで含めて解説します。
何が起きたのか：CVE-2025-55182の概要
今回問題となったのは、React Server Components（RSC）をサポートする以下のパッケージに存在する脆弱性です。
- react-server-dom-webpack
- react-server-dom-parcel
- react-server-dom-turbopack
これらのパッケージのバージョン19.0.0、19.1.0、19.1.1、19.2.0が影響対象とされています。LACの発表によれば、脆弱性は2025年12月3日に公開され、翌12月4日には概念実証コード（PoC）も公開されました。JSOCが検証した結果、この脆弱性は「容易に悪用可能」であることが確認されており、実際に12月7日にはJSOCが緊急のシグネチャをリリースし、その後複数の顧客環境でインシデントが発生したことが報告されています。
脆弱性の仕組み
React Server Componentsは、サーバー側でレンダリングされたコンポーネントをクライアントへ効率的にシリアライズ・転送する仕組みです。今回の脆弱性は、この処理を担うパッケージに対して特定のリクエストを送りつけることで、認証を経ずにサーバー側でコマンドが実行されてしまうというものです。LACの発表では、これにより「任意のファイル作成やボット感染、バックドア設置などの被害が発生する可能性がある」と説明されています。
影響が及ぶ周辺エコシステム
React本体だけでなく、React Server Componentsの仕組みを利用する以下のフレームワーク・ツールも影響を受ける可能性があるとされています。
- Next.js
- React Router
- Expo
- Redwood SDK
- Waku
- @vitejs/plugin-rsc
ここが今回の脆弱性の厄介な点です。自社のコードを直接確認しても「Reactを使っている」という認識だけでは不十分で、依存しているメタフレームワークやビルドツールの内部で、対象パッケージが間接的に読み込まれているケースが少なくありません。棚卸しの対象は自社アプリケーションのpackage.jsonだけでなく、依存関係ツリー全体に及びます。
組織として見過ごせない理由
公開から攻撃までのリードタイムが極端に短い
脆弱性の公開（12月3日）からPoC公開（12月4日）、そして実際の攻撃検知・インシデント発生までの期間は、わずか1週間程度です。従来「まずは情報収集してから対応方針を検討する」という悠長な進め方では、パッチ適用前に攻撃を受けるリスクが現実のものとなります。情報システム部門やセキュリティ担当者には、脆弱性情報の入手から初動までのリードタイムを極限まで短縮する体制が求められます。
攻撃の実態はボット感染・踏み台化が中心
LACの観測によれば、現時点で検知されている攻撃通信の多くは、wgetやcurlといった標準ツールを悪用してファイルを取得し、ボットマルウェアに感染させることを目的としたコマンド実行の試みです。特定の国・地域からの通信が多い傾向も報告されています。これは「情報漏洩を狙った標的型攻撃」というより、脆弱なサーバーを無差別に探索し、乗っ取って別の攻撃の踏み台やボットネットの一部として利用しようとする、機会主義的な攻撃と考えられます。だからこそ、自社が直接の標的でなくても、インターネットに公開されたサーバーであれば等しくスキャン対象になり得るという前提で対応する必要があります。
サプライチェーン的な広がり
影響が及ぶパッケージがNext.jsやReact Routerなど複数のフレームワークにまたがっているため、自社で直接管理していないサードパーティ製のSaaSやベンダー提供のWebアプリケーションが影響を受けている可能性もあります。自社アプリケーションの棚卸しに加えて、委託先ベンダーや利用中のクラウドサービスへの確認も対応範囲に含める必要があります。
企業が取るべき具体的な対応ステップ
情報システム部門が主導して進めるべき対応を、優先順位付きのフェーズとして整理します。
フェーズ1：影響範囲の棚卸し（資産管理）
- 社内外で稼働している全Webアプリケーション・APIサーバーの一覧化
- 各アプリケーションのpackage.json、package-lock.jsonからReact関連パッケージのバージョンを確認
- Next.js、React Router、Expoなど関連フレームワークを利用しているプロジェクトの洗い出し
- 委託開発ベンダー・SaaSベンダーへの影響有無の確認依頼
フェーズ2：応急処置（一次防御）
- WAF（Web Application Firewall）やIPS（侵入防止システム）による異常な通信パターンの検知・遮断設定の確認
- 該当パッケージを利用する公開エンドポイントへのアクセス制御強化（可能であれば一時的なアクセス制限）
- セキュリティベンダーが公開する最新シグネチャの適用状況確認
フェーズ3：恒久対策（アップデート）
- 影響を受けるパッケージを修正済みバージョンへ速やかにアップデート
- アップデート後の動作検証（ステージング環境での回帰テスト）
- 本番環境への適用とリリース後の監視強化
フェーズ4：侵害有無の調査
- サーバー、ファイアウォール、プロキシ、各種セキュリティ製品のログから、既知の攻撃先IPアドレス・ドメインへの通信や名前解決の履歴を確認
- 脆弱性の影響を受けていた環境における不審なファイル・不審なプロセスの有無の確認
- 身に覚えのないコマンド実行履歴、想定外のcron登録やスタートアップ項目の確認
フェーズ5：インシデント対応体制の起動
- 侵害の痕跡が確認された場合は、該当端末・サーバーのネットワークからの隔離を最優先で実施
- 社内のインシデント対応手順（CSIRT体制など）に沿ったエスカレーション
- 必要に応じて外部のフォレンジック調査サービスやマネージドセキュリティサービスの活用を検討
- 経営層・広報・法務への報告要否の判断（個人情報や機密情報の流出可能性がある場合は特に迅速な判断が必要）
実務での確認例
影響範囲の棚卸しでは、まず自社が管理する各プロジェクトで対象パッケージのバージョンを機械的に洗い出すことから始めます。以下はNode.jsプロジェクトの依存関係から対象パッケージのバージョンを確認するコマンド例です。
#!/bin/bash
# 対象パッケージのインストール済みバージョンを一括確認するスクリプト例
TARGET_PACKAGES=(
"react-server-dom-webpack"
"react-server-dom-parcel"
"react-server-dom-turbopack"
)
for pkg in "${TARGET_PACKAGES[@]}"; do
echo "=== ${pkg} ==="
npm ls "${pkg}" --all 2>/dev/null || echo "未使用、または依存関係に含まれず"
done
複数のリポジトリを横断して確認する場合は、CI/CDパイプラインに組み込み、対象バージョンが検出された場合はビルドを失敗させる、あるいはSlackやチャットツールへ自動通知する仕組みを用意しておくと、今後同種の脆弱性が発表された際にも初動を早められます。
# package-lock.json から対象パッケージのバージョンを抽出する例（jq利用）
jq -r '
.packages
| to_entries[]
| select(.key | test("react-server-dom-(webpack|parcel|turbopack)"))
| "\(.key): \(.value.version)"
' package-lock.json
平時からの備え：次の脆弱性に備える体制構築
SBOM（ソフトウェア部品表）の整備
今回のように、直接利用しているつもりのないパッケージが依存関係の奥深くに潜んでいるケースでは、日頃からSBOMを整備し、自社の全アプリケーションがどのライブラリ・バージョンに依存しているかを一元的に把握できる体制が有効です。緊急時の棚卸しにかかる時間を大幅に短縮できます。
脆弱性情報のトリアージ体制
JPCERT/CCやセキュリティベンダーが発信する脆弱性情報を継続的にウォッチし、自社の技術スタックに関連する情報を迅速にトリアージ（重要度判定）できる体制を構築します。「誰が」「どのタイミングで」「何を判断するか」をあらかじめ定めておくことで、公開から攻撃までのリードタイムが短い脆弱性にも対応しやすくなります。
攻撃対象領域（アタックサーフェス）の縮小
本来インターネットに公開する必要のない管理画面やAPIエンドポイントを最小限に絞り込み、多層防御（WAF、IPS、EDR等）を組み合わせておくことで、個別の脆弱性が発見された際の被害範囲を限定できます。
企業対応チェックリスト
- [ ] 自社の全Webアプリケーション・APIの資産一覧が最新化されているか
- [ ] react-server-dom-webpack／parcel／turbopackおよび関連フレームワークの利用有無とバージョンを確認したか
- [ ] 委託先ベンダー・SaaS提供元への影響確認を依頼したか
- [ ] WAF／IPSのシグネチャが最新化されているか
- [ ] 影響を受けるパッケージを修正済みバージョンへアップデートしたか
- [ ] 既知の攻撃先IPアドレス・ドメインへの通信履歴をログから確認したか
- [ ] 不審なファイル・プロセス・コマンド実行履歴の有無を確認したか
- [ ] インシデント発生時のエスカレーションフロー（CSIRT、経営層報告）が明確になっているか
- [ ] 外部フォレンジック・マネージドセキュリティサービスの連絡先を把握しているか
- [ ] SBOMや脆弱性トリアージ体制など、平時からの備えを見直したか
まとめ
CVE-2025-55182は、React Server Componentsという比較的新しい技術領域で発見された脆弱性でありながら、公開から短期間で実際の攻撃が観測された点で、企業のセキュリティ対応力が試された事案といえます。重要なのは、開発チームによるパッチ適用だけで完結させず、資産の棚卸し、一次防御、恒久対策、侵害調査、インシデント対応体制の起動という一連のフェーズを、情報システム部門が主導して組織的に進めることです。そして今回の対応を一過性のもので終わらせず、SBOMの整備や脆弱性トリアージ体制の構築など、次の脆弱性に備えた平時からの体制強化につなげることが、企業のセキュリティレジリエンスを高める最も確実な方法です。
コメント