Cloudflare’s scheduled WAF change and the rule it folds into
Cloudflare has a scheduled WAF release for 2026-05-18. The new entry is a detection for Sitecore cache poisoning, tagged CVE-2025-53693, and it is listed as disabled at release.
The key detail is that it does not stay as a separate permanent rule. Cloudflare says it will be merged into the existing Remote Code Execution – Java Deserialization rule. That makes the Java deserialization rule the anchor for the change, even though the new detection targets a different exploit path.
The disabled Sitecore cache poisoning detection
A disabled rule is not blocking traffic in any meaningful sense. It may exist in the catalogue, but it does not do the job most defenders care about, which is stopping requests.
That matters here because the new Sitecore detection is introduced without any public matching logic or enablement criteria. There is no clear way to test what it catches, or whether it matches only Sitecore-specific payloads, or some broader pattern that overlaps with the older rule.
Why the Java deserialization rule becomes the anchor
The original rule is named for Java deserialization remote code execution. Once the Sitecore detection is merged into it, the older rule ID becomes the one to watch.
That does not mean the underlying detection logic is unchanged. It means the new coverage is being attached to an existing rule identity, which is convenient for the vendor and mildly annoying for anyone trying to map alerts to a single signature name. Managed rules have a habit of doing that.
What changes when rule IDs are merged
A merged rule ID can break simple tracking. If a detection moves from one ID to another, or from a separate entry into a parent rule, dashboards and change logs may no longer line up neatly with what traffic is actually blocked.
For defenders, that creates a boring but real problem: the label changes before the operational behaviour is obvious. A rule that once looked like one signature may now represent a bundle of detections. If you are watching for a specific suffix, you can miss the fact that coverage has moved elsewhere.
Tracking the new suffix without mistaking it for coverage
Cloudflare gives the new rule ID suffix as …9e9c068d and the original Java deserialization rule as …7c5b669c. The new suffix marks the new detection, but it is still scheduled to be merged into the older rule.
Do not treat the appearance of the new suffix as proof that blocking is active. A named detection in a changelog is not the same thing as enforced protection on live traffic. Disabled release state is the clue that matters.
Reading managed rules updates without assuming blocking behaviour
Managed rules updates often blur the line between catalogue changes and enforcement changes. A new entry can be announced, folded into another rule, and still never block anything on its own.
For Cloudflare WAF rule merges, the safest reading is simple: check whether the rule is disabled, check which ID carries the merged logic, and check whether the managed rules change affects actual block behaviour or just the inventory of signatures. The changelog alone does not answer that.
Practical checks for defenders before and after release
Before the release date, record the current rule ID mapping for any Cloudflare WAF coverage you rely on. If you alert on rule names or suffixes, keep the old and new identifiers side by side so a merge does not look like a deletion.
After release, test against live policy state rather than the changelog entry. A disabled detection can sit inside a managed rules package without changing enforcement, and a merge can hide the movement unless you inspect the active rule set. If Sitecore cache poisoning is a concern, the useful question is not whether the signature exists somewhere in Cloudflare’s catalogue, but which rule is actually making decisions on requests.
