Cloudflareのグローバルインフラストラクチャは、1か月足らずの間に2度目となる大規模障害に見舞われた――そして、その原因は攻撃ではなく、広く利用されているJavaScriptライブラリReactに存在する重大な欠陥、React2Shell(CVE-2025-55182)と名付けられた脆弱性に対して、慌ただしくパッチを適用しようとしたことにあったことが明らかになった。
東部時間12月5日早朝、同社のネットワークの一部は事実上「暗転」した。Cloudflareのノードを通過するHTTPトラフィックのおよそ4分の1がエラーを返し始めたのである。インシデントのピーク時には、処理された全リクエストの約28%が利用不能となり、CloudflareのCDN、Webファイアウォール、セキュリティレイヤーに依存する何百万ものユーザーやオンラインサービスが、突如として切り離された。障害は30分未満で収束したものの、Cloudflareに全面的に依存しているWebサイトにとっては、オーディエンスから完全に孤立することを意味した。
CloudflareのCTOであるDane Knechtは、その後の事後分析の中で、侵害も外部からの干渉も一切なかったと強調した。彼の説明によれば、この障害は、新たに公開されたReact Server Componentsの重大な脆弱性を検知・遮断するため、HTTP処理ロジックに対してバイトレベルの変更を慌ただしくデプロイしたことが引き金となった。React2Shellに対する防御機能を急いで組み込もうとした結果、旧式のソフトウェアスタックを実行していた一部のプロキシ群がエラーでクラッシュし、クライアントに500ステータスコードを返す事態となったのである。
同社をここまで切迫した高速アップデートに追い込んだリスクは、数日間にわたり業界の議論を席巻している。React2ShellはCVSSスコア10.0(最大値)の逆シリアル化脆弱性であり、攻撃者にとって極めて魅力的だ。認証は不要で、複雑な準備もいらない。脆弱なサービスに対して細工されたリクエストを1回送るだけで、リモートコード実行が可能になる。影響を受けるのはReactベースのプロジェクトだけではなく、その周辺エコシステム全体――Next.jsや各種の人気ビルドツールも同様に危険にさらされている。
脆弱性の公開後、規制当局や大手クラウドプロバイダは、悪意ある活動の増加を相次いで報告した。英国当局は、この欠陥がすでに積極的に悪用されていると正式に警告し、米国のCISAはCVE-2025-55182を既知の悪用脆弱性カタログに即座に追加し、管理者に対してパッチ適用の遅延はもはや許されないとシグナルを送った。Amazonも別の通達で、中国国家機関と関係するグループが最初の公開から数時間以内に悪用を試み始めたと指摘している。その中には、業界の脅威レポートでおなじみのEarth LamiaやJackpot Pandaといったグループも含まれていた。
進行中の状況の規模は、スレットハンティングの観測結果からも推し量ることができる。Palo Alto NetworksのUnit 42は、脆弱なインスタンスを探すインターネット全域へのスキャン、実験的なリモート実行チェーン、クラウド構成ファイルやAWSアクセスキーの窃取試行、C2サーバーからペイロードを取得するローダーの展開などを報告している。Bitdefenderのアナリストは、ランサムウェアオペレーターや初期侵入ブローカーが急速に参戦し、実用的なエクスプロイトが一般公開され次第、企業ネットワーク内部に足場を築こうと競争を繰り広げるだろうと予測している。
攻撃ツールそのものも、オンライン上で異常なスピードで増殖している。この欠陥を発見しReactチームに報告した研究者Lachlan Davidsonは、公開から約30時間後には、すでに動作するエクスプロイトのプロトタイプが出回り始めていたと述べている。彼自身も後に独自のバリアントを公開し、攻撃メカニズムの詳細な技術解説を約束した。maple3142として知られる研究者は、別の動作するプロトタイプをGitHubにアップロードし、Ox Securityのアナリストは、そのコードが実際に脆弱な構成に対してリモート実行を可能にすることを確認した――インターネットにこうしたサービスを公開している組織にとって、即時対応が必要であることを意味する。
その一方で、React2Shellをめぐっては、ノイズに満ちた偽の「サンプル」が乱立している。公開された欠陥とはまったく無関係なメカニズムに依存しながら、エクスプロイトを名乗るプロジェクトが多数オンラインに現れているのだ。Davidsonは、多くの疑似POCがvm.runInThisContext、child_process.exec、fs.writeFileといった危険な関数を呼び出していると警告する。こうした機能は、本来であれば、開発者が自らの設計ミスによってクライアント側に露出させていない限り、攻撃者が利用できるものではない。これら誤解を招くプロジェクトは、防御側を混乱させるとともに、「脆弱性はすでに徹底的に研究され尽くした」という誤った印象を与えてしまう。実際には、組織は依然として信頼できる検知手法を欠いたままであるにもかかわらず。
Cloudflareの障害に話を戻すと、この一件は、大手プレイヤーがこの軍拡競争をいかに苦痛を伴いながら経験しているかを如実に示している。前回11月のインシデント――CEOが2019年以来最悪と評し、やはり設定ミスが原因だった――の後、同社は構成管理アーキテクチャの大幅な刷新を約束していた。今回の新たな障害は、その再設計がまだ完了していないことを物語っている。今回、チームはReact2Shellの悪用に特徴的な、異常に大きな悪意あるリクエストを捕捉するため、HTTPバッファサイズを128KBから1MBへ引き上げようとした。当初、デプロイは問題なく進んでいたが、Cloudflareが拡張されたバッファと互換性のない社内Webファイアウォールテストツールを無効化した際、グローバルな構成配布システムが変更されたパラメータを数秒以内にエッジ全体へ伝播させてしまった。
その結果、レガシーなFL1プロキシのロジック深部に潜んでいた欠陥が一気に表面化した。リクエスト処理中にLuaスクリプトエラーが発生し、影響を受けたノードを通過するトラフィックがすべて500レスポンスで失敗する事態となったのである。このプロキシクラスとマネージドWAFルールセットを併用していた顧客が最も大きな打撃を受け、ネットワーク全体のエラー率を目立って押し上げるには十分な規模だった。注目すべき点として、Cloudflareの中国インフラセグメントは影響を受けなかった。エンジニアは問題の変更を迅速に切り離し、東部時間午前4時11分にロールバックを実施、1分以内に通常のトラフィックフローを回復させた――もっとも、短期間に2度の大規模障害が発生したことによる評判への影響は、今後も尾を引くだろう。
今後に向けて、Cloudflareは複数の取り組みを加速させると約束している。構成データのより慎重なデプロイとバージョン管理、連鎖的な障害が発生している最中でもインフラを管理できる危機対応能力の強化、そして不正な構成ファイルが致命的な障害を引き起こすのではなく、安全な設定にフォールバックする「フェイルオープン」モデルの導入である。当面、同社は重要度の低い変更をすべて凍結し、短期間に重大インシデントを再発させてしまったことについて、顧客およびインターネットコミュニティ全体に改めて謝罪している。
Radwareの脅威リサーチ担当バイスプレジデントであるPascal Geenensは、オープンソースソフトウェアを扱う場合、巧妙な敵対者は詳細な公開情報がなくともコード変更を精査し、攻撃ロジックを再構築できてしまうと指摘する。一方で、多くの防御側は不完全または誤ったレポートに頼らざるを得ず、最終的には機能しない緩和策を展開してしまう。「これは競争だ」とGeenensは述べる。「防御側にもっと多くのプレイヤーがいて、最初から完全かつ正確な情報を受け取ることができれば、勝てる可能性ははるかに高くなるだろう。」
Webスタックの中核コンポーネントにおける重大な脆弱性の急速な拡散、国家と連携するグループによる実際の悪用、そしてCloudflareのような大規模インフラプロバイダによる神経質で反応的な対応――これらが重なり合うことで、私たちが当然視してきたインターネットという織物が、いかに脆いものであるかが浮き彫りになっている。そして、防御チームが緊急パッチを適用するために自らのシステムを拙速に壊さざるを得ない状況が頻発するほど、オープンソースの世界は、デジタルエコシステムの土台に新たな亀裂が生じたとき、それをどのように伝達すべきかを、より慎重に再考する必要に迫られるだろう。