Topic starter
24/08/2026 2:01 pm
TL;DR: A scan of 3.5 million active hosts found 28,000 exposed repositories and hundreds of live AWS, Stripe, and GitHub credentials, showing that open .git directories still turn routine misconfigurations into real access paths, according to Intruder. The issue is not just discovery scale: long-lived secrets hidden in repository history remain exploitable until teams govern exposure, rotation, and offboarding as an identity problem.
Editorial analysis by NHI Mgmt Group, based on content published by Intruder: “We found 28,000 .git repos sitting wide open. Here's what was inside”.
By the numbers:
- The scan recovered 400 AWS access keys, 107 Stripe API keys, 123 OpenAI API keys, 80 Telegram tokens and 17 GitHub personal access tokens.
Key questions
Q: What breaks when a .git repository is exposed on the internet?
A: When a .git repository is exposed, attackers may recover current code, deleted files, commit history and embedded credentials.
Q: Why do leaked repository secrets keep creating risk after discovery?
A: Because discovery does not remove authority.
Q: How should security teams handle exposed AWS credentials in code repositories?
A: Treat exposed AWS credentials as an active incident, not a hygiene issue.
Practitioner guidance
- Scan repository history, not just current files Use exposure tooling that walks commit history, reflogs and packed objects so deleted secrets are still detected before attackers find them.
- Treat leaked keys as active identities When a secret is exposed, immediately revoke the credential, rotate any dependent secrets and verify that the issuing account no longer has standing access.
- Inventory .git exposure across internet-facing assets Continuously check production and pre-production hosts for reachable .git directories, especially on app, admin and dev subdomains.
Bottom line: Exposed .git repositories can reveal historical commits, deleted files and still-valid credentials, so the real risk is broader than source code disclosure.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
24/08/2026 2:01 pm
Repository exposure is now a credential governance failure, not a code hygiene issue. When a .git directory is reachable on the web, the real risk sits in the history it preserves, not just the current files it serves. That means secret discovery, revocation and offboarding have to be managed as one control plane rather than separate tasks. Practitioners should treat exposed repositories as identity events with code attached.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What does repository secret leakage mean for NHI governance?
A: It means machine credentials need the same lifecycle discipline as human access, including inventory, ownership, rotation and offboarding. If a token, key or PAT can be committed into code and remain valid, then NHI governance is incomplete. Exposure control has to start before the secret ever reaches a repository.
👉 Read our full editorial: Exposed .git repositories keep leaking live AWS, Stripe and GitHub keys