Cloudflare caching issue?

No.

One of my websites had the very same problem, and after digging in a bit I found out with help from other Community MVPs that this path /z0f76a1d14fd21a8fb5fd0d03e0fdc3d3cedae52f?wsidchk=123456 is returned by a firewall service that some hosting providers are adopting In my case, it was A2 Hosting.

The Imunify360 / Webshield firewall will stand between Cloudflare edge and your origin. You can talk with your hosting provider’s support for more info on its behavior, but as far as Cloudflare is concerned, that means if you have a “cache everything” Page Rule you may need to adjust it somehow.

When Imunify360 detects a malicious activity, it intercepts the request and sends an interstitial page with a 200 HTTP status code. That page has a JavaScript redirect that points to that path, which then gets a 404 as there’s no such page on your server. The problem is that with Edge Cache TTL, the no-store directive set by the Cache Control header on the interstitial page is overridden, and that page is cached. After that, every visitor will get redirected to the 404 for as long as that interstitial page is not purged from cache.

Most users will create a Page Rule with a Cache Level: Cache Everything instruction coupled with a Edge Cache TTL. The problem is that Edge Cache TTL will override the Cache Control header set by the origin. So instead of using Edge Cache TTL, I’d suggest you try to set Browser Cache TTL: Respect Existing Headers on the Dashboard and leave the Page Rule with just Cache Everything, but not Edge Cache TTL.

Imunify360 even has a blog post about this issue;

1 Like