- ReactとNext.jsで、リモートコード実行（RCE）が可能なセキュリティ脆弱性が報告された
- この問題はNext.jsパッケージ内部で発生し、攻撃者が悪意ある入力により任意のコード実行を引き起こせる可能性がある
- VercelはGitHubの**セキュリティアドバイザリ（GHSA-9qr9-h5gf-34mp）**を通じて、該当脆弱性を公開し、更新版を配布した
- 利用者は最新バージョンにアップグレードして脆弱性を緩和する必要がある
- 今回の事例はフレームワークレベルのセキュリティ管理の重要性を再び浮き彫りにした
RCE脆弱性の概要
- Next.jsとReact環境で、リモートコード実行が可能な脆弱性が発見された
- 攻撃者がサーバー側で任意のJavaScriptコードを実行できるリスクが存在する
- この脆弱性はNext.jsパッケージの内部コード処理で発生する
- 具体的な脆弱関数やモジュールに関する詳細は公開されていない
影響と対応
- VercelはGitHubの**セキュリティアドバイザリ（GHSA-9qr9-h5gf-34mp）**を通じて問題を正式に発表した
- 当該アドバイザリはNext.jsリポジトリのセキュリティ通達セクションに掲載された
- 脆弱性の対象バージョンは明示されていないが、更新版の配布が行われた
- ユーザーには最新の安定版にアップグレードすることが推奨される
セキュリティアドバイザリと対策
- Next.jsパッケージを使用するすべてのプロジェクトは即座にバージョン確認が必要
package.jsonのNext.jsバージョンは最新の状態に保つ必要がある
- Vercelは修正版配布以外の追加的な緩和策について言及していない
- 脆弱性の技術的な詳細は非公開のままで、セキュリティ上の理由から限定的な情報のみが提供されている
重要性
- 今回の脆弱性は、サーバーサイドレンダリング環境におけるコード実行リスクを示した
- ReactおよびNext.jsベースのサービス運用者はセキュリティアップデートを定期的に適用する必要がある
- フレームワークレベルのセキュリティ脆弱性がアプリケーション全体のセキュリティに直接的な影響を与えうる
1件のコメント
Hacker Newsの意見
今回の脆弱性は、RSC/server actions導入時から警告されていた最悪のシナリオが現実化した事例だ
サーバーがクライアントの信頼できない入力をそのままデシリアライズし、モジュールとexport名を探して実行していた
hasOwnPropertyパッチで防げはするが、根本的にはReactがRPCレイヤーを作っているという事実を明確に認識していなかったのが問題だgRPCやSOAPのような従来のRPCフレームワークは明示的なスキーマとサービス定義で境界を明確にするが、Reactはバンドラーから見えるすべてのAPIを公開する方式なので危険だ
こうした設計によるセキュリティ問題は今後も繰り返される可能性が高い
明示的なスキーマがあっても、最後の段階で信頼できない入力がサーバー名前空間の任意のオブジェクトを参照できるようにしていれば意味がない
"use server"と記された関数だけが公開され、ReactチームもRPCシステムを設計していることは認識しているこの種のバグは他のRPCシステムでも十分起こり得る（Reactコントリビューターです）
ただし古い非公開レポジトリを維持するのも良い選択ではない
Nextは静的ビルドだけが唯一の長所だ
そのサポートが打ち切られたら、もはや使う理由はない
Facebook/Metaのセキュリティアドバイザリによると、React Server Components 19.0.0〜19.2.0には**認証前のリモートコード実行（RCE）**脆弱性が存在する
React公式ブログの告知でも、クライアントがサーバー関数を呼び出せる構造のため、攻撃者が悪意あるHTTPリクエストを作成してサーバー上で任意コードを実行できると説明している
hasOwnPropertyチェックの追加なら、攻撃はおそらくプロトタイプチェーンのプロパティ（__proto__など）を参照する方式だったのだろう修正コミットはこのコミットのようだ
複数の変更と一緒にsquashされ、詳細が見えにくくなっているように見える
コードで公開される関数の一覧をホワイトリスト方式で制限するパターンが4か所で見られる
Vercelはすでにプラットフォームレベルの保護で悪意あるリクエストパターンを遮断している
告知参照
CloudflareもWAFルールで先回りして対応した
それでもNext、React、その他のメタフレームワーク依存関係を直ちにアップデートすることを強く推奨する
Deno Deploy/Subhostingのブログ記事も参考になる
PoCリポジトリを参考に脆弱性を再現してみた
react-server-dom-webpackでもRCEが実行できたので、メカニズムの理解が完全には合っていないようだ実際のNext.jsプロジェクトでデモを見せてもらえるとよい
「VercelなしではRCEはない」と言われるほど、今回の件はホスティング環境とセキュリティの相関関係を浮き彫りにしている
CVEスコア10.0は、これほど広く使われているプロジェクトでは衝撃的な数値だ
それでも週間ダウンロード数は31万件を超えている
Reactチームがなぜこんな混乱を招く機能に時間を使うのか理解しがたい
SSRより何が優れているのか、性能向上がどれほどあるのかも疑問だ
Hook導入以降、開発者体験は悪化したのに、それを改善するよりさらに別の複雑さを足している
むしろJS本来の制御フローをコンポーネントロジックで自然に使えるようにしてほしい
私はこれを**コンポーネント化されたBFF（Backend for Frontend）**レイヤーだと見ている
各UI断片が対応するバックエンドロジックと直接結び付けられ、
fetch呼び出しなしでデータを取得できるこうするとフロントとバックエンドを一緒に進化させやすくなり、必要なデータだけを細かくロードできる
結局のところ、UI専用のサーバーロジックをコンポーネント構造の中に自然に溶け込ませられる
SvelteやReactのコンパイラベースのモデルの方がはるかに扱いやすい
Vue、Svelte、Angularなどはいずれも別個のコンパイラとファイル拡張子を必要とする
一方でReact/JSXはプリプロセッサ段階ですでに優遇されている
Rustはマクロシステムでこの問題を解決した — たとえばLeptosやYewは標準の
.rsファイル内でJSXやHTMLテンプレートをサポートしているJSがこうした拡張性を持てない限り、Webは今後も複雑で非効率な環境にとどまる可能性が高い
クライアント側の負荷を減らそうとしたが、それすら失敗したように感じる
Reactブログの詳細説明も参考になる