Cloudflare Managed Ruleset changes in Security Events
Cloudflare’s managed rules are updated in place, and the useful signal often lands in the Security Events dashboard before it settles into any neat release note. That is where merged detections show up, including rule IDs, actions, and the odd-looking cases where a new detection sits inside an existing managed rule.
The practical issue is simple: the managed ruleset name stays the same while the detection behaviour changes under it. If your monitoring keys off the old rule shape, you can end up with tidy dashboards and blind spots at the same time. A rule still firing is not the same thing as a rule still behaving the same way.
Watch the Security Events dashboard for merged detections
Merged detections are the bits that matter when Cloudflare folds a new pattern into an existing rule. In the Security Events dashboard, that can appear as a new event tied to an existing managed rule rather than a brand-new control with a fresh identity.
That matters for triage. If the new detection is merged into a rule you already trust, it can change the volume or shape of events without forcing a clean label change in your tooling. A quiet update is still an update, and quiet changes are the ones that usually waste the most time.
Rule action changes can quietly alter enforcement
Action changes are the awkward part. A managed rule can move from Block to Disabled, or from logging into something stricter, and the event trail still looks tidy if you are not reading it closely. The rule name stays familiar, but enforcement can shift underneath it.
Cloudflare’s managed rulesets can change action at the same time as detection logic changes. That means an event can represent a detection that is now visible but no longer enforced, or a detection that suddenly starts biting harder than your response playbook expects. Same rule family, different behaviour. That is where people get caught out.
Read the old action and the new action side by side
The only sensible way to read a managed rule update is as a pair: what it did before, and what it does now. If the old action was Block and the new action is Disabled, the detection may still appear in Security Events without actively stopping traffic. That is a very different operational posture.
Look for that before tuning alerts or response rules. If you only track the current state, you can miss the fact that an event used to mean enforcement and now means observation. That distinction matters when a WAF event is feeding incident response, dashboards, or any kind of automated escalation.
Check whether a disabled merged detection still affects your alerting
Disabled does not always mean irrelevant. A merged detection can still generate Security Events, and those events can still drive alerts, tickets, or metric spikes if your rules are too broad. In other words, the WAF may stop blocking, but your tooling may still panic.
That is worth checking any time Cloudflare folds a new detection into an old rule. If the action changes to Disabled, confirm whether your alerting logic still treats the event as a high-confidence attack signal. Sometimes that is sensible. Sometimes it is just a noisy habit.
Track the Java deserialisation update before it changes your response
The Java deserialisation update is a good example of why managed rules need watching after deployment, not just after release. Cloudflare introduced a new body detection and merged it into the original Remote Code Execution – Java Deserialization rule. The result is one rule family covering a wider pattern set, with enforcement behaviour that may no longer match the assumptions in older playbooks.
Java deserialisation detection is not a neat corner case. It sits close to remote code execution behaviour, so changes in matching logic can alter how quickly an incident appears, how much noise it creates, and whether a request is blocked or merely recorded. That is enough to spoil a day if the response logic was built around the old shape of the rule.
Map the new body detection to the original RCE rule
The useful move is to map the new body detection back to the original Remote Code Execution – Java Deserialization rule. That keeps the event stream readable when Cloudflare merges detections under one managed rule name. Without that mapping, a new body match can look like an unrelated event and get handled badly.
For monitoring, the rule identity matters less than the behaviour change attached to it. If the body detection is new and merged, tag it as an update to an existing RCE control rather than a separate mystery item. That makes it easier to see whether the event volume is rising because the detection got better or because traffic got worse.
Re-test any blocking or logging logic against the current managed rules
Any blocking or logging logic built around the old action needs a fresh look. A rule that once blocked may now be Disabled, which leaves you with a detection signal but no enforcement. A logging rule may now catch more cases than before, which can flood downstream alerts if nobody adjusts the thresholds.
Re-test the current managed rules against the paths you actually care about: API endpoints, admin surfaces, upload handlers, and anything else that tends to attract deserialisation abuse. The point is not to chase every event. It is to make sure the rule action still matches the response you expect when the WAF fires.
