What changed in the Managed Ruleset release
The update touches three areas: Microsoft SharePoint, Ruby on Rails Active Storage, and SSRF detection for cloud-hosted applications. One new SharePoint RCE rule was added, one Rails rule kept blocking but was relabelled, and the SSRF cloud rule now blocks instead of sitting disabled.
That last part matters most for day-to-day application security. A disabled rule is only useful if you remember it is there. In practice, people tend to assume a rule name means active protection, which is how gaps survive long enough to become boring.
Cloudflare also removed a set of legacy SSRF detections, including local and beta variants. If those names still sit in notes, dashboards, or runbooks, they now give a false sense of coverage.
Which SSRF detections disappeared and which one now blocks
The removed detections were:
- SSRF – Local
- SSRF – Local – 2 – Beta
- SSRF – Local – Beta
- SSRF – Cloud – Beta
- SSRF – Cloud – 2 – Beta
The surviving cloud rule, SSRF – Cloud, moved from Disabled to Block. That is the rule that now matters when you are checking SSRF protection for cloud-hosted applications.
For the rest of the Managed Ruleset, the SharePoint rule for CVE-2026-50522 is now a blocking detection, and the Rails Active Storage rule for CVE-2026-66066 stays in Block. The Rails entry used to be labelled as File Upload – RCE, which is another neat reminder that rule names age badly.
Keep the removed beta rules out of your mental model
Beta detections are easy to overvalue because they look like extra coverage. They are not stable controls. Once they are removed, they stop being part of your WAF coverage, no matter how often they appear in old screenshots.
If a team has been relying on a mix of local, beta, and cloud SSRF detections, the sensible default is to treat only the current cloud rule as live. Anything else should be checked against the current Managed Ruleset rather than assumed to exist because it used to.
How to check that your WAF coverage still matches the traffic you see
Start with your block logs. Look for the current SSRF cloud rule ID and confirm it is firing on traffic that looks like outbound fetch attempts, metadata access probes, or other suspicious requests aimed at cloud-hosted applications. If you see nothing, that is not reassurance by itself. It may mean the traffic never arrived, or that the rule does not match the patterns you actually receive.
Then test against known request shapes in your environment. The useful part is not a generic SSRF string pasted into a request. It is traffic that resembles what your application accepts, because SSRF filters often miss the awkward, real-world request formats that matter.
Review block logs and test against cloud-hosted application requests
Check whether the rule blocks requests aimed at internal services, metadata endpoints, or other fetch targets your app should never contact. If your app accepts URLs, callbacks, image fetches, import jobs, or remote previews, that is where you test. Those are the places where SSRF turns up wearing ordinary application behaviour as a disguise.
If you use Cloudflare WAF Managed Rules as a control layer, make sure the current rule action matches what you think it does. Disabled rules do nothing, beta rules come and go, and old names stick around long after their protection has vanished.
