2025年12月5日、世界のインターネットインフラは再び呼吸を止めた。

11月に発生した大規模障害の記憶も冷めやらぬ中、コンテンツデリバリネットワーク(CDN)およびセキュリティの巨人であるCloudflareが再び広範囲にわたるサービス停止を引き起こしたのだ。多くのユーザーが画面上で目にしたのは、無機質な「500 Internal Server Error」の文字だった。

しかし、今回の障害はその性質において、過去の事例とは決定的に異なる「皮肉」を含んでいる。原因は、サイバー攻撃でもなければ、単なるハードウェアの故障でもない。それは、現在進行形で世界中のサーバーを脅かしている最悪レベルの脆弱性「React2Shell」から顧客を守ろうとした、Cloudflare自身の「盾」が暴発した結果だったからだ。

本稿では、わずか25分間で世界中のWebトラフィックの約3割を機能不全に陥らせたこのインシデントの全貌を、技術的背景、セキュリティのジレンマ、そしてインターネットインフラが抱える構造的リスクの観点から見ていきたい。

AD

インシデントの解剖:25分間の「デジタルブラックアウト」

突然の沈黙と「500エラー」の嵐

世界協定時(UTC)2025年12月5日午前8時47分頃(日本時間同日午後5時47分頃)、インターネット上の主要なサービスが一斉に接続不能となった。

影響を受けたのは、Cloudflareのインフラを利用している無数のWebサイトやアプリケーションだ。具体的には以下のような事象が確認された。

  • 広範囲なサービス停止: Coinbase(暗号資産取引所)、Shopify(Eコマース)、Canva(デザインツール)、さらにはClaude AI(Anthropic社)といった高トラフィックなプラットフォームがアクセス不能となった。
  • 管理機能の喪失: Cloudflare自体のダッシュボードやAPIも機能を停止し、エンジニアたちが状況を確認したり、設定を変更したりすることさえ困難な状況に陥った。
  • エラーの連鎖: ユーザーのブラウザには「500 Internal Server Error」が表示され、障害状況を追跡するサイト「Downdetector」さえも一時的にアクセス過多とCloudflare依存により不安定になった。

影響の規模:世界のHTTPトラフィックの28%

CloudflareのCTOであるDane Knecht氏による事後報告によれば、この障害によってCloudflareが処理する全HTTPトラフィックの約28%が影響を受けたという。これは単なる一部のサーバーダウンではない。インターネットという巨大な動脈の約3分の1が、一時的に血流を止めたに等しい。

障害は約25分後の午前9時13分頃(UTC)(日本時間同日午後6時13分頃)には解消されたが、現代のデジタル経済において、この「空白の25分」がもたらした損失と混乱は計り知れない。

原因の深層:「React2Shell」との戦い

今回の障害を理解するための鍵は、Cloudflareが何と戦っていたのかを知ることにある。その敵の名は「React2Shell」(CVE-2025-55182)だ。

CVSSスコア10.0の悪夢

障害発生の直前、セキュリティ業界は戦慄していた。世界で最も普及しているJavaScriptライブラリの一つである「React」、そしてそれを基盤とする「Next.js」などのフレームワークに、致命的な脆弱性が発見されたからだ。

  • 脆弱性ID: CVE-2025-55182
  • 通称: React2Shell
  • 深刻度: CVSSスコア 10.0(最大値)
  • 影響範囲: React 19.0〜19.2.0、およびNext.js等の依存フレームワーク

この脆弱性は、React Server Components (RSC) における「Flight」プロトコルの非安全なデシリアライズ処理に起因する。攻撃者は認証を必要とせず、細工したHTTPリクエストを送信するだけで、サーバー上で任意のコードを実行(RCE: Remote Code Execution)できるという、極めて危険度の高いものだ。

迫りくる「国家レベル」の脅威

単に脆弱性が見つかっただけではない。Amazon Web Services (AWS) のセキュリティ研究チームや各国のサイバーセキュリティ機関(CISA等)は、この脆弱性が既に悪用されていることを確認していた。

特に、中国に関連するとされるハッキンググループ「Earth Lamia」や「Jackpot Panda」が、脆弱性の公表から数時間以内にはスキャンと攻撃を開始していたことが報告されている。概念実証(PoC)コードも出回っており、攻撃は時間との戦いとなっていた。

Cloudflareの決断と誤算

この緊急事態に対し、Cloudflareは正しい行動をとろうとした。顧客のサーバーがパッチ未適用の状態であっても、Cloudflareのエッジ(WAF: Web Application Firewall)で攻撃を食い止めるための「緊急ルール」を展開しようとしたのだ。

しかし、ここで悲劇が起きた。

Dane Knecht氏の説明によれば、「React Server Componentsの脆弱性を検知・緩和するために、ボディ解析ロジック(body parsing logic)に変更を加えた際、それがトリガーとなった」という。つまり、悪意あるリクエストを解析しようとするプロセスそのものが、正常なリクエスト処理をも巻き込んで破綻し、システム全体が過負荷あるいはエラー状態に陥ったのである。

これはサイバー攻撃によるダウンではない。「攻撃を防ぐための盾」が重すぎて、支える兵士(サーバー)が倒れてしまったようなものだ。

AD

「11月の悪夢」再び:繰り返される脆弱性

今回のインシデントがユーザーの不信感を招いている背景には、わずか数週間前の「前科」がある。

11月18日の大規模障害との関連

2025年11月18日、Cloudflareはデータベースの権限設定ミスに起因する大規模な障害を起こしている。CEOのMatthew Prince氏が「2019年以来最悪の障害」と評したこの事件では、ボット管理システムに関連するデータベース更新が原因で、世界中のネットワークが数時間にわたり麻痺した。

構造的なリスクの露呈

短期間に二度の大規模障害が発生したことは、以下の構造的なリスクを浮き彫りにしている。

  1. 単一障害点(SPOF)としての巨大CDN: 世界のウェブサイトの約20%以上がCloudflareに依存していると言われる。彼らがくしゃみをすれば、インターネット全体が風邪をひく構造が、極めて鮮明に可視化された。
  2. スピードと安定性のトレードオフ: React2Shellのような「今すぐ塞がなければ死ぬ」レベルの脆弱性に対し、十分な検証時間を確保することは難しい。Cloudflareはスピードを選んだが、その代償として安定性を失った。これは、セキュリティベンダーが常に直面する究極のジレンマである。

なぜWAFの変更が全断を招いたのか

ここで技術的な視点から、なぜ「WAFのルール追加」程度の変更がこれほど甚大な被害をもたらしたのかを推察する。

「ボディ解析」の落とし穴

React2Shell脆弱性を突く攻撃は、HTTPリクエストのボディ部分に含まれる特殊なシリアライズデータに隠されている。これを検知するには、WAFが流れてくるパケットの中身(ボディ)を深く検査(Deep Packet Inspection)し、特定のパターンを解析する必要がある。

通常、WAFのルールはヘッダー情報や単純なシグネチャのマッチングで済むことが多い。しかし、今回の変更は「ボディ解析ロジックの変更」であった。これは推測の域を出ないが、以下の可能性が考えられる。

  • リソース消費の増大: 全てのHTTPリクエストに対して重い解析ロジックが適用され、CPUやメモリリソースが枯渇した。
  • 例外処理の不備: 特定の形式のデータ(あるいは正常なデータ)に対し、新しいパーサが予期せぬエラー(例外)を吐き、プロセス自体がクラッシュした。
  • 再帰的なエラー: エラー発生時の処理がさらにシステムに負荷をかけ、連鎖的な障害(Thundering Herd問題に近い状態)を引き起こした。

Cloudflareのような分散システムにおいて、小さなロジックの変更がバタフライエフェクトのように全体へ波及する恐ろしさが、ここにある。

AD

今後の展望と企業が取るべき対策

「React2Shell」への対応は終わっていない

Cloudflareの障害は復旧したが、React2Shellの脅威自体は去っていないことに注意が必要だ。Cloudflareは修正した緩和策を適用済みとしているが、根本的な解決はアプリケーション側でのパッチ適用にある。

React 19系、Next.jsを使用している企業・開発者は、直ちに以下の対応を取る必要がある。

  • React: バージョン19.0.0〜19.2.0を使用している場合、修正版へのアップデート。
  • Next.js: 最新のパッチバージョンの適用。
  • 監視: Cloudflare等のWAFを過信せず、サーバーログでの不審なアクティビティ(特に中国関連のIPからのアクセスや、異常なペイロードを含むリクエスト)の監視。

マルチCDN・マルチクラウドの再考

今回の件は、単一のベンダーにインフラの全てを委ねることのリスクを再認識させた。「Cloudflareが落ちたらどうするか?」という問いに対し、BCP(事業継続計画)の観点から真剣に向き合う必要がある。
コストはかかるが、DNSのフェイルオーバー設定や、複数のCDNを併用するマルチCDN構成が、ミッションクリティカルなサービスには不可欠な要件となっていくだろう。

インターネットの「脆さ」と「強靭さ」の狭間で

2025年12月5日のCloudflare障害は、皮肉なことに、インターネットを守るための戦いが、時にインターネットそのものを傷つけてしまうという現実を突きつけた。

React2Shellという凶悪な脆弱性に対し、Cloudflareが即座に対応しようとした姿勢自体は非難されるべきではない。しかし、その「盾」が巨大化しすぎた今、その運用にはかつてないほどの慎重さと、失敗した際の影響を最小限に留める設計(Fail-safe)が求められている。

私たちは、デジタルの利便性を享受すると同時に、それが薄氷の上に成り立っていることを忘れてはならない。次に画面が「500エラー」で埋め尽くされたとき、それが単なる設定ミスなのか、それとも防ぎきれなかったサイバー攻撃の結果なのか、その違いを見極めるリテラシーが私たちには求められている。


Sources