What changed in Cloudflare’s release and which traffic it catches
The update adds detections for unauthenticated remote code execution in Nuxt Server Islands and Alibaba Fastjson versions up to 1.2.83. It also adds signatures for cloud-hosted SSRF attempts, obfuscated command injection in request parameters, and extra rules for generic RCE, XSS, and file upload RCE patterns. A few existing managed rules changed from Log to Block, so traffic that used to be recorded for review now gets stopped by default.
That shift matters because the difference between logging and blocking is not academic. A logged payload still hits the origin, still exercises application parsing, and still gets a chance to trip a vulnerable code path. A blocked payload never gets that far. For a deserialisation bug or a parameter parser that happily follows attacker input, that is the difference between a noisy alert and a bad day.
Cloudflare split the coverage across its managed and free rulesets. The managed ruleset gained the Nuxt Server Islands and Fastjson detections, plus the SSRF and command-injection signatures. The free ruleset also picked up new block rules, which at least removes the excuse that basic edge protection is only for paid setups.
Nuxt Server Islands and Fastjson still need application-side fixes
WAF rules do not fix either problem. Nuxt Server Islands can still be abused if the application accepts attacker-controlled component names or props in a way that reaches dangerous server-side rendering paths. Fastjson still behaves like Fastjson: if an application runs Alibaba Fastjson 1.2.83 or earlier with unsafe defaults, deserialisation can execute arbitrary system commands. No edge filter gets to rewrite that part of the failure.
Cloudflare can catch known payload shapes, payload fragments, and common exploit structure. It cannot prove that the server is safe. A quieter variant, a slightly different parameter mix, or a new gadget chain can still slip past signatures while the application remains exposed. The WAF should sit in front of a fix, not replace one.
Check where request body inspection can and cannot see the payload
Request body inspection is only useful when the payload is actually visible to the WAF. If an exploit lives in the request body and the body is inspected, Cloudflare can match the pattern and block it. If the payload is buried in a route segment, encoded in a format the rule does not decode, or hidden in a request that is not inspected in full, the detection coverage gets patchy fast.
Encrypted traffic also matters. Once TLS is terminated at Cloudflare, the edge can inspect the request body it sees. If traffic bypasses Cloudflare, or if an upstream path changes the payload before inspection, the rule set loses reach. Multipart uploads, JSON variants, and parameter smuggling all create awkward corners where a signature may not land cleanly. That is why body inspection needs to match the application’s actual input paths, not the tidy diagram in the dashboard.
Turn the new detections into something you can trust in production
Treat the new detections as controls with failure modes, not magic shields. Start by finding which rules are in Log and which are already set to Block, then map them to real application behaviour. A rule that fires on harmless test traffic is useful until it starts blocking an odd but valid client request. A rule that never fires is just decorative noise.
Keep the origin fixes in place for Nuxt Server Islands and Fastjson. For Fastjson, that means not running vulnerable versions and not relying on the WAF to catch every deserialisation attempt. For Nuxt, the safer path is still to remove the unsafe input path, not to hope a signature always matches the exploit of the month. Edge rules buy time. They do not buy forgiveness.
Test the managed rule actions against real requests before relying on them
Run controlled test traffic through the exact paths that matter, then check the action the WAF takes. Look at whether the payload is blocked, logged, or passed through, and test both obvious and slightly obfuscated variants. The command-injection rules are there for a reason, but obfuscation is the whole trick with that sort of payload, and attackers do not care about your tidy examples.
Do the same for SSRF attempts against cloud metadata endpoints. A rule that catches the standard metadata URL is useful, but the messy edge cases are the ones worth checking. If the rule still logs rather than blocks, or blocks a valid internal health check by mistake, that needs to be visible before production traffic does the talking for you.
A managed rule is only as good as the action attached to it, and only as safe as the requests you have actually tested.
