Exposed .git Vulnerability
An exposed .git directory allows anyone to download your Git repository, including source code, commit history, and sometimes sensitive configuration. This guide explains how to detect exposed .git directory vulnerabilities and fix them.
What Is an Exposed .git Directory?
The .git directory stores Git metadata and object files. When a web server is misconfigured to serve this directory, attackers can access it and reconstruct the repository. They may obtain source code, credentials in config files, API keys, and internal paths. This is a common deployment mistake when the web root includes the .git folder.
The .git directory contains HEAD (current branch), config (repository settings, sometimes remotes with credentials), objects (compressed file and commit data), refs (branch and tag pointers), and index. Tools like GitHack can recursively fetch these files and reconstruct the full repository. Even partial exposure of HEAD and config can reveal sensitive information.
Risks of Exposed .git
- Source code exposure: Entire codebase can be downloaded and analyzed
- Credentials: Config files may contain secrets and API keys
- Internal structure: Attackers learn about your architecture and endpoints
- Compliance: Code exposure can violate compliance requirements
Common Deployment Mistakes
Deploying with git clone or copying the entire project folder including .git is the most common cause. Some CI/CD pipelines or FTP deployments copy the whole directory. Shared hosting or manual uploads often include .git by default. Always use build outputs (e.g. npm run build, dist folder) or deployment artifacts that exclude .git. For related exposure risks, see our hidden files exposure guide.
Prevention Checklist
- Deploy only build artifacts, not the full repo
- Use git archive or rsync with exclude patterns
- Verify .git is not in the web root before go-live
- Add .git to .gitignore for deployment packages
How to Detect Exposed .git
Test for exposed .git by requesting /.git/HEAD or /.git/config. If the server returns file contents instead of 403 or 404, the directory is exposed. Vulnify's exposed paths checker tests for .git and other sensitive paths. A full website vulnerability scanner also checks for this during a scan.
curl -I https://example.com/.git/HEADIf you get a 200 response with content, the .git directory is exposed. Fix immediately by removing .git from the web root or configuring the server to deny access. Also check subpaths like /.git/config and /.git/refs/heads/main.
How to Fix Exposed .git
Remove the .git directory from the web root. Do not deploy the full Git repository to production; only deploy the built artifacts. Use deployment scripts that copy only necessary files. Configure the web server to deny access to hidden paths if .git must remain for any reason.
For Nginx, add location ~ /\.git { deny all; }. For Apache, use <DirectoryMatch "\.git"> Require all denied </DirectoryMatch>. After removal, rotate any credentials that may have been in config or committed to the repo. Assume the code was downloaded; treat it as a breach and follow incident response procedures.
Fix Checklist
- Remove .git from the web root or document root
- Update deployment process to exclude .git
- Rotate any exposed credentials or API keys
- Re-scan to confirm the exposure is fixed
Frequently Asked Questions
How do I check if my .git is exposed?
Use Vulnify's exposed paths checker or request /.git/HEAD manually. If you get file contents, it is exposed.
What if I already exposed .git?
Remove it immediately. Rotate any credentials that may have been in the config. Assume the code was downloaded.
Can I block .git without removing it?
Yes. Configure the web server to deny access to /.git. However, removing .git from the web root is the recommended fix.