Blocking CVE-2026-50522 with Cloudflare WAF Managed Rules
The important change is simple: a SharePoint RCE detection now has teeth. Rule 052b07cf, identified as Microsoft SharePoint - Remote Code Execution - CVE:CVE-2026-50522, moved from Log to Block. That changes it from something you can inspect later into something that stops the request at the edge.
For any Microsoft SharePoint Server deployment reachable through Cloudflare, that is the difference between seeing exploit traffic and refusing it. Logging has value during rollout, but it does nothing to stop a live attempt. A rule that only records malicious traffic is still a pass for the attacker.
SharePoint remote code execution moves from Log to Block
This is the most direct fix in the release. The SharePoint detection is new, and the action change means Cloudflare now treats the request pattern as something to reject by default rather than merely observe.
That matters because edge controls are often left in a half-finished state. A logging rule can sit there for weeks while someone waits to “see what normal looks like”. In that time, exploit traffic gets through if nothing else catches it. For an RCE issue, that is a poor trade.
Rails Active Storage stays covered while older SSRF detections disappear
Cloudflare kept rule 3a5b40d6 active for Rails - Arbitrary File Read & RCE - CVE: CVE-2026-66066, with the action still set to Block. The rule had previously been labelled File Upload - RCE, which is the sort of name that causes confusion when people are scanning a long managed rule list and trying to work out what still applies.
The SSRF side is less tidy. Rule 25ba9d7c, SSRF - Cloud, moved from Disabled to Block, which is the sort of change that quietly fixes a gap. At the same time, several older SSRF detections were removed:
8242627b:SSRF - Local743a63ec:SSRF - Local - 2 - Betac2e84e2d:SSRF - Cloud - Betaab8af26f:SSRF - Cloud - 2 - Beta01a076eb:SSRF - Local - Beta
If those labels existed in custom handling, stale references become a problem fast. A removed rule is not a dormant rule. It is gone.
Reading the managed rule set before you trust it
Managed WAF coverage is only useful if the account is actually running the rules you think it is. The labels are close enough to fool someone skimming the dashboard, which is usually how trouble starts. A rule can sound present, but its action can be wrong, or the rule can have been renamed, moved, or removed.
Rule IDs, action changes, and the traps in old labels
Rule IDs matter more than headings in the UI. The SharePoint detection is 052b07cf. The Rails rule is 3a5b40d6. The cloud SSRF rule is 25ba9d7c. If filters, exceptions, or logging pipelines still point at the old names, the tidy-looking policy may not match the live one.
Old labels are a trap. The Rails rule was previously marked File Upload - RCE, which looks harmless until someone assumes that label still describes the current coverage. Security tooling has a habit of keeping old names around long after the behaviour changes. It makes audit work tedious, which is probably why it gets skipped.
Which legacy SSRF variants are gone for good
The removed SSRF variants were the local and beta flavours, not the current cloud rule. That is the useful boundary. If a policy, note, or exception still refers to those old detections, it needs updating or removing.
This also tells you something about how to read managed protection. Cloudflare is not promising that every historical detection stays forever. Rules get replaced, merged, or dropped. If your account still relies on a legacy SSRF pattern, it may now be a blank line in the control set.
Hardening the edge so the fix sticks
Managed rules are only one layer. They catch known request patterns, but they do not protect a weak origin, a missed path, or a custom application route that behaves badly under hostile input. Edge filtering works best when the origin is not easy to reach in the first place.
Check the SharePoint and Rails rules are active in your account
The first check is boring and necessary: confirm that the SharePoint and Rails managed rules are present, enabled, and set to the intended action in the actual account that fronts the app. It is easy to look at a staging zone, a different tenant, or an old policy export and assume the live edge matches it. It often does not.
For SharePoint, the key question is whether 052b07cf is blocking exploit traffic. For Rails Active Storage, check that 3a5b40d6 remains in place and not silently overridden by a broader exception. If a control has been disabled by an exception upstream, the managed rule name becomes decoration.
Add custom WAF rules and origin protection where the managed set is not enough
Managed rules do not know your application’s odd paths, internal admin routes, or the one legacy endpoint someone forgot to retire. That is where custom WAF rules still matter. Use them to block paths that should never be public, restrict unexpected methods, and deny requests that only make sense from trusted networks.
Origin protection matters just as much. If the origin can still be reached directly, the edge is only one route of defence. Lock it down so traffic must pass through Cloudflare, then narrow access at the origin too. A managed rule that blocks one exploit family is useful; an origin that accepts anything else is still a problem.
For cloud-hosted apps, the safe default is not to trust a managed set as a complete answer. Treat it as a current control set, check the rule IDs, and back it with custom WAF rules where your own application shape leaves gaps.
