Topic starter
19/10/2026 5:39 pm
TL;DR: Truffle Security's research finds publicly exposed .git directories can leak source code, live API keys, and other credentials at scale, with 4,500 heavily visited websites exposing repositories and many valid tokens. Secrets discovery is not enough when exposed credentials remain live and broadly privileged.
Editorial analysis by NHI Mgmt Group, based on content published by Truffle Security: “4,500 of the Top 1 Million Websites Leaked Source Code, Secrets”.
By the numbers:
- 4,500 heavily visited websites publicly exposed source code through their git directory.
- AWS and GitHub keys accounted for 45% of all leaked credentials.
- 67% of GitHub credentials had admin access.
Key questions
Q: How should teams respond when a self-hosted repository exposes secrets?
A: Treat the repository as only one part of the problem.
Q: Why do exposed repository secrets create a broader IAM problem than a simple code leak?
A: Because many repository secrets are live access paths into cloud, CI/CD, and vendor systems.
Q: How do security teams know whether a leaked secret still matters?
A: They verify liveness. A leaked secret matters most when it still authenticates, still has broad scope, or still maps to a privileged workload or service account. Teams should combine detection with ownership, scope review, and immediate rotation so that the remediation queue reflects real access risk rather than scan noise.
Practitioner guidance
- Remove .git from public web roots Verify that production servers do not serve repository metadata and block requests to .git paths at the web server layer.
- Scan source and history for live credentials Search current files, historical commits, and deployment artefacts for API keys, tokens, and private keys before they reach production.
- Revoke exposed secrets immediately Treat any verified leaked credential as compromised and invalidate it before assuming archive copies or crawlers have finished propagating it.
Bottom line: Public git directory exposure becomes an identity security issue when repositories contain active credentials that can authenticate elsewhere.
What's in the full report
Truffle Security's full article covers the operational detail this post intentionally leaves for the source: the scanning method used to find exposed .git directories, the verification workflow for live credentials, and the disclosure and remediation process.
- How the researchers identified valid .git directories despite WAF behaviour and partial server responses
- The exact workflow used to reconstruct repositories and verify whether discovered secrets were still live
- Step-by-step disclosure attempts, including the email and contact methods used to reach affected owners
- Detailed prevention guidance for removing .git from production servers and blocking secrets from version control
👉 Read Truffle Security's analysis of exposed git directories and leaked secrets →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/10/2026 5:39 pm
Repository exposure is now a secrets governance problem, not a web hygiene problem: once .git is reachable, the organisation has already lost control of both code and identity material. The exposed object is not only the repository but also every credential ever embedded in it, including old commits and config files. That changes the ownership model from application operations to identity lifecycle governance, because the credential must be assumed live until proven otherwise.
A few things that frame the scale:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What is the difference between source code exposure and secret exposure in a git incident?
A: Source code exposure reveals application logic and repository history, while secret exposure reveals usable trust material such as API keys, tokens, and certificates. In practice, the second issue is more urgent because it can immediately affect downstream systems, even if the code itself is never modified.
👉 Read our full editorial: Exposed git directories keep source code and API keys leaking