Author here. Short version: my Cloudflare Pages build output directory was the repo root, so every committed file was a public URL, including a 150KB internal handoff doc and dot-directories like .claude/ and .github/. No credentials or customer data, but the doc described an admin query parameter that skipped checkout and an unfixed hole in my own schema.
The parts I think are useful beyond my own mistake:
- Two "purge everything" runs did nothing. The headers showed cf-cache-status: DYNAMIC with an age that kept climbing, so the stale copy was in a layer the zone purge doesn't reach. The custom domain served the old file while the pages.dev domain served the clean one.
- A cache-busted request (?cb=random) tells you whether the origin is clean. It does not tell you whether a visitor can still fetch the file. I used it to "verify" the fix twice and was wrong both times.
- What actually closed it was a firewall rule on the path, which runs before cache.
- Rotating the leaked admin string bought almost nothing, because the check was client-side and the value was in the page source all along. The real fix was closing the server-side hole.
Worth a minute: curl your own production domain for README.md, .git/config and your CI files with a plain request. Happy to answer questions.
What about have the output directory outside the repo?
Author here. Short version: my Cloudflare Pages build output directory was the repo root, so every committed file was a public URL, including a 150KB internal handoff doc and dot-directories like .claude/ and .github/. No credentials or customer data, but the doc described an admin query parameter that skipped checkout and an unfixed hole in my own schema.
The parts I think are useful beyond my own mistake:
- Two "purge everything" runs did nothing. The headers showed cf-cache-status: DYNAMIC with an age that kept climbing, so the stale copy was in a layer the zone purge doesn't reach. The custom domain served the old file while the pages.dev domain served the clean one.
- A cache-busted request (?cb=random) tells you whether the origin is clean. It does not tell you whether a visitor can still fetch the file. I used it to "verify" the fix twice and was wrong both times.
- What actually closed it was a firewall rule on the path, which runs before cache.
- Rotating the leaked admin string bought almost nothing, because the check was client-side and the value was in the page source all along. The real fix was closing the server-side hole.
Worth a minute: curl your own production domain for README.md, .git/config and your CI files with a plain request. Happy to answer questions.
Is there a reason you couldn’t have just posted that instead of the LLM generated slop you posted in the website?
Sorry, but I'd have rather read this than the LLM output. This writeup was worth my time.
It's not an anti-ai screed. It's that the official post was... unnecessarily wordy.
This could have been the post.