CloudFlare Cache Bug could Destroy your Company

While moving Debauc.us over from NextJS to Astro, a very interesting 'feature' was discovered that could lead to your site being improperly indexed and you can do nothing about it!

Cloudflare is an amazing start point.

Lets start being clear, I love Cloudflare. As an early user and having a site that needs to be protected more and more from the actions performed by people on the web, Cloudflare stands out as a massive value win.

DDoS Protection.
CDN that is arguably unmatched.
Pages offering free website hosting + functions.
Email handing of the domains.
Logging isn't an additional charge and fully open to view and monitor.

I could go on and on, but enough glazing. My issue today comes from a very specific feature I've already mentioned. The CDN (Content Delivery Network) is an amazing free service allowing your site to load much faster by placing copies of your website near to the user using its massive data centre infrastucture.

A large redesign.. and the problem with that.

Like many others, I thought it was time for a change! A new design on my blog and an example to try out the recently aquired Astro (which Cloudflare bought). Astro is designed with the main concept being to send HTML directly to the user, rather than the NextJS/React method of a basic container DOM which is populated with Javascript bundles.

I got a basic framework done (as you can now see) and proceeded with publishing the site to Cloudflare Pages. In doing so, I found out about a very bizarre and unexpected behaviour.

Astro Sitemap is an awesome bundle thats provided by the Astro team to generate on build automatically, so of course I used this. Astro Sitemap does what is usually done by default for extremely large websites, creating an index sitemap of all the other sitemaps.

<sitemapindex>
	<sitemap>
		<loc>https://debauc.us/sitemap-0.xml</loc>
	</sitemap>
</sitemapindex>

In my blogs case, this provides a link to (up to many) sitemaps that could cover many more pages then 1 sitemap. For large websites this is perfect, for my simple blog, I'll likely never fill up the first one.

However, this did uncover the bug! My old NextJS blog used /sitemap.xml which never got replaced when moving over to the new site. After about 2 hours of the new website being up I noticed this during my usual checks to make sure everthing worked correctly and seeing pages that existed still that shouldn't.

Cloudflares Cache has Problems.

Cloudflares CDN didn't delete the old pages from my previous Pages website, even when I changed entire frameworks. The pages on /blog/ and /tags/ continued to exist in both the sitemap.xml and the direct pages being served to users and robots. This was a problem, a big one.

Duplicate content is a huge issue, dead old pages is a huge issue, incorrectly returning a page that should be 404 is an issue! I started to panic, what did I do wrong? Did I miss a key setting or a certain value? Are you not supposed to switch frameworks on pages without deleting first? I had no idea.

Thankfully, Cloudflare does have a Discord Server with real people working on the teams in it. Credit where its due, I did get a response to the issue telling me to purge the cache with "Purge Everything" and it will all be cleared up soon enough. But I already did that..

After more talking with the team ( I don't want to name names as it's not the fault of the enginner I was talking to ) I discovered the cause of the issue, and my mind wondered how it could be used maliciously against myself and others.

Purge Everything.. doesn't Purge anything?

The caching system in Cloudflare works as follows:

The file/page is cached for the user in datacentres around the world.
"Purge Everything" and "Custom Purge" where you specify the URL to purge, mark it for deletion.
However, if the page is accessed, the cache is renewed on that page.

This is where the problem lies. Sitemaps specifically have long cache times, 24 hours from what I've seen on my browser from Cloudflares header responses. Addtionally, its done data centre by data centre. After 48 hours the US data centre near the Cloudflare engineer helping me with this issue was getting a 404 from my old sitemap, where as me on LHR still got it! Now I have mismatched URL's for the sitemap too!

It's now been 5 days since I first published (at the time of writing) the new design with the new sitemap stucture and still on LHR requests the old sitemap is served to the robots and users who happen to load that URL, keeping this zombie cache file alive. Triggering direct cache purges and full purges, do not work.

Waiting to be abused.

Say you have a rival website, say you know they use a Cloudflare CDN and they are about to launch a large site change, or you notice its just happened. Unless they happened to match every page URL 1-1, you can now simply ping any old content and keep it alive as long as your script runs.

This isn't a CVE level issue, by any means, but the fact you as a site owner seem unable to actually tell Cloudflare "I want this page deleted, and I want it deleted now", for whatever reason you may have over the network is bonkers to me.

For now the old sitemap still persists! I've actively monitoring it to see if the purge does eventually trigger of if there is a timeout involved. I will update this post if anything does happen to it.