Guides · ← All guides
Exposed .git Directory: What It Leaks and How to Check
Last updated: October 31, 2026 · Reviewed October 2026 · 7 min read
Of the 33 sensitive paths BreachHunter probes — the full module list is here — the exposed .git directory is the one that turns a minor misconfiguration into a full compromise. It happens innocently: a site gets deployed by copying a working folder to the server, and the hidden .git folder rides along. The site works fine. So does the download of your entire codebase, for anyone who asks.
How does a .git directory end up in your web root?
Git stores everything about a repository — every file version, every commit, every branch — in the .git folder at the project root. Deploy by dragging the project folder onto a server, syncing it with a tool that includes hidden files, or cloning the repo directly into the web root, and that folder ships with it. Web servers happily serve it: nothing in a default configuration tells them not to. The site owner sees a working site. A scanner sees an open archive.
What exactly leaks when .git is exposed?
| File an attacker requests | What it gives them | BreachHunter severity |
|---|---|---|
| /.git/HEAD | Confirmation the repository is exposed, and the current branch pointer — the starting thread for full reconstruction | CRITICAL |
| /.git/config | Your repository's remote URLs — which can embed live credentials (tokens inside https URLs) — and your repo host and project name | CRITICAL |
| /.git/logs/HEAD | The reflog: commit history, branch names, and the map of objects to download next | HIGH |
| The objects themselves | Every committed file at every committed version — source code, configuration, and secrets that were later removed | — |
Source: SENSITIVE_PATHS table, BreachHunter engine (app/pentest.py), read October 31, 2026. The last row is the one that matters: the first three files are just the index. The objects they point to are the library.
How do attackers rebuild the tree?
Slowly and mechanically — which is why it scales. Starting from /.git/HEAD and the reflog, a tool requests the commit objects, then the tree objects those commits name, then every blob in every tree. Git objects are stored compressed, but they are not encrypted, and the paths are predictable hashes. Open-source tools automate the whole walk. The attacker ends with your repository exactly as your team has it — same history, same deleted files, same key you committed in March and removed in April. Deletion is not erasure in git; it is just the newest commit. Our companion investigation covers the archive side of the same problem: deleted files the web archive keeps serving.
How do you check your own site in 30 seconds?
Ask your server for the file, the way a stranger would:
curl -I https://your-site.com/.git/HEAD
A response of 200 with a body like ref: refs/heads/main means the repository is public — treat it as urgent. A 403 or 404 means your server is already blocking it. Then run the free BreachHunter scan, which checks all three git paths plus the other 30 sensitive files in about a minute, so you are not relying on one manual probe.
How do you fix an exposed .git directory?
Three steps, in this order. First, block it at the server layer today. On nginx:
location ~ /\.git { deny all; }
On Apache:
RedirectMatch 404 /\.git
Second, remove it from the deploy. Ship a build artifact — an archive of the built site — instead of the working folder, so no .git exists on the server to protect. Third, rotate. Every secret that ever entered the repository's history — database passwords, API keys, tokens in remote URLs — must be revoked and reissued. Closing the door does not un-copy what may already have been downloaded. If you are working through a full scan report, our triage guide explains where this finding sits in the fix order (spoiler: first).
Check your site for an exposed .git — free scan →
Frequently asked questions
How do I check if my .git directory is exposed?
Request https://your-site.com/.git/HEAD in a browser or with curl. If you see a line like 'ref: refs/heads/main', your repository metadata is public. A 403 or 404 means the server is blocking it, which is what you want. BreachHunter checks /.git/HEAD, /.git/config and /.git/logs/HEAD automatically on every scan.
If I delete a secret from my code, is it gone?
No. Git keeps every committed version. A key removed in a later commit is still readable in the earlier one, and an exposed .git directory hands an attacker the whole history. The only safe response to a leaked secret is rotation: revoke the old key and issue a new one.
Does an exposed .git directory mean I have been hacked?
Not necessarily — it means the door has been open, not that anyone walked through it. Treat it as urgent anyway: automated scanners probe for /.git constantly, and you cannot prove a negative from your own logs. Close it, then rotate any secret that ever touched the repository.
What is the fastest safe fix?
Deny web access to /.git at the server layer (one rule in nginx or Apache), verify the path now returns 403/404, and redeploy from a build artifact that does not contain the .git folder at all. Then rotate the secrets in the repository's history.