Your website is quietly serving its own source code at /.git

You built the site, tested it, and pushed it live. It works. Pages load, the contact form sends, nothing is on fire. What you can’t see is that when the files were copied to the server, a hidden folder rode along with them — the .git folder, the version-control record that sits quietly in the root of nearly every modern codebase. It was never meant to leave your machine. Now it’s sitting on the public web, one folder above your home page.

That folder isn’t a couple of stray files. It’s the complete history of your project: every version of every file, the structure of your whole codebase, commit messages, and often — because someone once committed a config file “just to get it working” — database passwords, API keys and live deployment credentials. Anyone who knows to look can walk up to yoursite.com/.git/, download the lot, and reconstruct your entire application on their own laptop. They don’t need to break in. You’ve published the blueprints, and often the keys, next to the front door.

That’s the quiet failure: not a break-in, but the working copy’s hidden paperwork, deployed straight to the internet because nobody told it to stay behind.

Why it stays invisible

Nothing about this breaks the site. Your visitors never touch /.git, your pages render exactly as intended, and no error is thrown. The folder is hidden by design — the dot at the front of the name keeps it out of ordinary file listings — so unless you deliberately go looking for it, you’d never know it made the trip.

The reason it’s there at all is the way many sites get deployed. If the “deploy” step is really “copy the whole project folder to the server” — an FTP upload, an scp, a git clone straight into the web root, a git pull to update in place — then the .git folder is part of the project folder, so up it goes with everything else. The web server, for its part, will happily serve any file under its root that it hasn’t been told to hide. It has no idea that /.git/config is different from /about.html.

And it’s remarkably common. A Mysterium VPN study published in February 2026 found roughly 4.96 million web servers openly serving their .git metadata to the internet — and 252,733 of the exposed .git/config files contained live deployment credentials.

What makes it worse than most exposures is the payload. A misconfigured page leaks one page. An exposed .git folder leaks the entire project and its past — including secrets you removed from the current version but that still live in an earlier commit, exactly where you can’t see them and an attacker can.

Find it yourself

You can check your own site in about a minute, and the fuller audit in ten. No tools required.

1. Open the config file in a browser. In the address bar, type your site followed by /.git/config — for example https://yoursite.com/.git/config — and press Enter. If you’re safe, you’ll get a normal “404 Not Found” or a redirect to your home page. If you’re exposed, you’ll see a short block of text that starts with [core] and usually includes a [remote "origin"] section with a url = line. That’s your repository’s own configuration, served to the open web.
2. Try one more address to be sure. Load /.git/HEAD the same way (https://yoursite.com/.git/HEAD). An exposed site returns a single line like ref: refs/heads/main. A safe one returns an error page. Two positives means the folder is genuinely reachable, not a fluke.
3. Check the sites you forgot you had. The main site is rarely the problem — it’s the staging server, the old marketing microsite, the client project from two years ago. Run the same /.git/config check against every domain and subdomain you’re responsible for. These forgotten deployments are where exposed .git folders live longest.
4. No time to visit each one? Ask your host. If a colleague or agency manages the deployment, one email settles it: “Does our web root contain a .git folder, and is /.git/ reachable from the internet?” A straight “no, it’s blocked” is the answer you want.

If you get the [core] block back, don’t panic and don’t start deleting things blindly on the live server — read the fix first.

The fix

Closing this has two halves: stop serving the folder now, then stop it ever shipping again.

Block access immediately. The fastest remedy is to tell the web server to refuse any request for /.git. On Apache, a rule in your config that denies requests to the .git path does it; on Nginx, a location ^~ /.git { deny all; return 404; } block does the same. If you’re on managed or static hosting (Netlify, Vercel, a shared host), check whether it already blocks dot-folders — many do — and if not, ask support to deny /.git. This shuts the door within minutes, even before you tidy up properly.

Remove the folder from the server. The folder shouldn’t be in your web root at all. Delete it from the deployed copy — but keep your actual repository safe on your own machine and in your hosted service; you’re only removing the stray copy that got published.

Treat any exposed secret as burned. If your .git folder was reachable, assume its history was downloaded. Any password, API key or token that ever appeared in a commit — even one you later removed — must now be rotated: change it at the source and issue a new one. Deleting the folder doesn’t un-leak what was already copied.

Fix the deployment so it can’t recur. The root cause is copying the whole project folder to the server. The durable fix is a build step that publishes only the finished files — most modern hosts and pipelines do this by default — or, if you must copy manually, a rule that excludes .git from the transfer. Set that once and the hidden folder never makes the trip again.

None of this needs a security team. It needs someone to type one address into a browser, see whether [core] comes back, and — for the sites where it does — close the door and change the locks that were on show.