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.
ebiester•42m ago
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.
7777777phil•41m ago
This could have been the post.
trollbridge•39m ago
Is there a reason you couldn’t have just posted that instead of the LLM generated slop you posted in the website?
gregglain•35m ago
What about have the output directory outside the repo?
tminuslabs•2d ago
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.
ebiester•42m ago
It's not an anti-ai screed. It's that the official post was... unnecessarily wordy.
7777777phil•41m ago
trollbridge•39m ago