Reactの脆弱性から学ぶフレームワークとの付き合い方
ソフトウェアに潜む脆弱性の多くは、コーディング等のソフトウェアの開発工程で発生しています。
しかし、一部の深刻な脆弱性は開発に採用したフレームワークの内部に隠れていることがあります。
このようなリスクの影響を最小限に抑えるために、私たちはどのように備えれば良いのでしょうか。
目次
はじめに
こんにちは。アイソルートのhirokawa.yです。
Reactに関する脆弱性であるCVE-2025-55182 (React2Shell) が公表されてからしばらく経ちました。
オープンソースライブラリの潜在的な脆弱性は影響範囲が大きく、対応を求められる現場も多かったでしょう。
しかも、あの有名なReactからこれほど深刻な脆弱性が出るとは、想像もしていなかった人が殆どだと思います。
別の記事で紹介したように、多くの脆弱性はソフトウェアの開発工程で意識することで予防することができます。
参考:WEB開発者のための脆弱性診断入門｜ 開発者ブログ ｜ 株式会社アイソルート
とはいえ、自身が書いたコードに原因のある不具合はともかく、ライブラリに潜む脆弱性を検出することは困難です。
ソフトウェア開発者にとっては、単なる不運な事故だったと考えたくもなります。
しかし、本当に予防できる手立てはなかったのか、今回の事例から考えてみましょう。
この記事は アイソルート Advent Calendar 7日目の記事です。
脆弱性対応までのタイムライン
2025年11月29日にセキュリティ研究者によって報告され、2025年12月3日に公式から修正パッチがリリースされました。
また、2025年12月5日にCISAによって攻撃観測がKEVに登録され、2025年12月12日までに対応が必要と指定されました。
脆弱性の対応期限は、一般的に15～21日程度を目安に設定されることが多くなっています。
今回の判断は実際の攻撃観測や影響度合いから、極めて迅速な対応が必要ということを表わしています。
さて、皆さんの現場では既に対策が終わっているでしょうか。
ご存じの通り、脆弱性の公表と修正のリリースは同時に行われる慣習があります。
こういった対応が取られるのは、一度公開された脆弱性は悪用されるリスクが高くなるからです。
一方で、大々的に周知してユーザの危機感を煽らなければ、修正を適用してもらえないというジレンマがあります。
このように、既に公開されてしまった脆弱性に対しては、速やかに対処することが求められます。
しかし、こういった情報にいち早く気が付くのは意外と難しいものです。
今回のような緊急のケースでは、気が付いたときには手遅れということも起こり得ます。
そのため、CVEやKEVの情報を活用したリアルタイムの情報収集の仕組みが重要です。
今回の脆弱性の特異性
React2Shellには脅威度の基準として、CVSSの最高点である10.0が与えられています。
この衝撃は、2021年に発見されたLog4Shellに匹敵するといえば、その重大さが分かる人も多いでしょう。
実際のところ、脆弱性の特異性もそれを彷彿とさせるものです。
これらは任意コードが実行可能という深刻な脆弱性ですが、同種の脆弱性と比べても影響度を大きく評価されています。
その要因には、悪用のイメージなく広く使われているライブラリに内包される脆弱性であったことが挙げられます。
Log4Shellの例では、ログを出力するためのLog4jに、サーバに対する攻撃を想定していた人は少なかった筈です。
同じように、UI開発のためのReactではクライアント側の情報漏えいは想定し易いものの、
プログラムの役割や構造から言って、サーバに対する攻撃までは確かに想像しにくいものです。
しかし、セキュリティ研究者や悪意を持った攻撃者には、ここに目を付ける確固たる理由がありました。
React2Shellの仕組み
この脆弱性の仕組みを説明するには、従来のWeb開発におけるサーバとクライアントの境界を理解しなければなりません。
Reactには、Client Side Rendering (CSR) とServer Side Rendering (SSR) という二つの異なる概念があります。
CSRでは、サーバからクライアントに対してJavaScriptを送信し、ブラウザ内でWebページを生成します。
これによって、動的なコンテンツを快適に表示するネイティブアプリのような操作感を得ることができます。
しかし、最初にJavaScriptのデータを全て送信するため、最初のページ読み込みに時間が掛かったり、
検索エンジンから実際に表示される内容が見えないというデメリットもあります。
SSRはその逆で、サーバ側でWebページを生成してからクライアント側に送信し、ブラウザで表示します。
ページ単位で通信が発生する代わりに、ブラウザ内の動的処理がないため動作が早く、検索エンジンからも見え易くなります。
 |
 |
これらの良い所取りをしようとするのが、新たな概念であるReact Server Components (RSC) です。
そして、このRSCこそ今回の脆弱性が発生した部分でもあります。
RSCは、UI開発におけるサーバとクライアントの境界を横断する画期的な仕組みとして登場しました。
Reactを使用していても、RSCを使用せず、CSR/SSRのどちらかで完結している場合は今回の脆弱性の影響を受けません。
RSCが実現していることは、クライアントに見せたいUIをコンポーネントに分割し、
その中で必要な部分だけをクライアント側に生成してもらい、残りの部分をサーバ側で生成するという戦略です。
こうすることで、UIの使い易さと速さを両立することができます。
UIの実装ではユーザの操作に応じて新たな画面を表示する必要があります。
表示したい画面がサーバの担当するコンポーネントであれば、そのタイミングでクライアントに送信します。
これを実現するために開発されたFlightプロトコルでは、クライアントがサーバに要求することで、必要な部品を受け取ります。
 |
特別なことに見えるかもしれませんが、一般的なREST APIを使ったJSONデータのやり取りと概念的には大差ありません。
リクエストとレスポンスがあれば、悪性のデータを送りつけてみたくなるのがセキュリティ研究者や悪意を持った攻撃者です。
今回の脆弱性では、Flightに不正な値を注入して送信することで、サーバ上のUIロジックに任意の処理を実行させることが可能です。
簡単に言えば、React2Shellの正体はFlightで送信されたデータをサーバ側で正しいかどうか検証せずに処理してしまうことです。
このとき送信されたデータは、単なる表示用データではなく実行対象となるコンポーネントや処理を指定する情報として解釈されます。
ここでも本来行うべき無害化を行っておらず、結果として攻撃者の意図した処理を実行できる状態でした。
そして、Reactではこの機能を使用するかどうかはライブラリの利用者が選択可能ですが、
Reactベースのフレームワークでは明示的に意識しないままRSCを使用している場合があります。
このことも、今回の脆弱性の影響範囲を大きく広げている要因でした。
意識すべき対策
このように紐解いてみると、脆弱性の仕組みはよくあるWebサーバのコマンドインジェクションと同じで、
入力値チェックや処理を指定する際の無害化を行っていないという単純な話でした。
セキュアプログラミングに詳しい人であれば、十分に対策を講じ易い部類です。
しかし、UI開発という固定観念で油断していると、その危険性に気が付きにくくなってしまいます。
基本設計で使用するフレームワークを決めてしまえば、開発中にその内部実装に疑念を持つことは殆どないでしょう。
機能を抽象化して便利にしてくれている反面、その危険性まで不可視になってしまうのです。
一方で途中で述べたように、攻撃者はその機能の動作に潜む危険ポイントを敏感に察知します。
今回で言えば、UIを表示するためにデータを送信し、サーバがそれに応じた処理を行うという点です。
この動作は危険かもしれない、という感覚を持っていれば、React2Shellは予測可能な事態だったのです。
使用するフレームワークを選定するときには、どのようなライブラリを使っているか、
その設計思想に弱点はないか、その実装が成熟しているか、ということを見極めた上で決定する必要があります。
そこで、React2Shellの教訓として、以下の観点を確認するようにしてください。
1. クライアントからサーバへデータを送信している
2. 送信されるデータは、JSON等の構造化データであり、任意に改変できる
3. 想定外の入力値に対する挙動が、公式ドキュメントで明記されていない
これら全てに当てはまる場合、そのフレームワークを使用するのは待った方が良いかもしれません。
おわりに
今回はReact2Shellの動作を出来るだけ簡単に説明しました。
実際に攻撃に悪用するには不十分ですが、フレームワークの安易な選択に待ったを掛けるには十分です。
有名かどうかで判断するのではなく、機能の安全性まで考慮するようにしましょう。
ただ、それでも脆弱性を完全に回避することはできません。
そのため、リアルタイムで脆弱性情報を収集し、それが自分たちに影響するのか判断する必要があります。
こういった手間のかかる定常業務も、AIの力を借りることで楽にできるかもしれません。
アイソルートではチャットボットの構築やワークフローの導入支援も承っていますので、
現状の脆弱性管理に不安がある場合は、ぜひ一度ご相談ください。
