Source:https://thehackernews.com/2025/11/critical-react-native-cli-flaw-exposed.html
🛡 概要
人気の「@react-native-community/cli」に重大なリモートコード実行（RCE）脆弱性（CVE-2025-11953、CVSS 9.8）が判明し、既に修正が提供されています。原因はReact Nativeのビルドで利用されるMetro開発サーバが外部インターフェースへバインドし、/open-urlエンドポイントが未認証で到達可能な状態となり、特定条件下でOSコマンド注入を許す実装にありました。影響パッケージは「@react-native-community/cli-server-api」v4.8.0〜20.0.0-alpha.2で、修正版は20.0.0です。週あたり約150万〜200万ダウンロードの広範な利用実態から、開発者端末やソースコード、認証情報への実害が懸念されます。
🔍 技術詳細
問題の核心は、Metroサーバ（既定ポート: 8081）がローカルホストではなく外部インターフェース（0.0.0.0等）へバインドされやすい構成と、/open-urlの処理実装の組み合わせです。当該エンドポイントはHTTP POSTで渡されたユーザー入力を、npmパッケージ「open」が提供するopen()関数に引き渡します。open()はOS既定のハンドラ（Windowsの既定アプリ、macOSのopen、Linuxのxdg-openなど）を起動する仕組みですが、入力の妥当性検証が不十分だと、起動コマンドや引数が意図せず解釈され、結果的に任意のOSコマンド実行へ繋がります。特にWindowsではシェル経由の起動に依存する場面があり、攻撃者が引数を細かく制御して任意のシェルコマンドを実行しやすい特性があります。LinuxやmacOSでも任意バイナリの起動が可能で、パラメータ制御は相対的に限定されるものの、実行まで到達しうることが確認されています。攻撃シナリオとしては、ネットワーク上から到達可能なMetroサーバに対し、細工したPOSTリクエストを/open-urlへ送信するだけで成立します。宅内・社内LAN、テザリング、リモートワーク環境でポートが露出しているとリスクが高まり、NATやポートフォワーディング、誤ったファイアウォール設定により外部からのアクセスが可能になる場合があります。なお、React Nativeを用いていても、Metroを開発サーバとして使用しない構成は本件の影響を受けません。修正は「@react-native-community/cli-server-api」20.0.0で提供され、当該エンドポイントの安全化およびデフォルト露出の抑止が反映されています。
⚠ 影響
- 開発端末上での任意コード実行（開発者権限でのプロセス生成）
- ソースコード、環境変数、APIトークン、署名鍵などの窃取・改ざん
- ビルド成果物や依存関係の汚染によるソフトウェアサプライチェーン侵害
- Windowsでの引数制御容易性により、横展開・持続化・データ窃取の迅速化
🛠 対策
- 緊急パッチ適用：@react-native-community/cli-server-apiを20.0.0以降へ更新。lockfile（package-lock.json / yarn.lock / pnpm-lock.yaml）を再生成し、CIも再ビルド。
- 露出の最小化：Metroをlocalhost（127.0.0.1）へバインド。ファイアウォールでTCP/8081の受信を必要最小範囲に限定、NAT/ポートフォワーディング無効化。
- 代替策：即時更新できない場合はリバースプロキシで/open-urlをブロック、開発時はVPN配下のみで稼働。
- 実行境界の分離：開発用サービスはコンテナ/VMで隔離し、秘密情報は最小権限で保護。疑義期間の資格情報ローテーション、Git署名鍵の再発行を検討。
- 監視強化：Node.jsプロセスからのシェル/バイナリ起動（cmd.exe、powershell、bash、zsh、open、xdg-open等）をEDRで検知。
📌 SOC視点
- ネットワーク監視：8081宛のHTTP POST /open-urlを可視化。WAF/NGFW/プロキシでURI、メソッド、送信元の相関。短時間でのPOST急増や外部ASからの到達を検出。
- ホスト監視：親プロセスがnode（react-native start等）で、子にcmd.exe/powershell/bash/zsh/open/xdg-openや任意バイナリが連なるプロセスツリーをアラート。コマンドラインに「/c」「;」「&&」「|」「-enc」などの痕跡を確認。
- ログ相関：同時期の新規実行ファイル生成、%TEMP%や~/Downloads配下のペイロード作成、外向きC2様通信の有無を照合。
- ハンティング：該当期間の端末でスクリプト実行（.ps1、.sh）、資格情報アクセス、プロキシ認証異常を重点調査。
📈 MITRE ATT&CK
- TA0001 Initial Access — T1190 Exploit Public-Facing Application：外部へ露出した/open-urlに未認証で到達し悪用されるため。
- TA0002 Execution — T1059 Command and Scripting Interpreter（T1059.003 Windows Command Shell, T1059.004 Unix Shell）：open()を介してシェル/バイナリが起動し任意コマンド実行に至るため。
- TA0011 Command and Control — T1105 Ingress Tool Transfer：初期実行後、curlやPowerShellで追加ペイロード取得が想定されるため。
🏢 組織規模別助言
- 小規模（〜50名）：全開発端末でパッケージ更新を最優先。8081の外部露出を直ちに遮断し、簡易でもEDR/AVのプロセス監視を有効化。
- 中規模（50〜500名）：資産台帳でReact Native利用端末を特定し一斉更新。VPN外での開発サーバ起動を禁止し、WAFで/open-urlを遮断。検知・対応プレイブックを整備。
- 大規模（500名〜）：セグメント化とゼロトラストで開発ポートを分離。EDRへ振る舞い検知ルール（Node→Shell）を配信し、脆弱期間のスレットハンティングを実施。CI/CD用資格情報を再発行。
🔎 類似事例
- 開発用Webサーバ（Webpack DevServer/Storybook/Vite等）の誤公開に起因するRCE
- DNSリバインディングを利用してローカル開発サーバへ到達・操作を奪う攻撃
- open/xdg-openの不適切な利用によりURL処理からコード実行へ至った事例
🧭 次の一手
- @react-native-community/cli-server-apiを20.0.0以上へ更新し、lockfileを再生成。CI/CDも更新後に再ビルド。
- Metroのバインド先をlocalhostに固定し、TCP/8081の外部到達を遮断。社内スキャンで露出の有無を確認。
- 過去ログを精査（POST /open-url、Node→Shellの子プロセス生成、外向き通信）し、兆候があれば端末隔離と資格情報ローテーション、フォレンジックを実施。
- 公式アドバイザリとリリースノートを参照し、依存性更新の自動化、開発ポートの恒常的セグメント化、EDR/検知ルールの標準化を進める。
