28K Git Repositories Exposed Sensitive API Keys and Bank Info

Researchers uncovered a massive exposure during a scan of 3.5 million internet-facing hosts: over 28,000 publicly accessible .git repositories are leaking credentials, financial records, and HR documents. These repositories—meant to be hidden—are accidentally being served live on web servers, enabling automated tools to fetch commit history, metadata, and sensitive files. What’s worse, deleting a password from the current version doesn’t remove its appearance in past commits.

What Was Discovered

Using a custom tool dubbed “gitreaper,” the team sifted through 40 million likely hosts—drawn from Certificate Transparency logs—then filtered for HTTP servers exposing their Git history. The investigation revealed dozens of active secrets: more than 400 AWS access keys; over a hundred each of Stripe and OpenAI API keys; Telegram tokens; GitHub personal access tokens. Some of those remained valid during testing, meaning attackers could exploit exposed credentials immediately.

A range of internal documents was also exposed. One AWS key gave access to a bucket holding attendance and disciplinary files. In another case, a configuration file leaked payout and transaction history, revenue data, and partial bank-account details. These data leaks could be used for fraud, phishing, or corporate blackmail, especially when linked to personal or internal records.

How Small Slip-Ups Become Big Breaches

Git’s history is its downfall in many cases: once a secret has been committed—even briefly—it remains in past commits unless a history rewrite or purge occurs. Attackers now have bots that constantly scan for exposed keys, certificates, and tokens, sometimes detecting them within minutes of exposure. Removing only the live key isn’t enough if older commits still contain valid credentials. Teams must identify exposed paths like HEAD or packed-refs or files such as .env, which often still hold secrets.

To mitigate the damage, the researchers recommend immediately blocking public access to .git directories, rotating every credential found in both active and past commits, restricting each key to the minimum permissions required, and moving secrets into secure vaults or environment management systems. Secret-scanning tools, commit policies, and deployment checks that block .git path exposure are also critical. The team responsibly notified affected repository owners; several took action by removing exposed directories and rotating compromised credentials.

This isn’t a niche problem: misconfigured .git folders leave a traceable archive of everything an organization has ever committed—often with credentials embedded. The danger persists even if an offending file has been removed from the latest version. Historical leaks can continue to put organizations at risk.

Why It Matters: This incident shows that simple misconfiguration can expose a company’s entire inner workings. It’s more than just exposed credentials; it’s about internal trust, reputational risk, and breach potential. Companies must consider .git path exposure a full-blown security incident, not just a minor server oversight. What to watch: automated scanning tools, history-cleaning practices, and credential vaulting will become standard tools in prevention going forward.