CloudflareのWebアプリケーションファイアウォール（WAF）に存在した重大なゼロデイ脆弱性により、攻撃者がセキュリティ制御を回避し、保護されたオリジンサーバーへ直接アクセスできる状態になっていました。
FearsOffのセキュリティ研究者は2025年10月9日、特定の証明書検証パスを狙ったリクエストが、不正なトラフィックを遮断するために顧客が設定したWAFルールを完全に迂回できることを発見しました。
この脆弱性は、Automatic Certificate Management Environment（ACME）プロトコルで使用されるパスを悪用するものでした。
ACMEは、認証局が特定のURLパターンを通じてドメイン所有権を検証することで、SSL/TLS証明書の発行を自動化します: /.well-known/acme-challenge/{token}。
このパスは、本来、証明書検証ボットがドメイン所有権を確認するためだけに使われる、狭く制御されたゲートウェイであるべきものです。
Cloudflareのエッジネットワークには、このACMEチャレンジパスへのリクエスト処理方法にロジック上の欠陥がありました。
任意のリクエストが /.well-known/acme-challenge/* を対象にすると、正当な証明書検証への干渉を防ぐために、システムがWAFのセキュリティ機能を無効化していました。
しかし、そのコードは、リクエスト内のトークンが当該ホスト名に対する有効でアクティブなチャレンジと実際に一致しているかどうかを検証していませんでした。
その結果、攻撃者はACMEパスに任意のリクエストを送ることでWAF保護を完全に回避し、オリジンサーバーへ直接到達できました。
FearsOffの研究者は、この回避の深刻さを示すためのデモンストレーション環境を作成しました。彼らは、cf-php.fearsoff.org、cf-spring.fearsoff.org、cf-nextjs.fearsoff.orgを含むテストドメインへの全トラフィックを遮断するWAFルールを設定しました。
これらのドメインへの通常のリクエストは、正しくCloudflareのブロックページを返しました。しかし、同一のリクエストでもACMEチャレンジパスを狙うと、すべてのセキュリティ制御を回避してオリジンサーバーから直接応答が返ってきました。
Next.jsアプリケーションでは、サーバーサイドレンダリングのロジックが、本来公開されるべきではない運用上の詳細を露出させます。
ローカルファイルインクルージョン脆弱性を持つPHPアプリケーションは悪用可能となり、攻撃者が /etc/hosts のようなシステムファイルを読み取れるようになりました。
研究者は、アカウントレベルのWAFルールも完全に無視されることを確認しました。彼らは特定のテストヘッダー（X-middleware-subrequest）を含むリクエストをブロックするルールを設定しました。
通常のパスでは、これらのルールはフラグ付きリクエストを正しくブロックしました。ところが、同一のリクエストでもACMEチャレンジパスを対象にすると、評価されることなく通過しました。
これは、ヘッダー連結によるSQLインジェクション、X-Forwarded-Hostを介したサーバーサイドリクエストフォージェリ、キャッシュポイズニング、HTTPメソッドオーバーライドのトリックなど、ヘッダーベースの攻撃の広範なクラスが、脆弱なオリジンに到達し得ることを意味します。
Cloudflareは2025年10月27日に恒久的な修正を展開し、当該ホスト名に対してリクエストトークンが有効でアクティブなチャレンジと一致する場合にのみWAF機能を無効化するよう、ACMEチャレンジのロジックを変更しました。
脆弱性のタイムラインは責任ある開示を示しています。報告は10月9日にHackerOne経由で提出され、ベンダー検証は10月13日に開始、HackerOneが10月14日にトリアージを行い、最終修正は10月27日に展開されました。
Cloudflareは、顧客側での対応は不要であることを確認し、悪意ある悪用の証拠は見つかっていないと述べました。
この協業には、独立検証のためのCrypto.comセキュリティチームが関与し、パッチ適用を迅速化するためにCloudflare CEOのMatthew Prince氏との直接の連携も行われました。
このバグは、自動化のために用意されたメンテナンス用パスが、異なるコードパス間でセキュリティ制御の適用が一貫しない場合、危険な攻撃ベクトルになり得ることを浮き彫りにしています。
翻訳元: https://cyberpress.org/cloudflare-zero-day-flaw/