Cloudflare's 24 August 2026 WAF release ships 5 rules in Log mode - ruleset overrides make them Block

Summary. Cloudflare announced 5 WAF managed rule changes on 17 August 2026 with a release date of 24 August 2026 and a release behaviour of Log. Four are new detections: 1 for HTTP/2 request smuggling and 3 for JavaScript event handler coercion across headers, body and URI. The fifth, rule ...c293b926, is a beta that merges into the existing rule ...7b58420b. Cloudflare's WAF changelog overview describes week 1 of its seven-day cycle as "Logging only", with rules moving to their default action on the next release day, which is 31 August 2026. Two paragraphs later, the same page warns that ruleset overrides and tag overrides "apply to existing and future rules in a managed ruleset". Both statements cannot be true for the same zone. If you set a ruleset-level action of Block on the Cloudflare Managed Ruleset, which is available on Pro at $20/month and Business at $200/month, these five rules block traffic on 24 August, not on 31 August. The scheduled-changes table also drops the Ruleset and New Action columns that every published release table carries, so it does not say which ruleset the rules belong to or what action they take next week.

What Cloudflare actually scheduled

The scheduled changes page and the matching changelog post both carry an announcement date of 2026-08-17 and a release date of 2026-08-24. Every row lists Log as the release behaviour and N/A as the legacy rule ID.

Rule ID	Detection	What the scheduled table does not tell you
...1489d892	HTTP/2 Request Smuggling - Request Body Anomaly	Which managed ruleset it belongs to
...20646260	XSS - JavaScript Event Handler Coercion - Headers	Its default action after 31 August 2026
...d706d517	XSS - JavaScript Event Handler Coercion - Body	Its default action after 31 August 2026
...660886c8	XSS - JavaScript Event Handler Coercion - URI	Its default action after 31 August 2026
...c293b926	XSS, HTML Injection - Script Tag - Beta	What happens to overrides pinned to this ID

Compare that with the release Cloudflare published on the same day. The WAF changelog entry for 2026-08-17 covers WordPress remote code execution metadata for CVE-2026-65640 across the Cloudflare Managed Ruleset and the Cloudflare Free Ruleset, and its table carries seven columns including Ruleset, Previous Action and New Action. The 2026-08-11 entry does the same: a new vBulletin detection for CVE-2026-61511 moved from Log to Block, and two beta rules moved from Log to Block as they merged into their originals.

That precedent is the only published guide to what happens on 31 August. The scheduled table itself is silent.

The contradiction that decides your Monday

Cloudflare's WAF changelog overview sets out the seven-day cycle in plain terms. Week 1 deploys new or updated rules with the Log action, and the page states that rules in this mode "record matching requests but do not block traffic". Week 2 moves them to their intended default action and strips the beta and new tags.

The same page then adds a caution: "Ruleset overrides and tag overrides apply to existing and future rules in a managed ruleset. This means overrides you configure today will automatically apply to rules added in regular and emergency releases."

The Ruleset Engine override reference repeats it and adds the escape hatch: "If you want to override existing rules only, you must use rule overrides." Rule overrides are keyed by rule ID, so they cannot reach a rule that did not exist when you wrote them.

Put those together and the Log week is not a property of the release. It is a property of your configuration.

Your zone's configuration	Behaviour on 24 Aug 2026	Behaviour on 31 Aug 2026
No overrides on the managed ruleset	Log	Cloudflare's default action per rule
Ruleset-level action set to Block	Block from day one	Block
Ruleset-level action set to Log for testing	Log	Log, and you never see the default
Tag override on a tag these rules carry	The tag's action from day one	The tag's action
Rule overrides only, written before 17 Aug	Log	Cloudflare's default action per rule

The middle row is the one that costs money. A team that followed Cloudflare's own suggestion in the override reference, "to test a managed ruleset before enforcing it, consider executing the ruleset with all rules set to log instead of their default actions", has silently opted every future rule out of enforcement. There is no expiry on that override and no notification when a new rule inherits it.

The beta merge deletes your tuning

Rule ...c293b926, "XSS, HTML Injection - Script Tag - Beta", carries the comment that it "will be merged into the original rule 'XSS, HTML Injection - Script Tag' (ID: ...7b58420b)".

Cloudflare's changelog overview explains the mechanism: for updates to existing rules, it first deploys the updated version as a separate BETA rule with a beta tag, before updating the original rule on the next release cycle. So the beta rule ID is temporary by design.

If you spent the beta period tuning ...c293b926 down because it matched a legitimate template, that rule override points at an ID that stops existing. Your exception or override does not migrate. The broadened detection arrives inside ...7b58420b, carrying whatever configuration ...7b58420b already had.

The reverse failure is worse and quieter. The changelog overview states: "Once you change a rule to use an action other than the default one, Cloudflare will not be able to override the rule action." A zone that pinned ...7b58420b to Log two years ago after a false positive keeps it on Log. The merged, wider Script Tag detection then lands with no enforcement at all, and nothing in the dashboard flags that the rule is now doing more work for no effect.

Three of the five rules make this harder than it looks. JavaScript Event Handler Coercion ships as three separate IDs for headers, body and URI. Tuning the detection means three rule overrides, not one, and the scheduled table publishes no tag you could use to cover all three at once.

How to tell whether this is you, before the window closes

Security Events is where the Log week is visible, and its retention is the reason this cannot wait until 31 August. Cloudflare's Security Events documentation sets retention by plan.

Plan	Security Events retention	Can you review 24 Aug on 31 Aug?
Free	Up to the last 24 hours	No
Pro	Up to the last 24 hours	No
Business	Up to the last 3 days	No
Enterprise	Up to the last 30 days	Yes

On Free and Pro, the entire seven-day observation window Cloudflare designed is invisible to you six days later. Free zones also get sampled logs only, with no export. If you are on Pro or Business and you want the false-positive data these rules were put in Log mode to generate, you have to look inside the release day itself or push the events to your own store.

Three checks are worth running today.

Read your phase entry point ruleset and look at action_parameters.overrides. The Terraform guide for WAF Managed Rules confirms only action and enabled can be overridden on a rule, so a ruleset-level action is easy to spot and easy to forget you set.

Check whether the override lives at the account level or the zone level. Cloudflare's WAF exceptions documentation states that account-level rulesets run before zone-level rulesets within a phase, and that a zone-level exception will not prevent a match at the account level. A zone owner who tests an exception locally and sees no change is often fighting an account-level deployment they cannot see.

Confirm which ruleset you actually run. The Managed Rules page lists Cloudflare Managed Ruleset (...376e9aee) as Pro and above, and Free Managed Ruleset (...dfb893ba) as available on all plans. Because the scheduled table omits the Ruleset column, a Free-plan zone has no published way to know whether these five rules reach it at all.

The documentation is four months behind the release

The pages that govern this release are not maintained on the release cadence. The scheduled-changes page, the changelog overview, the override reference and the WAF exceptions page all report dateModified of 2026-04-16 in their JSON-LD, four months and eight days before the 24 August release, even though the scheduled table's contents changed on 17 August.

Page	dateModified	Governs
WAF scheduled changes	2026-04-16	The five rules releasing today
WAF changelog overview	2026-04-16	The seven-day Log-then-default cycle
Override a managed ruleset	2026-04-16	Whether Log week applies to you
Cloudflare Managed Ruleset	2026-08-03	Which rules are disabled by default
Managed Rules	2026-08-14	Plan availability and ruleset IDs

If you monitor Cloudflare's documentation with a scheduled fetch that diffs dateModified, this release is invisible. The changelog RSS feed at /changelog/rss/index.xml does carry the post, so feed subscription is the only reliable trigger. The same pattern showed up in Cloudflare's leaked credentials Authorization header change, where the detection page lagged the behaviour change, and in the enriched API 403 documentation URLs that point at pages describing something other than what the changelog promised.

What is still unknown

Cloudflare has not published the default action for any of the four new detections. The 2026-08-11 precedent points to Block, but a new HTTP/2 request smuggling detection on request body anomalies is exactly the class of rule that produces false positives on APIs with unusual framing, and Cloudflare also ships some rules in disabled mode for impact testing. Neither the ruleset membership nor the tags for the five rules are published. Until the 31 August changelog entry appears, the honest answer is that today's Log rows do not tell you what next Monday does.

India-specific considerations

Indian teams running payment or lending APIs behind Cloudflare have a narrower margin here than the plan table suggests. A Pro-plan zone with 24-hour Security Events retention cannot produce a week of evidence that a new WAF rule did not disrupt a regulated flow, which is the kind of record a Digital Personal Data Protection Act 2023 readiness review or an RBI-facing audit expects to see. If the WAF sits in front of a consent or KYC endpoint, push security events to your own log store now rather than relying on dashboard retention, and record the override state of the managed ruleset alongside the change, because the override, not the release, determines what happened on 24 August. Teams tracking rule-level visibility gaps in other cloud firewalls will recognise the pattern from network firewall rule hit counts, where pass rules were invisible in the metrics that audits relied on. The wider request-handling context sits in our web platform developer guide.

FAQ

What changes in Cloudflare's WAF on 24 August 2026?

Cloudflare releases five managed rule changes announced on 17 August 2026. Four are new detections: HTTP/2 Request Smuggling - Request Body Anomaly, and JavaScript Event Handler Coercion for headers, body and URI. The fifth is a beta Script Tag rule that merges into rule ...7b58420b. All five list Log as their release behaviour.

Does Log mode mean these rules cannot block my traffic today?

No. Cloudflare's changelog overview says ruleset overrides and tag overrides apply to existing and future rules in a managed ruleset. A zone with a ruleset-level action of Block applies that action to all five new rules from the release date, not from the following week. Only zones without those overrides get logging behaviour.

When do the new rules take their default action?

Cloudflare's release cycle runs over seven days, so the default action lands on the next release day, 31 August 2026, when the beta and new tags are removed. The scheduled-changes table for 24 August omits the New Action column that published release tables carry, so the default action is not disclosed in advance.

What happens to my override on the beta rule ...c293b926?

That rule merges into the original rule ...7b58420b. Rule overrides are keyed by rule ID, so an override written against the beta ID stops applying once the beta rule is gone. The broadened detection then runs under ...7b58420b with whatever configuration that rule already carried in your zone.

Why might a merged rule stop protecting me?

Cloudflare states that once you change a rule to use an action other than the default one, Cloudflare cannot override the rule action. A zone that pinned ...7b58420b to Log after an earlier false positive keeps Log after the merge, so the wider Script Tag detection runs without enforcement and nothing in the dashboard flags it.

How long can I review the Log-week data?

Security Events retention is up to 24 hours on Free and Pro, up to 3 days on Business, and up to 30 days on Enterprise. On Free and Pro the 24 August release day is no longer queryable by 31 August, so the observation window Cloudflare designed is only usable if you export events or run on Enterprise.

Which managed ruleset do the five rules belong to?

Cloudflare has not said. The scheduled-changes table for 24 August drops the Ruleset column that the 17 August and 11 August release tables include. The Cloudflare Managed Ruleset is available on Pro and above, while the Free Managed Ruleset runs on all plans, so Free zones cannot confirm whether these rules reach them.

What should I check before the release lands?

Read your phase entry point ruleset for a ruleset-level or tag-level action in action_parameters.overrides, confirm whether the managed ruleset is deployed at the account level or the zone level, and identify which ruleset you run. Account-level rulesets execute before zone-level rulesets, so zone-level exceptions cannot suppress an account-level match.

How eCorpIT can help

We review WAF managed ruleset deployments the way an auditor would: reading the phase entry point ruleset, listing every ruleset, tag and rule override, and reporting which future rules each override will silently capture. As an ISO 27001:2022 certified, CMMI Level 5 organisation, we design application security controls aligned with DPDP and RBI expectations, and we set up security event export so retention limits do not erase your evidence. If your WAF sits in front of regulated traffic, book a WAF override review and we will map your override state against Cloudflare's next release cycle. Related engineering work sits in our multicloud security posture service.

References

1. WAF Release - Scheduled changes for 2026-08-24, Cloudflare changelog
2. WAF scheduled changes, Cloudflare WAF documentation
3. WAF changelog overview and release cycle, Cloudflare
4. WAF changelog, releases for 2026-08-17 and 2026-08-11, Cloudflare
5. Managed Rules, Cloudflare WAF documentation
6. Cloudflare Managed Ruleset reference, Cloudflare
7. Override a managed ruleset, Cloudflare Ruleset Engine documentation
8. Create exceptions, Cloudflare WAF documentation
9. Security Events and plan retention, Cloudflare WAF documentation
10. WAF Managed Rules configuration using Terraform, Cloudflare
11. Cloudflare Web Application Firewall overview
12. Cloudflare plans and pricing

Last updated 24 August 2026.