🤖 Ghostwritten by Claude Opus 4.6 · Fact-checked & edited by GPT 5.4 · Curated by Tom Hundley
If your website serves /.git/config, attackers may be able to see repository URLs, branch metadata, and in some cases embedded credentials such as personal access tokens. The immediate fix is to block public access to .git, but that is only half the job. If credentials were ever exposed, you should assume they may have been harvested and rotate them.
A 2026 report from Mysterium VPN said its internet scan found 4.96 million publicly accessible .git directories and 252,733 exposed .git/config files containing deployment credentials. We have not independently verified that study, so treat those figures as reported, not confirmed. The underlying risk, however, is well established: exposed .git directories can allow source-code reconstruction, and .git/config sometimes contains remote URLs with embedded usernames or tokens.
If you've been building with Cursor, Bolt, Replit, Lovable, or another AI coding tool and then deploying quickly, this article is for you. Previous articles in this series covered how to check if your .git folder is exposed and how to fix it before you deploy. Here we'll focus on what can leak from .git/config, how attackers use it, and what to rotate first.
TL;DR: .git/config often reveals repository remotes and workflow details, and sometimes includes embedded credentials that should be rotated immediately.
Git creates a hidden .git directory in your project to store version history and repository settings. One of the files inside it is .git/config, which defines remotes, branches, and other local repository settings.
A risky example looks like this:
[remote "origin"]
url = https://USERNAME:YOUR_TOKEN@github.com/your-org/your-private-app.gitThat pattern is dangerous because the URL itself contains a credential. If that file is public, anyone who can fetch it may be able to reuse the token, depending on whether it is still valid and what permissions it has.
| Exposed information | Potential attacker impact |
|---|---|
| GitHub or GitLab remote URL with embedded token | Clone or modify repositories if the token is still valid and has sufficient scope |
| Repository URL and naming conventions | Identify private projects, environments, and likely deployment targets |
| Branch names and remote tracking | Infer release workflow and CI/CD structure |
| Submodule remotes | Discover additional repositories or third-party dependencies |
Not every .git/config file contains secrets. Many only contain remote URLs without credentials. But when credentials do appear, the risk moves from information disclosure to possible account or supply-chain compromise.
TL;DR: The problem usually comes from deployment shortcuts, not AI itself: copying the whole project, building containers too broadly, or using credential-filled remote URLs.
AI coding tools can speed up setup and deployment, but the exposure usually happens through ordinary operational mistakes.
1. Uploading the entire project directory. If you deploy by copying your whole working folder to a server, .git may go with it. On many web servers, hidden directories are not automatically blocked.
2. Container builds that copy too much. A Dockerfile with COPY . . can pull .git into the build context unless you exclude it with .dockerignore. Whether it becomes web-accessible depends on how the image is built and served, but it is a common way Git metadata ends up in production artifacts.
3. Embedding credentials in remote URLs. Some developers still use HTTPS remotes with usernames and tokens in the URL. AI assistants may reproduce that pattern if prompted poorly or if they mirror an existing local setup. As we covered in AI coding tools and secret leak rates, fast scaffolding can also reproduce insecure defaults unless you explicitly guard against them.
The lesson is simple: faster deployment increases the cost of skipped review.
TL;DR: Test /.git/config, block access if it is reachable, and rotate any token or password that appeared there.
Open a browser and visit:
https://yourwebsite.com/.git/configReplace yourwebsite.com with your actual domain.
404 Not Found, 403 Forbidden, or another denial response: good sign, though you should still verify server rules and deployment contents.[core], [remote], or similar Git config sections: your Git configuration is exposed.A browser check is a quick first pass, not a full audit. Also test common Git paths such as /.git/HEAD and verify your deployment process does not ship .git at all.
If a credential appeared in a public file, assume it may have been collected by scanners.
For GitHub personal access tokens such as ghp_, github_pat_, and related formats:
For GitLab personal access tokens such as glpat-:
For passwords or other secrets:
Paste this into your AI coding tool:
"Add security rules to block public access to the
.gitdirectory and other hidden files. Show me configurations for Nginx, Apache, Vercel, and Netlify. Also add a.dockerignorefile that excludes.gitif I'm using Docker."
For implementation details, see the full .git config credentials guide.
Paste this into your AI tool:
"Review my deployment configuration. Make sure no Git credentials are embedded in repository URLs. Show me how to use SSH keys or environment-variable-based authentication instead of URL-embedded tokens. Also verify that my
.gitdirectory is excluded from production builds."
TL;DR: Blocking stops new exposure, but it does not invalidate credentials that may already have been copied.
Most remediation guides stop too early. They tell you to deny access to .git and move on. That prevents future downloads, but it does not change the status of any token, password, or key that was already visible.
The Mysterium VPN report says it found 252,733 servers with credentials in .git/config. We have not independently verified that number, but the remediation logic is the same either way: if a secret was public, rotate it.
Also review your GitHub Actions configurations for supply chain risks. A compromised source-control token can sometimes be used to alter workflows, inject malicious code, or tamper with future deployments, depending on repository permissions and branch protections.
TL;DR: Ask your AI tool to audit secrets, deployment contents, and authentication methods in one pass.
Paste this into Cursor, Bolt, or your preferred AI coding tool:
"Audit my project for security issues: (1) check whether any credentials, tokens, or passwords appear in
.git/configor URL strings, (2) check whether.gitcould be included in a production deployment, (3) generate a.gitignoreand.dockerignorethat exclude sensitive files and build artifacts, and (4) show me how to move any discovered credentials into environment variables or a secrets manager instead."
The .git directory is Git's local metadata store. It exists in your working project folder by default. It reaches a web server when you deploy the entire project directory instead of only the files needed to run the application.
Often, yes. If enough Git metadata is accessible, attackers can use publicly available tools to rebuild much or all of the repository history. The exact result depends on which files are exposed, but the risk is real and well documented.
Not necessarily. Blocking access prevents new downloads, but any credential that was previously exposed should be rotated. You should also review repository activity, deployment logs, and authentication events for signs of misuse.
Their standard managed build workflows typically do not publish the .git directory as part of the site output. But custom deployments, self-hosted environments, reverse proxies, or manual uploads can still create exposure. Verify your actual deployment path rather than assuming the platform covers every case.
Use SSH keys where appropriate, short-lived credentials where supported, and platform-managed secrets or environment variables for deployment automation. The goal is to keep credentials out of repository files, shell history, and build artifacts.
.git directories can leak repository metadata and sometimes live credentials..git directories and 252,733 credential-bearing .git/config files; those figures are reported, not independently verified here..git is necessary, but rotating exposed credentials is the critical remediation step./.git/config, /.git/HEAD, and your deployment pipeline today.If your site exposes .git/config, treat it as a security incident, not a minor cleanup task. First block access. Then rotate anything that was visible. Finally, fix the deployment process that allowed .git into production in the first place.
If you want a second set of eyes on your deployment pipeline, secret handling, or AI-assisted development workflow, Elegant Software Solutions can help you review the weak points before they become an incident.
Discover more content: