Cloudflareは2026年7月20日、Managed Rulesetへ8件の新規検知を追加する。対象は、制限プロトコルや難読化ホストを使うSSRF、パストラバーサル型LFI、Adobe ColdFusionの2件の脆弱性、本文・ヘッダー・URIに対するJavaScript難読化XSSである。初期動作はすべてLogで、即時にリクエストを遮断する変更ではない。

何が変わるか

新規ルールは次の領域を対象にする。

  • SSRF: Restricted Protocol
  • SSRF: Obfuscated Host
  • LFI: Path Traversal
  • Adobe ColdFusion File Upload Path Traversal（CVE-2026-48276）
  • Adobe ColdFusion Path Traversal（CVE-2026-48282）
  • XSS JS Bracket Concat ObfuscationのBody、Headers、URI

Cloudflareの発表ではRelease BehaviorはLogである。したがって、7月20日に突然正当な通信がブロックされる可能性は低い。ただし、将来アクションがBlockへ変わる場合や、利用者側が個別にアクションを上書きする場合に備え、Log期間を評価期間として使う必要がある。

影響の見方

SSRF検知は、URLフェッチ、Webhook、画像取得、PDF生成、外部API連携など、利用者がURLを入力できる機能で反応し得る。LFIとColdFusion向け検知は、ファイルパスやアップロード名を扱うアプリケーションで確認が必要になる。XSS検知は、コード断片、テンプレート、検索クエリ、セキュリティ検証用ペイロードなど、業務上正当でも特殊な文字列を含む通信に影響し得る。

Logだけであっても、イベント量の急増はSIEMコストやアラート疲れにつながる。逆に、検知を無視すると、将来のBlock化に備えた誤検知調整の機会を失う。

7月20日までに行うこと

対象ルールIDを監視ダッシュボードへ登録し、変更前のWAFイベント量を基準値として保存する。アプリケーションチームには、URL入力、ファイル操作、HTMLやJavaScriptを含む入力を処理するエンドポイント一覧を提出させる。

リリース後は、ルール別、ホスト別、パス別、送信元別に検知を分類する。正当な通信だった場合、いきなりルール全体を無効化せず、特定パス、特定パラメータ、既知の送信元へ例外を狭く設定する。攻撃と判断したイベントは、オリジンサーバーのログやアプリケーションの入力検証と突き合わせる。

評価方法

ステージング環境では、既知のSSRF、パストラバーサル、XSSテストケースを使い、各ルールが期待どおり記録されるか確認する。同時に、通常のファイルアップロード、Webhook登録、検索、コード投稿などを回帰試験する。

評価指標は、検知件数だけでは不十分である。真陽性率、誤陽性率、対象エンドポイント、リクエスト処理時間、SIEM取り込み量、調査時間を記録する。Blockへ変更する判断は、攻撃再現と正当通信の回帰試験を両方通過してから行う。

ロールバックと例外管理

利用者側でBlockへ変更した後に障害が出た場合は、まず該当ルールをLogへ戻す。ルールセット全体の無効化は最後の手段とする。例外は有効期限、対象パス、理由、承認者を記録し、恒久化しない。アプリケーション側の入力検証を修正できたら、例外を削除して再試験する。

実務チェックリスト

  • 8件のルールIDを監視対象へ追加する
  • 7月20日前のWAFイベント基準値を保存する
  • URLフェッチ、ファイル操作、コード入力を扱う経路を棚卸しする
  • ステージングで攻撃テストと正常系回帰試験を行う
  • 例外はパスや条件を限定し、有効期限を設定する
  • Block変更時の即時復旧手順を用意する

編集部の見解

今回のリリースはLog開始なので、対応を後回しにしやすい。しかし、Log期間こそ本番トラフィックで誤検知を把握できる最も安全な時間である。7月20日以降のイベントを定量評価し、将来のBlock化に耐えられる例外設計を先に作るべきだ。

一次情報