Cloudflare WAF scheduled release: rule ID changes
The release lands in Log mode first, so the new detections will show up as signal before they start blocking anything. That is helpful if you watch the feed closely, but it also means the visible behaviour changes before any enforcement does.
Four new detections are added in this release. One covers HTTP/2 request body anomalies tied to request smuggling. The other three cover XSS JavaScript event handler coercion across headers, body, and URI. They are separate paths, which matters if your dashboards group by rule family rather than by exact rule ID.
HTTP/2 request body anomalies land as a new detection path
The HTTP/2 detection is aimed at request body anomalies that fit a smuggling pattern. In practical terms, it gives you a fresh log-only path for traffic that looks wrong at the body level, rather than waiting for a later blocking rule to catch it.
That sort of release tends to expose noise before it exposes abuse. If you already chart HTTP/2 anomalies, expect a new line item rather than a neat replacement for an older one.
XSS coercion gets split across headers, body, and URI
The XSS coercion detections are split into three separate signatures: headers, body, and URI. That split is awkward if your monitoring stack assumes one attack class equals one rule ID. It also makes per-surface reporting cleaner, which is useful if a lot of your false positives live in one part of the request.
If alerting is tied to the family name alone, the new detections may look like a spike. If it is tied to exact IDs, they will look like three new rules, because that is what they are.
The beta script-tag rule is being folded back into the original managed signature
The beta rule for script-tag injection is being merged back into the original managed signature. Cloudflare is replacing the beta rule ID with the original managed rule ID, which is neat in the abstract and irritating in the bits that rely on stable identifiers.
That kind of replacement usually looks harmless in a console. In logs, allowlists, alerts, and reports, it can change the shape of the data without changing the attack surface at all.
The beta ID disappears from the reporting trail
Once the beta rule is folded back into the original signature, the beta ID stops being the thing you see and store. Any report keyed to the beta ID will lose continuity unless it maps cleanly to the managed rule ID.
That is the sort of drift that is easy to miss because nothing has actually broken. The same traffic still gets detected. The identifier just changes, which is enough to throw off trend lines and case histories.
Automation tied to rule IDs needs a fresh mapping
Any script, alert, or suppression rule built around the beta ID needs remapping to the managed rule ID. Hard-coded IDs age badly in WAF reporting, and this is one of those unglamorous reminders.
If your automation matches on rule ID, check for three things: alert routing, suppression rules, and any export jobs that label detections by signature. One missed mapping can leave a detection looking new, vanished, or duplicated depending on which layer reads it first.
Track the release like a control change, not just a changelog entry
A scheduled WAF release is a control change because it alters what gets logged, how it is named, and how it is counted. Treat it that way and the monitoring fallout stays boring.
The useful habit is simple: compare the old IDs and the new IDs in the places where decisions are made, not just where events are displayed. A dashboard can look fine while the alert behind it is now pointing at the wrong rule.
Check dashboards, alerts, and allowlists against the new IDs
Dashboards should be checked for renamed or replaced identifiers. Alerts need the same treatment, especially if they are grouped by exact rule ID rather than by managed rule family. Allowlists need the closest look of all, because a stale exemption can stop matching once the beta ID disappears.
If a suppression is meant for the script-tag beta rule, it should be verified against the merged managed rule ID. If it is left untouched, it may no longer suppress what it was built to suppress.
Validate that detection drift has not crept into your reporting
Detection drift shows up when the same traffic starts landing under different labels, or when a rule ID replacement makes old and new counts hard to compare. That is a reporting problem first and a security problem second, which is exactly why it gets ignored for too long.
A quick check is enough: compare pre-release and post-release logs for the affected rule families, then confirm whether the volume shift is real or just a naming change. If the beta rule disappears and the managed rule takes over cleanly, the counts should still make sense after the mapping update. If they do not, something in the reporting chain is still reading the old name and believing it.
