2025年12月5日08時47分(UTC)(このブログでは時刻はすべてUTCで記載します)を起点に、Cloudflareのネットワークの一部で重大な障害が発生しました。このインシデントは09:12に解決し(影響時間は約25分)、現在はすべてのサービスが完全に復旧しています。
障害範囲は、Cloudflareが処理する全HTTPトラフィックの約28%に相当し、その結果一部のお客様に影響がありましたが、この影響は特定の条件が重なった一部のお客様に対する限定的なものでした。
今回の障害は、直接的にも間接的にもCloudflareのシステムに対するいかなるサイバー攻撃や悪意のある活動によって引き起こされたものではなく、今週公開された「React Server Components」の新たな脆弱性への対応作業の一環として、Cloudflare内部の「ボディ解析(body parsing)」のロジックに変更を加えたことが直接のきっかけでした。
Cloudflareは、11月18日の障害に続き再びインターネットに障害を引き起こしてしまったことを重く受け止めています。今回の件を踏まえ、来週、このようなインシデントの発生を防ぐための当社の取り組みの詳細について発表いたします。
以下のグラフは、インシデント期間中に当社のネットワークが配信したHTTP 500エラー(下の赤い線)と、影響を受けなかったCloudflareの全トラフィック(上部の緑線)を比較したものです。
CloudflareのWebアプリケーションファイアウォール(WAF)は、悪意のあるペイロードを検出・遮断するため、プロキシで分析のためにHTTPのリクエストボディをメモリに読み込みます。従来、このバッファサイズは128KBでした。
今回、重大な脆弱性CVE-2025-55182からReactをご利用のお客様を保護するための継続的な作業の一環としてこのバッファサイズを1MB(Next.jsアプリケーションで許可されるデフォルト制限)へ拡大する変更作業を行っていました。本来の目的は、できるだけ多くのお客様を保護することでした。
この最初の変更は、段階的展開方式を用いたロールアウトを実施しましたが、ロールアウト中に、社内用WAFテストツールが増加したバッファサイズに対応していないことが判明しました。しかし、この時点でこの社内用テストツールは必要ではなくお客様のトラフィックに影響を与えていないことから、2回目の変更としてツールを無効化しました。
2回目の変更として行ったWAFテストツールの無効化は、当社のグローバル設定システムを使用して実施されました。このシステムは変更を段階的に展開するのではなく、数秒で全ネットワークに反映させます(11月18日の障害後、見直しを行っています)。
残念ながら、この2回目のWAFテストツールを無効化するといった作業により、当社のバージョンのFL1プロキシを使用する特定の状況下において、ネットワークから500 HTTPエラーコードが返されるという事態が発生しました。
これは、変更が当社のネットワークに反映された直後、FL1プロキシ内で動作するルールモジュールのバグが誘発され、以下のLua例外が発生する結果となりました:
[lua] Failed to run module rulesets callback late_routing: /usr/local/nginx-fl/lua/modules/init.lua:314: attempt to index field 'execute' (a nil value)
これにより、HTTPコード500エラーが返されました。
この問題は変更適用直後に特定され、09:12にロールバックを行ったところ、すべてのトラフィックが平常通り配信されるようになりました。
今回の影響範囲は、Web配信に古いFL1プロキシを利用し、かつCloudflareのマネージドルールセットがデプロイされているお客様が対象でした。この条件に該当するWebサイトに対するすべてのリクエストは、/cdn-cgi/traceなどの一部のテストエンドポイントを除き、HTTP 500エラーが返される状態となりました。
裏を返せば、上記に当てはまらないお客様に対する影響はありませんでした。当社のチャイナネットワークを経由する顧客トラフィックも影響を受けませんでした。
Cloudflareは、システムに入る各リクエストを複数のルールをまとめた「ルールセット」を使用して評価しています。ルールはそれぞれ、フィルター(トラフィックを選別)と、アクション(トラフィックを処理)で構成されます。一般的なアクションは、「block」、「log」、「skip」ですが、「execute」というアクションもあり、これは別のルールセットの評価をトリガーするために使用されます。
Cloudflareの内部ログシステムはこの機能を使用して、公開前の新しいルールを評価しています。上位のルールセットが、テスト用のルールを含む別のルールセットを実行する仕組みになっており、今回私たちが無効化しようとしていたのは、そのテスト用のルールでした。
ルールセットシステムには、問題のあるルールをすぐに無効化できるようにする「キルスイッチ」サブシステムがあります。このキルスイッチシステムは、前のセクションで説明した「グローバル構成システム」から情報を受け取ります。私たちはこれまでにもインシデント対応のため、このキルスイッチを何度か使用しており、明確に定められた標準手順(SOP)に従って運用しています。今回のインシデントでも同じ手順に沿った対応を実施しました。
しかし、私たちはこれまで「execute」アクションを持つルールに対してキルスイッチを適用したことがありませんでした。キルスイッチが適用された場合、コードは「execute」の評価を正しくスキップしたことで、そのアクションが参照していたサブルールセットも評価しませんでした。ところが、ルールセット全体の評価結果を処理する際にエラーが発生してしまいました。
if rule_result.action == "execute" then
rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)]
end
コードは「execute」アクションがある場合、「rule_result.execute」というオブジェクトが必ず存在するという前提で動いていました。しかし今回は「execute」がスキップされたため、rule_result.executeオブジェクトが存在せず、Luaはnil値を検索しようとした結果、エラーを返しました。
これはコードに長年気付かれないまま潜在していた単純なバグでした。この種のコードエラーは、強力な型システムを持つ言語であれば防ぐことができ、実際Rustで記述された新しいFL2プロキシに置き換えたところ、エラーは発生しませんでした。
2025年11月18日のインシデント発生後に進めていた改善について
2025年11月18日に発生した別の障害で、同様の長時間にわたり利用できなくなるといったインシデントを経験しています。この2つの障害に共通しているのは、セキュリティ対策のための設定変更が当社のネットワーク全体に反映され、一気に影響が拡散した点です。
11月18日のインシデントの後、私たちは多くのお客様から直接話を聞き、同様の問題を防ぐための計画を共有してきました。現在進めているこの改善が完了していれば今回のインシデントを抑えられた可能性が高いと考えられますが、残念ながら、まだ展開が完了していません。
Cloudflareはこの遅れを重く受け止め、この改善策を企業一丸となり、引き続き「最優先事項」として取り組みます。特に、以下に概説するプロジェクトは、この種の変更の影響を抑制できるものです:
ロールアウトとバージョン管理の強化:厳密なヘルスチェックを行いながら段階的にソフトウェアを展開するのと同様に、迅速な脅威対応や各種設定に使われるデータにも、同じ安全性と影響範囲を抑える仕組みが必要です。これには、ヘルスチェックや迅速なロールバック機能などが含まれます。
緊急時対応機能の合理化:追加の種類の障害が発生しても、重要な操作が確実に実行できるようにすることが必要です。これは、社内のサービスだけでなく、すべてのCloudflareユーザーが利用するCloudflareのコントロールプレーンとの標準的な操作方法にも当てはまります。
フェイルオープン方式のエラーハンドリング:耐障害性向上の取り組みの一環として、すべての重要なCloudflareデータプレーンコンポーネントにおいて、誤って適用されていたハードフェイル(即時停止)ロジックの置き換えを行っています。設定ファイルが破損しているか、範囲外である場合(例:機能上限を超えている場合)、リクエストを落とすのではなく、エラーを記録し、安全が確認された既定状態に戻すか、スコアリングせずにトラフィックを通過させます。一部のサービスでは、状況に応じてお客様がフェイルオープン(問題があっても通す)またはフェイルクローズ(問題があったら止める)かを選択できるようにする予定です。さらに設定のずれを防止する仕組み(drift prevention)も導入する予定です
来週末までに、今回紹介した内容を含む全ての耐障害性プロジェクトの詳細を公開する予定です。その間、Cloudflareは、復旧とロールバックの仕組みが強化されるまで、新しい変更をネットワークに適用しない方針を固めています。
今回のように、短期間に大規模障害が連続して起きてしまうようなことは決して許されるものではありません。Cloudflareのチームを代表し、今回の件でお客様、そしてインターネット全体に与えた影響について、改めて深くお詫び申し上げます。
時間 (UTC) | ステータス | 説明 |
08:47 | 障害発生 | 設定変更がネットワークに適用され、配信が始まる |
08:48 | 影響が最大に | 設定変更がネットワーク全体に行き渡る |
08:50 | 障害として正式に認識 | 自動アラート |
09:11 | 変更を元に戻す | 構成変更を元に戻し、再配信を開始 |
09:12 | 復旧 | 変更の取り消しが全ネットワークに反映され、すべてのトラフィックが正常に復旧 |