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.
At a glance
What this is: This research shows that publicly exposed git directories can disclose source code and active credentials, turning a web misconfiguration into a secrets exposure problem.
Why it matters: It matters because identity teams and app security teams need to treat repository exposure, secret leakage, and revocation as one governance problem, not separate tasks.
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.
- The first round returned 255 leaked keys, and the second round returned 97 leaked keys.
👉 Read Truffle Security's analysis of exposed git directories and leaked secrets
Context
A publicly exposed .git directory is not just a source-code hygiene issue. It can expose repository history, configuration files, and credentials that were never meant to be reachable from the web, which turns a simple server mistake into an NHI and secrets management problem.
The control gap is familiar: teams often secure the application while leaving build artefacts, repository metadata, and embedded credentials outside the same governance boundary. Secret sprawl challenge becomes visible here because the repository becomes both the leak source and the discovery surface.
For identity and access teams, the important distinction is that leaked credentials are still identities until they are revoked. If a token, key, or certificate can authenticate, then exposure has already crossed into lifecycle and privilege governance.
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. Revoke and rotate the exposed secrets, review the downstream SaaS and storage accounts they can reach, and verify whether other credentials were stored in the same location. Self-hosted systems demand the same lifecycle discipline as any production identity platform.
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. A single leaked key can grant write access, runner control, or deployment visibility across multiple services. That turns a source-control incident into an identity governance event, with blast radius determined by privilege scope rather than repository size.
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.
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.
Technical breakdown
Why exposed .git directories reveal more than source code
A .git directory contains the working history of a repository, not just the latest application files. That means commit metadata, configuration files, paths, and sometimes embedded secrets are all recoverable if the directory is reachable from the web server. The practical security issue is that attackers do not need to exploit the application itself first. They can reconstruct the repository, inspect old commits, and search for credentials that were never removed from version control. This is why exposed repository metadata is a discovery and credential exposure problem, not only a file disclosure issue. Read Guide to the Secret Sprawl Challenge.
Practical implication: Treat exposed repository metadata as a secret exposure event, not a routine misconfiguration.
How leaked API keys turn repository exposure into identity abuse
API keys, GitHub tokens, and similar non-human credentials can authenticate directly to third-party services. Once an attacker finds them in code or config files, the next step is not necessarily exploitation of the website, but use of the credential itself against the downstream platform. Truffle Security's data shows why this matters: leaked keys often carry real permissions, and some have admin-level scope. In NHI terms, the repository is only the discovery mechanism. The real security failure is that the credential retained its authority even after it escaped the intended boundary. See the API Key Management Guide.
Practical implication: Scope every exposed credential by downstream permission, not just by where it was found.
Why key verification is not the same as safe exposure handling
The article distinguishes verified secrets from unverified ones because authentication success proves the credential still works. That matters operationally: an unverified key may still be live, but a verified one removes doubt about impact and urgency. This is a lifecycle problem because discovery does not end the risk. Once a key has escaped into public systems, crawlers, archives, and attackers may all preserve copies. The control question is therefore not whether a leak was found, but whether the credential was revoked, rotated, and removed from all places it can still be used. See the Leaked Credential and Secret Incident Response Playbook.
Practical implication: Use verification results to prioritise revocation, then confirm the exposed credential is no longer accepted anywhere.
Threat narrative
Attacker objective: The attacker wants working credentials and source intelligence that let them control related systems, not just read the website code.
- Entry occurs when a public web server exposes a .git directory, allowing repository contents to be enumerated without breaking application access controls.
- Credential access follows when attackers recover API keys, GitHub tokens, or private keys from source code, config files, or commit history.
- Escalation happens when the recovered credentials grant repository admin rights or access to third-party services with broader privileges than the website itself.
- Impact includes arbitrary repository actions, data access, and in some cases man-in-the-middle capability through exposed private TLS keys.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Verified secret leakage is the operational proof that revocation, not detection, is the control boundary: discovery alone only tells you that a credential existed in public. Verification tells you whether it still works. In NHI terms, the meaningful control failure is the persistence of authority after exposure, which means the governance process failed to remove the identity's usable state quickly enough.
Overprivileged leaked tokens create identity blast radius: the article's 67% admin-access figure shows that exposed credentials are often not low-value artefacts. When a leaked token can modify repositories or reach connected services, the scope of compromise extends well beyond the initial site. That is a privilege design problem, not merely a leakage problem, and it should be governed as such.
Exposure windows are unstable, so static review models undercount real risk: the drop from 255 leaked keys to 97 in a later scan shows that exposure is dynamic, not fixed. A point-in-time audit can miss newly exposed credentials or overstate cleanup progress if leaked copies have already been archived elsewhere. The practitioner implication is that secret governance has to assume persistence outside the primary system of record.
Credential leakage and source-code leakage are the same incident class when the repository holds active trust material: this is the specific concept practitioners should track as identity blast radius. A repository leak becomes a governance failure when it contains authentication material that can be used outside the source system, because the compromise path crosses from code handling into identity authority.
From our research library:
- 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.
- Read next: Leaked Credential and Secret Incident Response Playbook
What this signals
Credential blast radius is the concept to watch: a leaked repository is dangerous because it can expose authentication material that outlives the original deployment path. When a key is still valid after disclosure, the risk is no longer theoretical and the control failure has already moved into downstream systems. Organisations should align repository controls, secret scanning, and revocation into one operational motion rather than separate queues.
The next programme question is how to break the link between code publishing and credential authority. Teams that still rely on manual cleanup after exposure will keep discovering that verification, revocation, and historical commit review are not optional follow-up tasks but part of the same incident boundary.
For practitioners
- 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.
- Replace static secrets with stronger trust patterns Move high-risk integrations away from long-lived API keys where possible and use narrower, short-lived authentication paths with clear ownership.
Key takeaways
- Public git directory exposure becomes an identity security issue when repositories contain active credentials that can authenticate elsewhere.
- The research shows both scale and privilege depth, with thousands of exposed repositories and many leaked keys carrying real access rights.
- The decisive control is not detection alone but rapid revocation, combined with preventing repository metadata from being published in the first place.
Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · API Key Management Guide · Leaked Credential and Secret Incident Response Playbook · Secrets Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on exposed secrets in public git directories and their continued reuse risk. |
| NHI-07 — Long-Lived Secrets | Leaked API keys and tokens remained valid long enough to be used after discovery. | |
| NHI-05 — Overprivileged NHI | Many leaked GitHub credentials had admin-level rights, expanding the blast radius of disclosure. | |
| Recommendation — Scan repositories for exposed secrets and revoke any credential found outside approved storage immediately. Replace long-lived API keys with shorter-lived credentials and eliminate static secrets from repositories. Reduce credential scope so leaked non-human identities cannot modify repositories or connected services. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | Attackers recover credentials from exposed repositories and can then use them to reach downstream systems. |
| Recommendation — Map exposed repository findings to credential access and exfiltration activity in your detection and response pipeline. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article shows leaked credentials often retain broad permissions after exposure. |
| Recommendation — Review and tighten entitlements for exposed credentials before they are reused against connected systems. | ||
Key terms
- Git Directory Exposure: A Git directory exposure occurs when repository metadata is reachable from a public server and can be downloaded without authorisation. That metadata may include source code history, configuration files, and embedded secrets, which turns a development artefact into a live security exposure.
- Verified Secret: A verified secret is a credential that has been checked against the target service and confirmed to be valid or active. This is more actionable than a pattern match because it indicates a real access path, not just a string that resembles a token.
- Credential Blast Radius: Credential blast radius is the amount of access, data, and system reach that a single compromised secret can unlock. The wider the blast radius, the more damage one leaked token or certificate can cause. Reducing it requires tighter scope, faster revocation, and better segmentation.
- Repository Secret Sprawl: Repository secret sprawl is the accumulation of credentials across source files, commit history, configuration artefacts, and deployment materials. It makes cleanup difficult because the same secret can persist in multiple places, often long after developers believe it was removed.
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
Deepen your knowledge
NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org