2025年12月から2026年1月にかけて、React Server Components（RSC）周辺で、脆弱性の「第1波」「第2波」「第3波」が連続して公表された。中でも2026年1月に更新されたCVE-2026-23864は、認証不要でメモリ枯渇やCPU過負荷を誘発し得るDoSとして位置づけられ、前回修正の“不完全さ”が原因で追加対応が必要になった事例である。

本稿は、公開情報に基づき、なぜ修正が繰り返し不完全になり得たのかを「RSCシリアライゼーション層」という設計境界に着目して分析し、運用側が取るべき実務的な防御策を整理する。

三つの波: 2025年12月3日→12月11日→2026年1月26日

Reactチームの公表内容を時系列で整理すると、RSCの「Server Function endpoint（Server Actions等）」と「Flight/RSCのデシリアライゼーション」が、攻撃面として前景化していることが分かる。

  • 第1波（2025-12-03公表）: RSCのServer Functionに関連するRCE（CVE-2025-55182）。影響はRSCが有効でServer Function endpointが露出している構成に及ぶ。
  • 第2波（2025-12-11公表）: DoS（無限ループ）およびソースコード露出。DoSはCVE-2025-55184 / CVE-2025-67779として整理され、修正が提供された。
  • 第3波（2026-01-26更新）: 追加のDoS。とりわけCVE-2026-23864（CVSS 7.5）は、前回修正の不完全さに起因して追加で対処が必要になったと説明されている。

重要なのは、RSCの利用形態が「Server Functionsを明示的に使っていない」場合でも、フレームワークの設定やビルド生成物としてServer Function endpointが露出し得る点である。結果として、アプリ開発者の“意図”と、実際の公開攻撃面が乖離しやすい。

なぜ「不完全修正」が起きたのか: シリアライゼーション境界の複雑性

同一領域で複数回の脆弱性が連鎖する場合、単純に「実装ミスが多い」というより、境界設計そのものが難易度を押し上げているケースが多い。RSCにおけるシリアライゼーション層の特徴は、概ね次の3点に要約できる。

  • プロトコル化: RSCは単なるUI機能ではなく、クライアントとサーバの間でコンポーネントツリーや参照（場合によってはServer Function呼び出し）を表現する「転送表現（プロトコル）」に近い。入力は事実上、外部から到達し得る。
  • 多重実装・多経路: React本体、RSC実装（例: react-server-dom-*）、フレームワーク（Next.js等）、ホスティング（エッジ/サーバレス/Node）などで、同一“概念”が複数のコードパスに分岐する。ある経路の修正が、別経路に波及しないことが起こり得る。
  • 非対称なリソース消費: デシリアライゼーションは、攻撃者が小さな入力で大きな計算量・メモリ確保を引き起こせる典型領域である。無限ループや指数的展開、重複構造の増幅は、修正の粒度が粗いと“抜け道”として再発しやすい。

第3波の文脈で「不完全修正」が明示された点は、単発のバグ修正というより、入力境界の扱い（検証、制限、フェイルセーフ）が、設計上の中核リスクになっていることを示唆する。

CVE-2026-23864: メモリ枯渇DoSを成立させる条件

公開情報から読み取れる要点は次の通りである。

  • 攻撃類型: デシリアライゼーション起因のDoS（メモリ枯渇、CPU過負荷、クラッシュ等）。
  • 前提条件: RSCが有効で、Server Function endpointが到達可能であること。認証前の到達が可能な構成では、インターネットからの無差別到達を許す。
  • 運用影響: サーバレスや水平分割構成でも、リクエスト単位のコスト爆発が生じれば、同時多発でワーカー枯渇や課金増大を招く。オンプレ/固定台数でも、メモリ枯渇は再起動ループを誘発し、実質的な停止となる。

ここでの教訓は「RSCは安全か」ではない。“シリアライゼーション境界に、未検証入力を通していないか”という問いに置き換える必要がある。RSCの利便性は高いが、外部入力の取り込み点を増やした以上、従来のSSR/CSRとは異なる防御設計が要求される。

運用側の即応: まずバージョン固定と到達面の把握

最優先は、影響を受けるReactおよび関連パッケージを、Reactチームが提示する修正済みバージョンへ更新することである。同時に、更新が間に合わない場合の“時間稼ぎ”として、到達面を絞る。具体策は以下である。

  • 修正済みバージョンへ更新: Reactの該当系列で、修正が取り込まれた版へ上げる。フレームワークがReactを内包・固定している場合、フレームワーク側の更新も必要である。
  • Server Function endpointの露出確認: ルーティング、ビルド成果物、ホスティング設定（プレビューURL含む）まで含め、外部から到達可能かを検査する。「機能を使っていない」ことは、露出していないことを意味しない。
  • リクエスト制限: 逆プロキシ/エッジでのボディサイズ制限、レート制限、異常パターンの遮断を実装する。DoSは“成立”を阻止できなくても、“同時多発”を減らせる。
  • フェイルセーフ: ワーカー単位のメモリ上限、過負荷時のサーキットブレーカー、ヘルスチェックと自動退避など、落ち方を制御する。DoSは完全防御よりも、被害半径の制御が効く。

設計上の教訓: RSCは「アプリ内DSL」ではなく「外部入力を扱う層」である

RSCシリアライゼーション層の本質的リスクは、次の二律背反にある。

  • 表現力の拡大: コンポーネントツリーや参照を転送できることは、開発体験を改善する一方で、入力空間を爆発させる。
  • 実装の分散: エコシステムの中で“同じ概念”が複数経路で実装されるほど、抜け道が残りやすい。修正は「1箇所」では完結しない。

従って、再発防止の焦点は「個別CVEのパッチ適用」だけでなく、入力検証・制限・観測可能性をRSC境界に組み込むことにある。具体的には、入力サイズやネスト深度の上限、デコードの段階的中断、異常系の安全な失敗（early abort）、そして異常パターンの可視化が要点となる。

FAQ

影響はNext.jsだけの問題なのか？

Next.jsが典型例になりやすいが、本質は「RSCを有効にしたアプリで、Server Function endpointが露出しているか」である。フレームワークに依存せず、React/RSCを採用する構成全体が対象になり得る。

Server Functions（Server Actions）を使っていないのに、なぜ影響し得るのか？

公開情報では、Server Function endpointが露出していることが条件として示されている。実装・設定・ビルドにより、開発者が意図しない形でendpointが到達可能になる場合があるためである。

WAFやCDNがあれば、アップデートは不要か？

不要にはならない。WAF等は同時多発の抑制や一部パターン遮断に寄与するが、デシリアライゼーション由来のDoSは“正規の経路”に見える入力でも成立し得る。根本対策は修正版への更新である。

最短で何を確認すべきか？

1) 本番でRSCが有効か、2) Server Function endpointが外部から到達可能か、3) React/関連パッケージ/フレームワークのバージョンが修正版か、を順に確認する。加えて、リクエストサイズ制限とレート制限を先に入れると、更新までのリスクを下げられる。

参考文献