Cloudflare Brings Real-Time Threat Intelligence into WAF Rules

Cloudflare Brings Real-Time Threat Intelligence into WAF Rules

In June 2026 Cloudflare announced a significant security upgrade: integrating Cloudforce One real-time threat intelligence directly into the WAF engine, letting security teams write proactive rules based on who is attacking, who they target, and how. Previously, teams would see in Threat Events that an IP was linked to a specific actor such as Tycoon 2FA or RaccoonO365, but had to manually copy IP lists into rules. Now that intelligence becomes WAF rules directly, blocking high-risk actors before they touch your infrastructure.

New WAF Fields

To make intelligence usable for rule matching, Cloudflare exposes the following cf.intel fields:

Because a single IP can be associated with multiple actors or industries, these fields are arrays, and you combine them with the any() function and [*] wildcard. For example:

• Block known DDoS participants targeting your region: any(cf.intel.ip.target_countries[*] == "FR") and any(cf.intel.ip.datasets[*] == "ddos")
• Protect against a specific actor hitting the Finance sector: any(cf.intel.ip.target_industries[*] == "Banking & Financial Services") and any(cf.intel.ip.attacker_names[*] == "BLACKBASTA")

Always-On Detection: Separate Detection from Mitigation

This builds on Cloudflare's always-on detection framework: threat intelligence runs continuously in the background, enriching every HTTP request with threat metadata rather than only logging on rule match. This removes the traditional log-versus-block tradeoff, because once a rule blocks a request you lose visibility into how other signatures would have assessed it.

On performance, the threat datasets are compressed and distributed to every Cloudflare data center, and the WAF performs O(1) constant-time lookups, keeping latency overhead in microseconds whether checking ten indicators or ten million. The initial release focuses on IP matching, with plans to extend to JA3/JA4 fingerprints and domain matching to counter IP rotation.

How to Use It and What It Means for Websites

The fields are fully integrated into WAF custom rules and rate limiting, manageable via the Cloudflare API and Terraform as infrastructure as code. Matches appear in Security Analytics for audit and postmortem, and Threat Events saved views can be exported into a WAF rule with one click.

For most sites, this shifts protection from static rules to dynamic intelligence. Start with the WAF guide and website security best practices, then expand with the Security Hardening category.

Managing threat-intel rules with Terraform

Since the fields are manageable via the Cloudflare API and Terraform, a rule that "blocks known DDoS participants targeting your region" looks roughly like this:

resource "cloudflare_ruleset" "waf_threat_intel" {
  zone_id = var.zone_id
  kind    = "zone"
  phase   = "http_request_firewall_custom"

  rules {
    action = "block"
    expression = <<EOT
any(cf.intel.ip.target_countries[*] == "FR") and
any(cf.intel.ip.datasets[*] == "ddos")
EOT
    description = "block known DDoS participants targeting France"
  }
}

Once the rule is inside your terraform plan / apply flow, the team gets an audit trail of "which rule changed, and why", plus one-command rollback. Compared with clicking around the dashboard, this suits teams that run many rules and need several people to collaborate on defense.

Reference: https://developers.cloudflare.com/ruleset-engine/rules-language/expressions/

Rollout path: from small sites to high-value targets

For most sites, subscribing to threat intelligence up front is not the right move. A more pragmatic order is:

1. Turn on managed rules first: enable Cloudflare's built-in WAF managed rule sets and rate limiting to keep the most common injection, scanning, and brute-force attempts out;
2. Observe with Security Analytics: spend a week or two noting which regions and paths keep probing your site, then turn those findings into custom rules;
3. Consider intelligence rules later: when the attack surface grows, or after facing targeted DDoS or phishing groups, evaluate the cf.intel fields and paid threat intelligence;
4. Pair with other controls: threat intelligence only covers the "known actors" layer — certificates, two-factor authentication, backups, and patching are still non-negotiable (see the website security best practices).

FAQ

• Do the cf.intel fields require a paid plan? Availability depends on your plan tier and the threat-intel licensing scope; try writing a rule in your own plan to confirm. Managed rules and rate limiting are built into the plan.
• Does always-on detection add request latency? The design uses O(1) local lookups with microsecond overhead, imperceptible for normal traffic; if concerned, verify with a side-by-side test.
• What if I block legitimate traffic? Ship the rule in "log" mode first, watch matches for a few days, then switch to "block", and give every rule a clear description and tag for later audits.
• Is WAF alone enough? No. The WAF is one layer at the traffic entry; origin security, access control, backup, and recovery matter just as much. Layered defense beats a single point.

Source: https://blog.cloudflare.com/realtime-threat-intel-waf-rules/