React/Next.js RSC DoS緊急対応｜16.2.3から最新パッチ確認まで

React/Next.jsを本番運用していて、突然のCPUスパイクやサーバーレス課金の急増が怖い人に向けた記事です。CVE-2026-23869は未認証で到達できるDoSなので、「あとで直す」で放置すると、障害より先にコストが跳ねるケースもあります。この記事では5分の影響判定から当日中の更新、WAFをどう併用するかまで順番に整理します。僕は福祉事業のIT全般を担当しつつ、複業でReact/Next.jsのAI×SaaS案件にも入っているので、現場で回している手順をそのまま共有します。

まず5分で把握するCVE-2026-23869対策の全体像

CVE-2026-23869は、React Server ComponentsのServer Functionデシリアライズ処理を悪用したDoSです。イメージとしては、受付で本来1秒で終わる確認作業を、悪意ある来訪者が何度も複雑化して、窓口CPUを占有してしまう状態です。つまり「データを盗まれる脆弱性」より「サービスを止められる脆弱性」だと捉えるのが実務的です。

• 重大度 — CVSS 7.5（High）で、未認証・ネットワーク越しに到達可能です
• 攻撃特性 — 特製リクエストでCPUを最大約1分消費しうると公開情報で示されています
• 公開日 — React/Next.jsのGHSAは2026年4月8日に公開されています
• React修正版 — 19.0.5 / 19.1.6 / 19.2.5です
• Next.js修正版 — 15.5.15 と 16.2.3です

一次情報はReact公式アドバイザリとNext.js公式アドバイザリです。ここだけ押さえれば、社内共有で情報がぶれにくくなります。まず「何が壊れるのか」を短く言語化して、関係者の意思決定スピードを上げるのが先です。

影響判定チェックリスト（App Router・Server Function・RSC依存）

緊急対応で一番やってはいけないのは、全員が同時に別々の調査を始めることです。最初の30分で判定フローを固定すると、手戻りが激減します。僕が現場で使う基本形は「実行中バージョン確認→影響範囲照合→更新先決定」の3段階です。

1. 実行バージョン確認 — lockfile基準でnext/react/react-domとRSC関連依存を確認します
2. 影響範囲照合 — GHSAの対象レンジと突き合わせます
3. 運用分岐確定 — 16系本命か、15系緊急対応かを決めます
4. 担当分担 — 更新担当・検証担当・告知担当をその場で固定します

npm ls next react react-dom react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack

この時点で「たぶん大丈夫」は禁止です。 npm lsで実際に解決されたバージョンを見ないと、依存の取りこぼしを見逃しやすいです。

この表をそのまま社内に貼るだけでも、判断が早くなります。抽象論より「いま何を上げるか」が見える状態を作るのが先です。

本番を塞ぐ最短手順：React 19.2.5 / Next.js 16.2.3へ更新

ここはスピード勝負ですが、順番を間違えると逆に遅くなります。おすすめは「更新コマンドを一本化して、検証観点を先に決める」やり方です。 先に検証観点を決める理由は、更新後に「何を確認したら完了か」で揉めないためです。

1. 更新コマンドを実行

# 16系本命ライン
npm install next@16.2.3 react@19.2.5 react-dom@19.2.5

# 15系の最短修正
npm install next@15.5.15 react@19.2.5 react-dom@19.2.5

# RSC関連を強制固定（取りこぼし防止）
npm pkg set overrides.react-server-dom-webpack=19.2.5 overrides.react-server-dom-parcel=19.2.5 overrides.react-server-dom-turbopack=19.2.5

# 更新確認
npm ls next react react-dom react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack

2. 最低限の検証を固定

• Server Function経路 — 実行・失敗・再試行を確認
• App Router主要ページ — SSR/遷移/フォーム送信を確認
• 監視指標 — CPU・レスポンスタイム・関数実行時間を30分追跡

もし社内だけで緊急対応の役割分担が詰まるなら、更新担当・検証担当・告知担当を30分で仮決めして、担当設計だけ先に固めるのが現実的です。止血フェーズは「正しい技術」だけでなく「速い意思決定」が同じくらい重要です。

13.x/14.x・15.x運用の緊急分岐と移行判断

ここがいちばん迷いやすいポイントです。13.x/14.x運用チームは、今回の件で「延命」の難しさがはっきり出ました。公開情報では13.x/14.xはEOL扱いで、修正版が出ない前提で見た方が安全です。結論として、15.5.15へ一度寄せるか、16.2.3へ跳ぶかの二択で考えるのが速いです。

• 13.x/14.x運用 — 段階移行計画を即作成し、短期で15.5.15以上へ移します
• 15.x運用 — まず15.5.15で止血し、次スプリントで16.2.3計画を確定します
• 16.x運用 — 16.2.3へ上げて監視強化、運用ゲートを追加します

1. 今日中 — 影響判定と更新実施
2. 3日以内 — 負荷観測と運用手順の文書化
3. 2週間以内 — EOLラインの撤退計画を経営層まで合意

公式の裏取りとしてはNext.js 16.2.3のリリースノート、運用寄りの整理はNetlifyの解説が読みやすいです。移行方針の説明が必要なら、影響範囲・更新先・検証観点を1枚にまとめてから社内共有すると、調整が進みやすくなります。

WAFは暫定防御、再発防止は運用設計で決まります

VercelはWAFルールを自動適用していますが、同時に「WAF依存は不十分、パッチ適用が必須」と明言しています。ここはすごく大事です。WAFは時間を買う道具であって、脆弱性を消す道具ではないという前提で運用するのが安全です。

• 暫定防御 — WAFルール適用、レート制限、異常IPの短期遮断
• 恒久対策 — React/Next.js更新、依存固定、検証ゲート追加
• 運用定着 — 依存更新SLOを決め、毎週の点検をチーム習慣にする

# 例: CIで最低限チェックする項目
npm ci
npm ls next react react-dom react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack
npm audit --omit=dev

僕はこの運用を「異世界転生の型」だと思っています。つまり、ITの安全策を非IT現場の業務継続に翻訳して届ける形です。障害ゼロを約束するより、障害時の復旧速度を設計しておく方が、現場にとってはめっちゃ助かります。関連記事として、比較→手順型でまとめた運用改善の記事や、再現しやすい型を整理した実践テンプレ記事もあわせて読むと理解がつながりやすいです。

CVE-2026-23869を後回しにしたときの現実

この脆弱性を知らないままだと、可用性だけでなく予算計画まで崩れる可能性があります。 とくにサーバーレス運用では、落ちる前に課金だけ増えることが起きやすいです。攻撃トラフィックを正常アクセスと区別しにくい時間帯ほど、現場の疲弊が加速します。

• 機会損失 — ピーク時間の応答劣化で問い合わせ・申込が減る可能性があります
• コスト損失 — CPU占有で関数実行コストが先に増える可能性があります
• 信用損失 — 「復旧はしたが遅かった」が続くと、社内外の信頼が下がる可能性があります

この記事を書いている理由

僕自身、2025年に結婚式Web招待状サービスを開発して、90日以上ログイン継続率を維持する運用を経験しました。公開サービスは「落ちない設計」より「落ちそうな時に素早く戻せる設計」が現実的だと何度も感じています。福祉事業のIT全般を担当する今も、脆弱性対応は開発者だけの課題ではなく、利用者さんの生活導線を守る仕事だと捉えています。だからこそ、影響判定から更新、運用定着までを一気通貫で言語化して届けたいんです。

次のアクション

今日やることはシンプルです。まずnpm lsで影響判定、次にReact 19.2.5/Next.js 16.2.3（または15.5.15）以上の最新修正版へ更新、そのあと30分監視です。5月以降に対応する場合は、Next.js 16.2.6 / 15.5.18 など最新パッチラインも必ず確認してください。