2025年12月5日早朝（世界各地の現地時間）に発生したCloudflare（クラウドフレア）の大規模障害。ZoomやLinkedIn、Coinbase、Canva、Shopifyなど、仕事でもプライベートでもよく使うサービスが一気に「500 Internal Server Error」で落ちて、「え、またインターネット壊れた？」と感じた人も多かったと思います。(AP News)

この障害についてCloudflareが正式に、「原因はReactの重大な脆弱性『React2Shell（CVE-2025-55182）』への緊急対策だった」と説明しました。つまりサイバー攻撃で落とされたのではなく、自分たちの防御アップデートが自分たちの首をしめた格好です。(BleepingComputer)

この記事では、
今回の障害がいつ・どこで・どれくらい起きたのか、
React2Shellとは何なのか、
Cloudflare側のミスはどこにあったのか、
そして、開発者・インフラ担当・一般ユーザーがそれぞれ何を確認しておくべきか
を、できるだけ専門用語をかみ砕きながら整理していきます。

この話題は、Cloudflareを使っているWebサイトの運営者やエンジニアはもちろん、「朝起きたらサービスが全部落ちていて仕事にならなかった…」というユーザーにとっても、今後の備えとして無視できない内容です。

今回のCloudflare障害で実際に何が起きていたのか

2025年12月5日に起きたCloudflare障害は、世界のHTTPトラフィックのおよそ28％が一時的に止まるレベルの大規模なものだったと報告されています。(BleepingComputer)

発生日時は、Cloudflareの公式説明や各社報道を総合すると「2025年12月5日 08:47〜09:13（UTC付近）」の短い時間帯で、実際には20〜30分ほどの停止です。ただ、その短時間に非常に多くのサービスが一斉に巻き込まれたため、体感としては「半分のインターネットが落ちた」と感じた人も少なくありませんでした。(Reuters)

影響が出たサービスとして名前が挙がっているのは、Zoom、LinkedIn、Coinbase、DoorDash、Canva、Shopify、Discord、Substackなど、日常的に使われる大手サービスがずらっと並びます。障害監視サイトのDowndetector（ダウンディテクター）自体も巻き込まれており、「何が起きているのか調べるサイトも落ちている」という、なかなかシュールな状況になっていました。(SecurityWeek)

画面上では、多くのユーザーが「500 Internal Server Error」というエラーコードを目にしたはずです。これはサーバー側の内部エラーを示すHTTPステータスコードで、ブラウザやOSではなく、インターネットのどこか（今回はCloudflare側）で処理が壊れているサインです。

発生日時・公式ステータス・対象ユーザー層を整理

今回の障害は「2025年12月5日発生・同日中に復旧済み」であり、記事執筆時点（2025年12月6日公開）ではCloudflareネットワークは正常運用に戻っています。(Reuters)

Cloudflareのステータスページや各メディアによると、障害は12月5日の朝に発生し、およそ25分間続いたあとに修正がロールアウトされ、Cloudflare DashboardやAPIも含めて順次復旧しました。

対象となったユーザー層はかなり広く、CloudflareのCDN（コンテンツ配信ネットワーク）、WAF（Web Application Firewall）、リバースプロキシなどを利用しているサイトの閲覧者全員がポテンシャルな影響範囲に入ります。つまり「Cloudflareと契約している企業」だけではなく、そのサイトを見ていた一般ユーザーも含め、インターネット利用者の相当な割合が間接的な被害者という形です。

企業側として特に影響が大きかったのは、
決済やログインをCloudflare経由のフロントエンドに置いているSaaSやEC、
常時接続が前提のオンライン会議ツールなど、
「数分でも止まるとビジネス的ダメージが出る」タイプのサービスです。

一方で、個人ブログや静的サイトでもCloudflareをフロントに置いているところは多く、ユーザーによっては「お気に入りのサイトが軒並み落ちていた」という印象が残ったかもしれません。

React2Shell（CVE-2025-55182）とは何者か

React2ShellことCVE-2025-55182は、React Server Components（RSC）の“Flight”プロトコルに存在する最大深刻度のリモートコード実行（RCE）脆弱性です。(BleepingComputer)

この脆弱性は、React 19系の一部バージョン（19.0、19.1.0、19.1.1、19.2.0）と、それに依存したNext.jsやReact Router、Waku、@parcel/rsc、@vitejs/plugin-rsc、RedwoodSDKなどのフレームワークにも影響します。攻撃者は、認証なしに細工したHTTPリクエストをReact Server Functionsのエンドポイントに送ることで、サーバー上で任意コードを実行できる可能性があります。(BleepingComputer)

要するに、「Reactベースのサーバーサイドアプリに向けて特定のリクエストを投げるだけで、サーバーを乗っ取れるかもしれない」というかなりエグい種類のバグです。CVSSスコアも最大の10.0と評価されており、業界的にも“最優先で塞がなければならない穴”という扱いになっています。(SC Media)

しかも、この脆弱性は公表からわずか数時間で、中国系とみられる複数の攻撃グループ（Earth LamiaやJackpot Pandaなど）が実際に悪用を始めたとAWSの研究チームが報告しています。英国のNHS England National CSOCも、既に複数の実用的なPoC（Proof of Concept）コードが出回っており、今後も継続的な悪用が高い確率で続くだろうと警鐘を鳴らしています。(BleepingComputer)

この“リアルタイムで悪用が始まっている”という状況が、Cloudflareを含む各社に「今すぐ防御ルールを入れないとまずい」という強いプレッシャーを与えました。

Cloudflareが「自爆」した技術的ポイント──WAFのボディ解析ロジック

Cloudflareは今回の障害について、『React Server Componentsの脆弱性を検出・緩和するためにWAFのリクエストボディ解析ロジックを変更したところ、それが原因でネットワークの一部が利用できなくなった』と公式に説明しています。(BleepingComputer)

もう少し分解してみます。

React2Shellを狙う攻撃はHTTPリクエストの形に特徴があるため、CloudflareとしてはWAFのルールで「怪しい形のリクエストを検知・ブロックしたい」と考えます。そのためには、HTTPのボディ部分や特定ヘッダーをより細かく解析する必要があり、ここで“body parsing logic（ボディ解析ロジック）”の変更が入ったとされています。

ところが、その変更が一部の環境と相性が悪く、Cloudflare内部でエラーを誘発してしまい、結果として多くのユーザーにHTTP 500エラーが返される形になってしまいました。障害報告によれば、影響を受けたのはCloudflareが捌く全HTTPトラフィックの約28％に相当するサブセットで、Cloudflare CTOのDane Knechtは「サイバー攻撃ではなく、あくまで自社の変更が引き金だった」と強調しています。(BleepingComputer)

セキュリティ系メディアの中には、「高度な脆弱性を前に、Cloudflareは数十分の自社ダウンを許容してでも今すぐ塞ぎにいくというリスク計算をした」と分析しているところもあります。つまり、単なる設定ミスというより、「攻撃を食らうリスク」と「短い障害を起こすリスク」を天秤にかけて、後者を選んだという見方です。(SC Media)

もちろん、結果としてはユーザーからすると「またCloudflareのせいで落ちた」となるので、評価が厳しくなるのは避けられません。ここが運用とセキュリティの難しいところですね。

公式対応状況：復旧済みだが、2度目の大障害としての重さ

Cloudflareは障害発生後30分以内に修正を展開し、当該のWAF変更をロールバックした上で、非緊急の変更を凍結するなどの対策を取ったと説明しています。(SecurityWeek)

今回のインシデントで重要なのは、「これがここ2〜3週間で2回目の大規模障害である」という点です。ひとつ前の障害は11月中旬に発生し、数時間にわたってCloudflare Global Networkの大部分が影響を受けました。このときはボットトラフィックのブロック用データベース更新が原因で、内部的な“疑似DDoS”的状態を引き起こしたと説明されています。(bankinfosecurity.asia)

CloudflareのCEO Matthew Princeは、その11月の障害を「2019年以来最悪の障害」と表現しており、今回の12月の障害についてもCTOが「再びインターネットを失望させてしまった」と謝罪しています。(Cybernews)

公式ブログや発表を見る限り、現時点でのステータスは次のように整理できます。

(1) React2Shellに対するWAF側の緩和策は継続しつつ、問題を起こしたボディ解析の変更は修正またはロールバック済み
(2) 影響を受けたトラフィック約28％は既に正常状態に戻っている
(3) 今後しばらく、Cloudflare内部では“非本質的な変更”を一時停止し、変更プロセスの見直しを行う

ユーザー側としては、「今この瞬間も障害が続いている」という状況ではないものの、「また似たようなインシデントが起きないか」という不安は残る、そんな微妙な心理状態になっているはずです。

開発者・運用担当が今すぐやっておきたいチェックリスト

ReactやNext.jsを使っている開発者・サイト運用者は、『Cloudflareを信じて終わり』ではなく、自分のアプリ側のReact2Shell対策も必ず進める必要があります。(BleepingComputer)

とくに、React Server ComponentsやNext.jsのApp Routerを使ったサーバーコンポーネント構成を採用している場合は、“自分のアプリがCVE-2025-55182に該当するかどうか”を真っ先に確認したいところです。

ざっくりした流れは次のようなイメージになります。

(1) 自分のプロジェクトで使っているReactのバージョン、Next.jsや関連ライブラリのバージョンを全部洗い出す
(2) Reactの公式アドバイザリやフレームワーク側のセキュリティ情報を確認し、CVE-2025-55182に該当していないかチェックする
(3) 該当している場合は、推奨されている安全なバージョンへアップデートする
(4) どうしても即アップデートできない場合は、WAFやリバースプロキシ側で提供されているReact2Shell向けのルールを確認し、テスト環境で十分に検証したうえで有効化する
(5) 変更後は、エラー率やレスポンスコード分布（特にHTTP 500や403）をモニタリングし、今回のような“防御ルール由来の障害”が起きていないかを確認する

Cloudflare以外にも、AWS、Google Cloud、各種WAFベンダーがReact2Shell向けのシグネチャやルールセットを急遽用意している状況です。とはいえ、それらも“完璧”ではなく、誤検知やパフォーマンス劣化を引き起こす可能性があります。最終的な安全性の担保は、自分のアプリとインフラの両方を理解している自分たちのチームにしかできません。

一般ユーザー視点：障害に巻き込まれたとき、どう立ち回ればよかった？

エンドユーザー側には直接できることは多くありませんが、「自分の回線やPCの問題なのか」「インターネット全体の問題なのか」を切り分けるクセをつけておくと、無駄な復旧作業を減らせます。

Cloudflare障害のとき、多くの人がまずやったのは「Wi-Fiを切り替える」「PCを再起動する」「ブラウザを変える」といったローカルな対処だったと思います。もちろん、それ自体は悪いことではありませんが、今回のような“インフラ側の大事故”の場合、どれだけ再起動しても治りません。

実務的には、次のようなステップで切り分けると動きやすくなります。

(1) 1つのサイトだけ落ちているのか、複数のサービスが同時におかしいのかを確認する
(2) 別のデバイス（スマホなど）や別回線（モバイル回線など）でも同じサイトが落ちているかを試す
(3) それでもダメなら、X（旧Twitter）や障害情報サイトで「Cloudflare」「サービス名＋障害」などを検索する
(4) グローバルな障害だと判明したら、むやみに自分側の設定をいじらず、状況が落ち着くのを待つ

今回もX上では、「また半分のインターネットが死んでる」「LinkedInもZoomも落ちてるんだけど」といった投稿が一気に増え、「これは自分の家の問題じゃなさそうだ」と判断できた人も多かったはずです。(スコットランドサン)

2週間で2回のCloudflare大障害が意味するもの

短期間で大規模障害が続いていることは、『インターネットが少数の巨大インフラに過度に依存している』という構造的なリスクを改めて浮き彫りにしました。(ガーディアン)

クラウドサービスやCDN、WAF、DNSなどの“基盤”がどんどん集中している現在、1社の設定ミスや不具合が世界中の企業やユーザーに波及するケースが増えています。今回のCloudflare、少し前のAWSのDNS障害、さらにその前のCrowdStrikeの更新ミスでWindowsマシンが大量にブルースクリーンになった件など、例を挙げればきりがありません。(Reuters)

インフラ設計の観点では、次のような問いかけがますます重要になっていきます。

・自社サービスは、特定のCDNやWAFに100％依存していないか
・マルチクラウド、マルチCDN構成を取るコストと、こうした障害によるビジネス損失のどちらが大きいのか
・本番環境への“緊急変更”が必要になったときのルールやガードレールは十分か

もちろん、言うは易く行うは難しで、マルチ構成にすればするほど設計や運用コストは一気に跳ね上がります。それでも、「全部一社に預けるのは、もう危険すぎるのでは？」という議論が盛り上がるのは、ある意味自然な流れでしょう。

みんなの環境ではどうだった？コメント欄で共有してほしいこと

今回のCloudflare障害は、“React2Shellという危険な脆弱性”と“それを急いで塞ごうとした結果の自爆”がセットになった、教訓だらけのインシデントでした。

ここまで読んでくださった方の中には、実際に仕事で影響を受けた人、React / Next.jsのアプリを運用していてヒヤッとした人、あるいは単に「なんか朝ネットが変だったな」と感じただけの人まで、いろんな立場の方がいるはずです。

ぜひ、コメント欄で次のようなことを共有してもらえると、このテーマについての“みんなの実体験データベース”が厚くなっていきます。

・12月5日の朝、どんなサービスが落ちているのを目撃しましたか？
・自社や自分のプロジェクトでは、React2Shellに関する対策をもう始めていますか？
・Cloudflareのような巨大インフラの「緊急アップデートによる自爆」をどう評価しますか？
・マルチクラウドやマルチCDNへの移行を、今回の件をきっかけに考え始めましたか？

ちょっとした愚痴でも、技術的な深掘りでもOKです。「うちはこういう構成にしていたおかげで助かった」「がっつり巻き込まれてしまったので、こう変えようと思う」といった具体的な話は、同じような悩みを抱えている人たちの大きなヒントになります。

あなたの視点や体験が、この“React2Shell騒動＋Cloudflare障害”をどう理解するかのヒントになっていくはずなので、遠慮なく書き込んでいってください。