Tracking false positives after managed rule merges
A Cloudflare WAF rule merge changes more than naming. If a new detection is introduced in a disabled state and then folded into an existing managed rule, your alerting may keep pointing at the old path while the detection lives elsewhere. That is where false positives get mixed up with coverage changes.
The Sitecore cache poisoning detection tied to CVE-2025-53693 is a good example of the pattern. It has its own rule ID, then gets merged into the existing Remote Code Execution – Java Deserialization rule. If your logs, filters, or suppression rules watch only the new ID, they will miss the consolidated path once the merge lands.
Watch the rule IDs before you trust the alert count
Alert volume by itself does not tell you whether a merge reduced noise or moved detections into a different bucket. Rule ID consolidation can flatten what looked like two signals into one. That can make a false-positive trend look better on paper while the coverage underneath has changed.
The safest check is simple: map the older signature to the consolidated managed rule before you change anything else. If the merged rule keeps firing and the old ID drops away, the alert count may stay stable while the reporting path changes. If your monitoring only counts unique IDs, you will read that as a dip. It is just bookkeeping with better manners.
Map the old signature to the consolidated managed rule
Keep a direct record of which managed rule absorbed which detection. For the Cloudflare WAF rule merge case, that means linking the Sitecore – Cache Poisoning – CVE:CVE-2025-53693 detection to Remote Code Execution – Java Deserialization. Without that mapping, rule-level reporting and exception tracking go fuzzy fast.
This matters most when you have custom WAF rules built around specific managed IDs. A consolidation can leave those rules matching the wrong thing, or nothing at all. The detection still exists, but your local logic has gone blind to the new shape of it.
Separate genuine noise from coverage changes
A merge can make false positives look smaller without actually improving detection quality. The merged rule may simply absorb a signature that used to appear on its own. That is a coverage change, not proof that the noise vanished.
Check whether the same traffic still triggers the consolidated rule after the merge window. If the alert pattern shifts from one ID to another, the issue is probably identification, not behaviour. If the alerts stop entirely, then you need to know whether the detection was disabled, merged, or genuinely retired.
Check whether false positives rose, or the detection just moved
Look at the request patterns, not just the ticket count. A false positive usually leaves a repeatable shape in the logs, even when Cloudflare changes the rule ID. If that shape is still there after consolidation, the underlying detection path changed rather than the event disappearing.
Disabled release behaviour adds another wrinkle. In the 2026-05-18 scheduled change, the new Sitecore detection is created in a disabled state before being merged. That means you do not get an active blocking change from the new ID alone. Any observed change in alerts may come from how the managed rule is represented, not from new blocking behaviour.
Test the merged path against your custom WAF rules
Run the consolidated managed rule against any custom WAF rules that depend on the old signature. Look for filters that match on exact rule IDs, exception lists that carve out a single detection, and alert routing that assumes one managed rule equals one signature. Those break quietly, which is the worst sort of breakage.
If you tune exceptions around individual detections, consolidation removes that per-signature granularity. You may need to widen the exception to the whole managed rule or split the local logic into a different control path. That is less tidy, but tidiness is not the point when the ID has changed and the traffic has not.
