PuppyIP Resource Center
Developer Tool Updates 9 min Published 2026-09-15 Updated 2026-09-16

Three Cloudflare WAF rules now Block: investigating matches and false positives

On September 15, 2026, Cloudflare changed three Managed Ruleset detections from Log to Block. Sites using the managed WAF should first check their effective rule actions. For new 403 responses, use Security Events to distinguish attacks from false positives before considering a narrowly scoped, temporary exception.

Cloudflare WAF Managed Ruleset SSRF Command Injection Information disclosure False-positive investigation

Service eligibility and regional restrictions

PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.

Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.

Key Takeaways

  • The changes cover SSRF - Cloud - 3 (...ca453d31), Version Control - Information Disclosure - Beta (...e540f17f), and Command Injection - Generic 10 (...ba458b4b).
  • All three default actions changed from Log to Block. The version-control beta rule was merged into the original rule ...0550c529; its beta suffix should not be a permanent sole identifier.
  • Cloudflare published only rule ID suffixes, without an exact release time, rollout scope, customer-plan coverage rate or false-positive rate. Actual zone actions may also depend on deployment and overrides.
  • Check new Security Events by Block action, host, path and rule. Keep timestamps, Ray IDs, rule names, actions and application logs. A single 403 does not prove this rule change caused it.
  • After proving that a target rule blocked a legitimate request, prefer a time-limited exception matching precise request conditions and specific rules. Do not disable the entire Cloudflare Managed Ruleset.
  • PRODUCT_FIT=CONDITIONAL_NETWORK_ONLY: a fixed IP cannot change WAF rules or remove a Block. Investigate networking only with independent evidence of DNS, TLS, 407 or connection-timeout problems accessing the dashboard or API.

Confirm exactly what changed in the three rules

Cloudflare's September 15, 2026 WAF Release lists Previous Action=Log and New Action=Block for three Cloudflare Managed Ruleset detections. The published ID suffix for SSRF - Cloud - 3 is ...ca453d31, and for Command Injection - Generic 10 it is ...ba458b4b. Both are marked as new detections.

The third rule, Version Control - Information Disclosure - Beta, has the published suffix ...e540f17f. Cloudflare says it was merged into the original Version Control - Information Disclosure rule ...0550c529. The official page gives suffixes only. In the dashboard, API or logs, verify the complete rule ID together with the rule name and ruleset; do not invent the rest of a UUID.

A new Block default does not mean every zone uses the same action

The release confirms a change to Cloudflare's managed defaults. Whether a request is blocked also depends on whether the target zone deploys the Cloudflare Managed Ruleset, its deployment scope, current ruleset version, and rule-level, tag-level or ruleset-wide overrides. If the rule or effective action cannot be confirmed, record coverage as UNKNOWN rather than claiming the site has the new protection.

Before and after the change, export or record the zone, ruleset, complete rule ID, rule name, default action, effective overrides and change time. Cloudflare documentation states that specific rule-level settings take priority over broader ruleset configuration. Tag-level overrides can also affect future rules with that tag, making them unsuitable as a rushed response to a single false positive.

Find new Blocks in Security Events rather than relying on browser 403s

In Cloudflare Security Events, select a time range spanning the change, start with Action=Block, then narrow by Host, Path, Source, service or rule. Cloudflare says this page shows events processed or flagged by security products. One HTTP request can generate multiple events, so event counts are not distinct request counts.

For each potentially related sample, retain the UTC timestamp, Ray ID, hostname, path, HTTP method, full rule ID, rule name, action, application version and corresponding origin logs. Sampling, historical retention and export options vary by plan. When only sampled logs are available, state that limitation rather than extrapolating total traffic or a false-positive rate.

Separate malicious matches, legitimate false positives and unrelated failures

If events involve cloud metadata addresses, command-injection patterns or version-control history paths, first treat them as security incidents. Preserve request and origin evidence, check whether requests reached the origin and whether abnormal processes or file access occurred, and contain risk through the existing response procedure. A Block proves an edge action occurred; it proves neither a successful attack nor the absence of bypasses through other paths.

Evidence of a false positive requires the same legitimate business request to succeed before the change, consistently match the target rule afterward, and correlate through Ray IDs and application logs. Without a target-rule match, distinguish origin 403s, identity permissions, Bot Management, Rate Limiting, DNS, TLS and proxy errors. Do not attribute every 403 to this WAF release.

For confirmed false positives, use the narrowest temporary exception

Cloudflare exceptions use the Skip action, with expressions defining the conditions and specific rules to skip. Restrict conditions to verified hostnames, paths, methods, trusted caller attributes and target rules. Record an owner, approver, start and expiry times, sample Ray IDs and compensating controls. Do not disable the entire Managed Ruleset for one legitimate request or create a broad tag override that automatically affects future rules.

The exception's account/zone scope and execution order must match the actual deployment level: a zone-level exception cannot stop an account-level rule from matching first. If sufficiently narrow conditions cannot be expressed, or the request remains suspicious, pause the affected feature and escalate to the security owner instead of widening the bypass.

Define validation, removal and stop conditions together

In an isolated environment or with minimal production traffic, validate three outcomes: malicious or approved harmless detection samples remain blocked, the legitimate primary path works again, and unrelated hosts and paths are not skipped. Do not send executable attack payloads to production. Retain rule IDs, actions, Ray IDs, origin results and exception versions when retesting.

After an application fix or Cloudflare rule update, remove the temporary exception first, then retest legitimate requests and the target detection. Stop normal traffic expansion and involve the security team if Block counts rise abnormally, sensitive paths are probed, suspicious execution appears at the origin, events cannot be correlated with application requests, or exception scope cannot be shown to be narrow enough.

Network egress controls connectivity, not WAF permission

A fixed egress IP does not change the Cloudflare Managed Ruleset, default actions, overrides or exceptions, and cannot automatically allow a request blocked by the WAF. Rotating IPs to bypass rules also disrupts evidence correlation and can increase security risk.

Refer to the proxy connection troubleshooting checklist only when accessing the Cloudflare dashboard or API produces DNS failures, TCP timeouts, TLS certificate errors, proxy 407 responses or consistent differences between network paths. If Security Events already proves a rule match, investigate WAF configuration, application input and security response.

Sources

Frequently Asked Questions

Which three Cloudflare WAF rules changed from Log to Block?

SSRF - Cloud - 3 (...ca453d31), Version Control - Information Disclosure - Beta (...e540f17f), and Command Injection - Generic 10 (...ba458b4b). Only ID suffixes were published; use complete IDs from the dashboard or API for verification.

Why are there no Blocks from these three rules?

The zone may not deploy the relevant Managed Ruleset, requests may not match, the version may not yet appear, or existing overrides may change the default action. Check the zone, ruleset version, full rule IDs and effective configuration; do not claim coverage while it is unknown.

Does a browser 403 prove this WAF update matched?

No. Correlate the request in Security Events using its time, Ray ID, host, path, rule ID and action. Origin permissions, Bot Management, Rate Limiting and other security rules can also return 403.

Can I disable the Cloudflare Managed Ruleset after finding a false positive?

Do not disable it outright. First prove that a legitimate request matched the target rule, then create the narrowest time-limited exception for specific request conditions and rules, with an owner, expiry, compensating controls and removal verification.

Should the Version Control beta rule remain a permanent configuration target?

That is not recommended. Cloudflare says ...e540f17f was merged into the original Version Control - Information Disclosure rule ...0550c529. Check the rule name, full ID and current ruleset together rather than hard-coding the beta suffix as the sole permanent identifier.

Can another proxy or fixed IP resolve a WAF Block?

No. A WAF Block is a security-rule action. Network egress becomes relevant only with independent DNS, TCP, TLS or 407 evidence when accessing the dashboard or API.