Reference · LeakTrace Intelligence Team
Exposed .git directory on a production web server
A production web server exposes its `.git/` directory over HTTP, allowing anyone to reconstruct the full source tree, including secrets committed to history.
Pattern summary
- Category
- Code / repository leak
- Severity
- Critical
- Prevalence framing
- Frequently observed in firms that deploy by rsync or manual git pull without excluding hidden directories.
- Remediation effort
- Trivial
- Verticals affected
- All
When a codebase is deployed to a web server by cloning or pulling a git repository into the document root, the `.git/` directory ends up publicly accessible unless the web server is explicitly configured to block it. Anyone who requests `https:///.git/config` and gets a 200 response can then use standard tooling to reconstruct the entire source tree, commit history, and any secrets that were ever committed and later removed.
## Why attackers exploit it
Reconstructed source often contains database credentials, API keys, third-party integration tokens, and unsanitized customer data used in test fixtures. Even a "clean" current head can have secrets in history that a rotation swept from the working tree but not from the git objects.
## Remediation direction
Immediate: block `.git/`, `.svn/`, and `.hg/` at the web server or CDN layer. Longer-term: deploy from a build artifact, not from a live git checkout. If any secret ever appeared in commit history, rotate that secret regardless of whether it appears in the current tree.
Concerned this pattern touches your exposure surface?
LeakTrace runs continuous intelligence on principals, households, and advisor tenants across every observable public exposure surface. Discovery call under mutual NDA, first-touch reply within one business day from an authenticated LeakTrace address.
See services and pricing