React2Shellによる影響
タイトル：フロントエンド界のLog4Shell？「React2Shell」が示すReact Server Componentsの新たな脅威
「CVSSスコア 10.0」——この数字を見たとき、背筋が凍る思いをしたエンジニアは私だけではないはずです。
2025年12月、React Server Components（RSC）における深刻な脆弱性、通称 「React2Shell (CVE-2025-55182)」 が公開されました。なぜこれほど騒がれているのか？それは、これが単なるバグではなく、認証なしでリモートから任意のコードを実行できる（RCE）という、極めて危険な脆弱性だからです。[1]
今回は、この「React2Shell」がなぜこれほど注目されているのか、そして私たちがどう向き合うべきかを解説します。
なぜ「React2Shell」と呼ばれるのか？
この名前は、数年前にJava界隈を震撼させた「Log4Shell」に由来しています。Log4Shellがそうであったように、React2Shellもまた、広く使われているライブラリ（React/Next.js）の深層に潜んでおり、影響範囲が広く、かつ攻撃が成立しやすいという共通点があります。
特にNext.jsのApp Routerを採用している場合、デフォルトで影響を受ける構成になっていることが多く、多くの開発者が「自分のサイトは大丈夫か？」と確認に追われることになりました。[2]
技術的な「面白さ」と「怖さ」
攻撃手法の詳細は省きますが、この脆弱性の根本にはJavaScript特有の 「ダックタイピング（Duck Typing）」 の悪用があります。
攻撃者は巧妙に細工されたリクエストを送ることで、サーバー上のReactコンポーネントに対し、予期しない型のオブジェクトを処理させます。JavaScriptの柔軟性が仇となり、本来実行されるべきではないコードへのパスが開かれてしまうのです。この「柔軟性がセキュリティホールになる」という点は、JSエンジニアとして非常に考えさせられる事例です。[1]
今すぐ確認すべきこと
もしあなたが Next.js (v15.x, v16.x) や React 19 を使用しているなら、今すぐ以下の対応を行ってください。
- バージョンの確認: 影響を受けるバージョンを使用していないか確認する。
- パッチの適用: 公式から提供されている修正パッチ適用済みのバージョンへアップデートする（Next.jsの最新版など）。
- WAFの設定: AWS WAFなどのファイアウォールで、既知の攻撃パターンをブロックするルールを適用する。[2]
最後に
React Server Componentsは、フロントエンド開発に革命をもたらしました。しかし、サーバーサイドでJSが動くということは、従来のフロントエンドセキュリティの常識だけでは守りきれない領域が生まれたことも意味します。
React2Shellは、私たちに「サーバーサイドレンダリング時代のセキュリティ」を再考させる良い（そして手痛い）きっかけになるかもしれません。