Exposed .git directories are back — blame misconfigured CDNs
A CDN migration pattern we keep seeing re-exposes .git on production origins. One curl command tells you if you are affected; one config line fixes it.
A CDN migration pattern we keep seeing re-exposes the .git directory on production origins, handing attackers your full source history. One curl command tells you if you are affected.
Why it happens
During a CDN migration or when adding a WAF, teams often add a Cache-Control or a rewrite rule to a CDN edge (Cloudflare Workers, CloudFront, Fastly…) that tells the edge:
"proxy everything to the origin"
…without realising that /.git/ has been added as an origin-only path on the CDN side. The CDN caches and serves .git/HEAD, .git/config, .git/logs/, and eventually .git/objects/pack/*.pack.
How to check
curl -s https://yourdomain/.git/HEAD | head -1
If you get a ref: refs/heads/main (or similar), you're affected.
The fix
- Remove
/\.git/from origin-only or allowlist rules on your CDN. It should be blocked at the edge. - If you control the origin web server, add a rule to block
.gitentirely. In Nginx:location ~ /\.git { deny all; return 403; }. In Apache:<DirectoryMatch "/\.git"> Require all denied </DirectoryMatch>. - Rotate all credentials in your git history. If
.gitwas exposed, someone already has your source code — including env and config. Treat your repo's credentials as compromised and rotate them all.
The pattern we are seeing
Most of the affected clients were migrating from a self-hosted static site to Cloudflare Pages, or switching from one CDN to a managed WAF. The migration process involves adding new origin rules to the CDN, and it is surprisingly easy to forget that .* in an origin rule includes .*\.git/.*.