Security firm Intruder has published the results of an internet-wide scan that should worry any team that has ever deployed a web application without double-checking what’s sitting in its webroot. Starting from roughly 40 million candidate targets pulled from Certificate Transparency logs and narrowing down to 3.5 million live hosts actually tested, researchers found 28,000 sites with a publicly reachable .git directory — the hidden folder Git uses to store a project’s entire version history.

Why an exposed .git folder is worse than it sounds

A misconfigured web server that fails to block access to .git effectively hands over the whole development history of an application, not just whatever code happens to be deployed right now. That distinction matters enormously: a developer who committed an API key by accident and later removed it in a follow-up commit has not actually deleted that key. It’s still sitting in the repository’s object history, retrievable by anyone who can read the .git folder, even though the live source files look clean.

To make the scan practical at this scale, Intruder built a purpose-made tool nicknamed “gitreaper” that can inspect a repository’s commit history and object store directly, without needing to clone the entire project first — a shortcut that made it feasible to check millions of hosts rather than a curated handful.

What actually turned up

The haul was substantial and, in many cases, still valid at the time of testing. Researchers recovered over 400 AWS access keys, 107 Stripe API keys, 123 OpenAI API keys, 80 Telegram bot tokens, and 17 GitHub personal access tokens embedded in exposed history and configuration files. Several of these credentials were confirmed to still be active. Beyond raw credentials, some repositories contained far more sensitive material than developers likely realized was there: payment-processor keys that could expose transaction histories, revenue figures, and partial bank account details, and in a number of cases, internal HR data including employee disciplinary records and attendance logs — evidently swept up because deployment or automation scripts referencing that data had been committed alongside application code.

Responsible disclosure, mixed results

Intruder says it notified identifiable repository owners where contact information could be established, and that several organizations responded by pulling the exposed repositories offline and rotating the affected credentials. Given the scan covered tens of thousands of sites, though, it’s a safe assumption that a meaningful share of this exposure remains live simply because ownership couldn’t be traced or the notification never reached the right person.

Closing the gap

The fix for this specific issue is not complicated, which is part of what makes the scale of the finding so striking. Intruder and other researchers recommend:

• Block any external request to a .git path at the web server or reverse proxy level — this should be a default deployment check, not an afterthought.
• If a repository has ever been exposed, assume it was copied and rotate every credential that appears anywhere in its commit history, not just in the current branch.
• Review cloud billing, API usage logs, and payment-processor activity for signs that exposed keys were actually used by someone else.
• Move secrets out of source control entirely, into a managed secrets vault or environment-based configuration, so a future accidental commit can’t leak a live credential in the first place.
• Add automated secret-scanning to the commit and deployment pipeline to catch this class of mistake before it ever reaches a public server.

The underlying lesson is one security teams have repeated for years but that keeps resurfacing at scale: deleting a secret from your current codebase is not the same as removing it from your project’s history, and an exposed .git folder makes that entire history available to anyone who thinks to ask for it.