ReactサーバーコンポーネントのDoSおよびソースコード露出の脆弱性が公開

 (react.dev)
4 ポイント 投稿者 GN⁺ 2025-12-13 | 1件のコメント | WhatsAppで共有
  • React Server Componentsで サービス拒否（DoS） および ソースコード露出 の脆弱性が新たに発見・公開された
  • 今回の脆弱性では リモートコード実行（RCE） は不可能だが、サーバー停止やコード流出のリスクが存在する
  • 影響を受けるパッケージは react-server-dom-webpack、react-server-dom-parcel、react-server-dom-turbopack の 19.0.0〜19.2.2 バージョン で、修正版は 19.0.3、19.1.4、19.2.3
  • DoS脆弱性（CVE-2025-55184、CVE-2025-67779） は悪意あるHTTPリクエストによりサーバーの無限ループを引き起こす可能性があり、ソースコード露出脆弱性（CVE-2025-55183） はサーバー関数のコードの一部を返す可能性がある
  • Reactチームは即時アップグレードを推奨しており、今回の追加公開は セキュリティ対応サイクルの正常なプロセス だと説明している

新たに公開された脆弱性の概要

  • セキュリティ研究者が先週公開された 致命的脆弱性のパッチ検証中 に、追加で2件の脆弱性を発見した
  • 新しい脆弱性では リモートコード実行（RCE） は不可能で、既存の React2Shellパッチ は引き続き有効
  • 新たに公開された脆弱性は次のとおり
    • サービス拒否（DoS） — CVE-2025-55184、CVE-2025-67779（CVSS 7.5、高深刻度）
    • ソースコード露出 — CVE-2025-55183（CVSS 5.3、中程度の深刻度）
  • Reactチームは 即時アップグレード を推奨

既存パッチの不完全性

  • 先週配布された 19.0.2、19.1.3、19.2.2 バージョンのパッチは不完全 であり、再度更新が必要
  • 完全な修正は 19.0.3、19.1.4、19.2.3 バージョン に含まれる
  • 以前の投稿の 更新手順 に従う必要がある
  • 修正版の配布完了後、追加の詳細が公開される予定

影響を受けるパッケージおよびバージョン

  • 脆弱性は CVE-2025-55182 と同じパッケージおよびバージョンに存在する
  • 影響を受けるバージョン: 19.0.0〜19.2.2
  • 影響を受けるパッケージ:
    • react-server-dom-webpack
    • react-server-dom-parcel
    • react-server-dom-turbopack
  • 修正版: 19.0.3、19.1.4、19.2.3
  • サーバーを使用しない、または React Server Components をサポートしないアプリは影響を受けない

後続の脆弱性公開でよくあるパターン

  • 致命的なCVE公開後、関連コードパスを追加分析する過程で後続の脆弱性がしばしば発見される
  • 例として Log4Shell 後に追加のCVEが報告された事例に言及
  • こうした追加公開は セキュリティ対応が正常に機能していることを意味する

影響を受けるフレームワークおよびバンドラー

  • 次のフレームワークおよびバンドラーは脆弱なReactパッケージを含むか依存している
    • next、react-router、waku、@parcel/rsc、@vitejs/plugin-rsc、rwsdk
  • 以前の投稿の 更新手順 に従う必要がある

ホスティングプロバイダーの緩和措置

  • 複数のホスティングプロバイダーと協力して 一時的な緩和措置 を適用
  • ただし、これらの措置に依存せず 直ちに更新 する必要がある

React Native関連のガイダンス

  • React Nativeのみを使用するユーザーは追加対応不要
  • モノレポ環境 では次のパッケージのみ更新が必要
    • react-server-dom-webpack
    • react-server-dom-parcel
    • react-server-dom-turbopack
  • react および react-dom は更新不要
  • 関連する詳細は React Native の GitHub issue を参照

高深刻度: サービス拒否（DoS）

  • CVE-2025-55184、CVE-2025-67779、CVSS 7.5
  • 悪意あるHTTPリクエストが Reactサーバー関数エンドポイント に送信された場合、デシリアライズ過程で 無限ループが発生 する
  • サーバープロセスが停止し、CPUを過剰に占有する可能性がある
  • サーバー関数エンドポイントを直接実装していなくても、React Server Components をサポートするアプリ であれば脆弱な可能性がある
  • 本日配布されたパッチは 無限ループ防止 により問題を解決する
  • 初期修正が不完全だったため、追加の脆弱性（CVE-2025-67779）で補完された

中程度の深刻度: ソースコード露出

  • CVE-2025-55183、CVSS 5.3
  • 悪意あるHTTPリクエストにより、サーバー関数の ソースコードの一部が返される 可能性がある
  • サーバー関数が文字列引数を明示的または暗黙的に露出する場合に発生する
  • 例示コードでは、データベース接続キーなどの ハードコードされた秘密値 が露出する可能性がある
  • パッチは サーバー関数ソースコードの文字列化防止 により問題を解決する
  • 露出範囲はサーバー関数内部のコードに限定され、ランタイムシークレット（process.env.SECRET など） には影響しない
  • 本番バンドル基準での検証が必要

タイムライン

  • 12月3日: Andrew MacPherson が Vercel および Meta Bug Bounty にコード露出を報告
  • 12月4日: RyotaK が DoS脆弱性を報告
  • 12月6日: Reactチームが両問題を確認し、調査開始
  • 12月7日: 初期修正案を作成し、検証計画を策定
  • 12月8日: ホスティングプロバイダーおよびオープンソースプロジェクトへ通知
  • 12月10日: 緩和措置を適用し、パッチ検証を完了
  • 12月11日: Shinsaku Nomura が追加のDoSを報告し、CVE-2025-55183・55184・67779 を公開

報告者

  • Andrew MacPherson (AndrewMohawk) — ソースコード露出を報告
  • RyotaK (GMO Flatt Security Inc) および Shinsaku Nomura (Bitforest Co., Ltd.) — サービス拒否脆弱性を報告

関連記事

1件のコメント

 
GN⁺ 2025-12-13
Hacker Newsのコメント

  • React Server Components（RSC）は、前からずっとしっくりこなかった。
    JavaScriptコードを見るだけでは、クライアントで実行される部分とサーバーで実行される部分を区別しにくいからだ。
    そのうえ、これを実装するには深いシリアライズRPCメカニズムが必要で、開発者にとって不透明であり、セキュリティ脆弱性のリスクを高めるポイントにもなる。

    • 以前のNextJS pages router時代は、サーバーコードとクライアントコードの境界が明確でよかった。
      しかしapp routerに変わってからは混乱した。コードが両方で実行されうるせいで、Headersのようなオブジェクトが常に存在するわけではなく、何がどこで動くのかが分かりにくかった。
    • 新しく入ったチームでNextを使っているのを見て、「これがどう動くのか分かっている人はいますか？」と聞いたが、誰も明確に説明できなかった。
      React+Nextはうまく動いているときは魔法のように感じるが、チームで仕事をすると予測可能性がどんどん失われるのが問題だと感じる。
    • だから私はInertia.jsのファンだ。Inertia.jsはLaravel、Rails、Djangoのような伝統的なMVCバックエンドと、React、Vue、Svelteのようなフロントエンドツールを自然につないでくれる。
      役割が明確で、作業が単純で、ほとんどのプロジェクトで最も安全な選択だと思う。
    • RSCとSSRは過剰に採用されている気がする。
      ランディングページやマーケティングページならSSRは有用だが、一般的なSaaSダッシュボードのようなアプリでは、複雑さのわりに得られるものがほとんどない。
    • 他のフレームワーク（Angular、SvelteKit、Nuxt）がこうした脆弱性にどれほど晒されているのか気になる。
      Reactが単に人気だから注目されているだけなのか、それとも構造的により危険なのかという疑問がある。

  • 先週RSCを見てみたが、複雑さが高すぎるうえ、ドキュメントもほとんどなかった。
    Reactはまだ実験的機能だと言っているが、NextJSはすでに広く展開している。
    今後さらに多くのセキュリティ問題が出てきそうだし、Nextのビルドシステムは過度に複雑で、デバッグさえ難しかった。
    得られる利点に対してコストが大きすぎる。

    • 以前から、Nextは「まだ本番準備ができていないReact機能」を最新機能のように見せている、という不満があった。
      それで私もNextを離れた。認知負荷が高すぎるわりに得るものが少なかった。
    • Reactには長年ドキュメント不足の問題があった。
      RSCだけでなく全体として明確なガイドが出るのが遅く、CRAのようなツールも公式には認めていない。
      今になってようやくuseEffectのドキュメントは良くなったが、遅すぎた。
      2025年になった今でも実務で使っているのに、依然として明確な文書化が不足している。

  • SPAの核心は、「アプリ全体をクライアントに送り、サーバーとはデータだけをやり取りすること」だった。

    • ところが今、C#界隈ではBlazor Serverが流行している。
      昔の.aspx Web Formsのように、すべてのクリックや入力がサーバーへ送られ、変更されたDOMが再び返ってくる。
      実質的に昔の方式に戻ったようなもので、少しあきれる。
    • 結局、多くの開発者は再びサーバーサイドレンダリングの理由を理解し、PHP、Rails、Springのようなフルスタックフレームワークへ回帰した。
    • しかし最近は、Reactのようなライブラリで静的サイトを作るケースが増えており、単純なテンプレートエンジン+JSの組み合わせより遅くて複雑だ。
      「適切な道具を選ぶ感覚」が失われたのは残念だ。
    • もちろんRSCは純粋なSPA向けではない。別の目的を持ったアプローチだ。

  • 今回のセキュリティ告知では、「重大なCVEが見つかると、後続の脆弱性がよく明らかになる」という一文が最も目についた。
    問題の範囲や影響、緩和方法を説明する前に、CVEを正当化しようとしているように見えて不安だった。

    • ただ、ある人は「それは正当化ではなく、人々が最初に気になる点についての説明にすぎない」と見ている。
    • フィードバックを反映して文言を修正したとのこと → 修正されたPRリンク
    • これを**認識管理（perception management）**と表現する人もいた。
      関連Wiki記事
    • この件にはキャリア上の利害関係が絡んでいると見る向きもある。
    • 「これはVercelのマーケティングチームが書いた文章のようだ」と言う人もいた。

  • 15年前にOpaでもすでに似た試みがあった。
    クライアントコードとサーバーコードを自動で分離し、JSXに似た構文を導入していた。
    しかしセキュリティ分析を強化していくうちにコンパイラが巨大化し、結局は単一アプリという概念よりも、明確な分離の重要性に気づいた。
    いつかLLMがこうしたコードを自動生成するかもしれないが、今は単純な構造のほうがよいと思う。

    • 実際、RSCの脆弱性はコード分割そのものより、シリアライズ/デシリアライズ過程の動的性質に起因している。
      JSのプロトタイプ汚染、関数のtoString、Promiseのオーバーライドのような問題を防ぐためのパッチが進んでいる。
      RSCはimport "server-only"やimport "client-only"のような静的検証で環境を分けているため、構造的には安全なアプローチだ。
    • 似たアイデアとしてElectric Clojureというプロジェクトもある → リンク
    • 参考までに、Ocsigen EliomはOpaより前にこうした概念を試していた。

  • ReactはもともとMVCのViewとして小さく単純だった頃がよかった。
    今は機能が増えすぎて、肥大化した感じがある。

    • ただしRSCは別ライブラリであり、標準のReactインストールには含まれていない。
    • 昔のバージョンに戻りたければ git checkout v15.0.0 でよい。

  • RSCはそもそも存在すべきではなかった。
    ほとんどのアプリはサーバーでHTMLをレンダリングすれば十分で、SPAが必要になるのはごく一部だ。
    RSCは複雑性とセキュリティ脆弱性を増やしただけだ。

    • 同意する。だが、ブートキャンプやVC資金に後押しされたエコシステムがこの方向を押し続けている。
      BunやVercelのようなプロジェクトが、「すべてが完璧に動くJSユートピア」という幻想を売っているため、この流れは簡単には消えない気がする。

  • 以前、Dan AbramovとXでRSCについて議論したことがある。
    彼は革新的な機能だと言っていたが、私は「自分の足を撃つ銃」だと言った。結局、現実はその通りになった。

    • 個人的にはRSCでアプリを作ってみたが、それでもこの方式は気に入っている。
      ただ、プロトコルレベルのバグの可能性を過小評価していた。今回の脆弱性はシリアライズプロトコルに集中している。
      セキュリティコミュニティがようやく深く見始めたところで、チームにはもっと早く対応してほしかった。
    • 成功したシステムは結局、過剰な拡張によって怪物になりがちだ。
      Reactも単純なレンダリングライブラリからランタイムへと変わる中で、複雑さが爆発した。
    • 個人的にはDanのアプローチがそれほど優れているとは思わない。
      一方でVueとViteははるかに洗練された設計だと思う → Evan You個人サイト
    • もちろん、ほとんどのアイデアは失敗するものなので、批判ばかりする態度にも注意すべきだ。
      ときには大胆な試みがホームランになることもある。
    • 「あなたのほうが優れているのかもしれない」という励ましのコメントもあった。

  • RSCがフロントエンドがバックエンドを飲み込もうとする試みだとすれば、HTMXはその逆だ。
    HTMXはクライアント–サーバー境界を維持するのでバックエンド側は安全だが、フロントエンドではXSSリスクがある。

    • ただしHTMXはすでにテンプレートエンジンの自動エスケープでXSS問題を解決している。
      関連文章

  • Nextチームが新しいセキュリティアップデートを発表した → NextJS Security Update 2025-12-11
    14.x、15.x、16.xバージョンに影響する