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.
At a glance
What this is: Intruder's scan shows that exposed .git repositories continue to reveal live AWS, Stripe and GitHub credentials, turning a common misconfiguration into direct access risk.
Why it matters: For IAM and NHI teams, the issue is not just finding leaked secrets but governing their lifecycle, scope and revocation before attackers or autonomous tools can use them.
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.
Context
An exposed .git repository is not just a messy code hygiene issue. It can expose commit history, deleted files and embedded secrets that remain valid long after developers think they were removed, which makes repository exposure an access-control problem as much as a development mistake.
For IAM and NHI programmes, the relevant question is whether secret discovery, rotation and offboarding are governed as one lifecycle. A repository leak often becomes the first visible symptom of a broader control failure across credential inventory, privilege scope and revocation.
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. The failure is not just disclosure of source code. It is the exposure of historical objects that can still contain live secrets, which turns a web misconfiguration into a direct access path.
Q: Why do leaked repository secrets keep creating risk after discovery?
A: Because discovery does not remove authority. If the token remains valid, an attacker or unauthorised user can still authenticate until the issuing system revokes it, rotates it, and confirms that dependent integrations have moved to a replacement credential.
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. Revoke the key pair, rotate dependent secrets, review CloudTrail for abnormal enumeration or download activity, and check whether the credential had write or export permissions. Repository cleanup matters, but cloud-side containment decides how far the breach goes.
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.
Technical breakdown
Why exposed .git histories reveal more than the current codebase
A Git repository stores commits, trees and blobs, which means the current source tree is only one view of a longer history. Deleted files can remain recoverable through earlier commits, reflogs or packed objects, so a secret removed from HEAD may still exist in historical data. That is why scanning only the live file set misses part of the exposure surface. The technical problem is therefore not just file visibility but object history visibility, especially when repositories are reachable over the web.
Practical implication: treat repository history as part of the secret estate, not just the present code tree.
Why scale changes secret discovery economics
At internet scale, traditional repo scanners struggle because they often need to reconstruct full repositories on disk before analysis. That is expensive in storage and slow in throughput, especially when millions of hosts may need checking. Memory-based history walking changes the economics by fetching only what is needed, evaluating blobs in memory and discarding non-secrets. This matters because exposure monitoring fails when the scanning model is too heavy to run broadly and often enough.
Practical implication: build scanning methods that can operate at fleet scale, or repository exposure will outpace detection.
How live API keys and PATs turn exposure into account takeover
A secret is not merely a string in a file. An AWS access key, Stripe secret key or GitHub PAT represents delegated authority with whatever permissions were granted at issuance. If that authority remains active, an attacker can use it for cloud access, financial abuse, source code theft or follow-on social engineering. This is why leaked secrets are fundamentally an identity problem: they are machine credentials with business impact, not just sensitive content.
Practical implication: govern exposed secrets as active identities and revoke them, not just remove them from code.
Threat narrative
Attacker objective: The objective is to turn repository exposure into usable access to cloud, financial or code-hosting systems through valid credentials.
- Entry occurs when attackers or scanners discover a wide-open .git repository that exposes commit history and embedded secrets.
- Credential access follows when live AWS keys, Stripe keys or GitHub personal access tokens are recovered from historical objects or committed files.
- Impact occurs when those secrets are used to access cloud resources, payment data or private source code before revocation happens.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- 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.
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 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.
History-aware scanning is the right mental model for secret leakage. A scanner that only checks the live checkout will miss deleted files, old branches and reflog references that still contain usable credentials. The article's core lesson is that exposure often hides in object history, which makes repository scanning a better fit for in-memory traversal than for traditional disk reconstruction. Security teams should therefore validate that their exposure tooling can see beyond HEAD.
Live API keys and PATs are machine identities with standing authority. The article shows how AWS keys, Stripe secret keys and GitHub tokens can each become direct access paths once leaked. That aligns with OWASP-NHI concerns around secret leakage, long-lived secrets and overprivileged NHI. The practitioner conclusion is simple: if the credential is still valid, the incident is not historical.
Exposed secrets increasingly create an AI-assisted attack surface. The article's reference to autonomous models using public credentials against Hugging Face shows that exposure windows are shrinking as attackers automate discovery and exploitation. That does not change the underlying control failure, but it does reduce the time available for manual detection and response. Teams should assume faster weaponisation of leaked credentials than in earlier breach cycles.
Secret exposure window: the practical failure mode is the gap between publication, discovery and revocation. The article demonstrates that repositories can expose active credentials for long periods, which means the risk is not just leakage but persistence. Security leaders should measure that window as a governance metric, because every extra day increases the chance of abuse.
From our research library:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Read next: API Key Management Guide
What this signals
Secret exposure window: the critical control gap is the time between a secret entering a repository, being discovered and being revoked. The shorter that window becomes, the less value an exposed repository has to an attacker, which is why revocation speed matters as much as detection breadth.
Repository scanning should move from periodic hygiene to continuous exposure monitoring. In practice, that means checking history, not only current files, and tying findings directly to credential rotation workflows so that leaked keys are not left to age in place.
The NHI angle is straightforward: a live key in source control is a machine identity with delegated authority, not a static artifact. Once that framing changes, repository exposure becomes a lifecycle and privilege problem rather than a narrow developer mistake.
For practitioners
- 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.
- Shorten the life of machine credentials Replace long-lived keys where possible and enforce tighter issuance and rotation rules for AWS, Stripe and GitHub credentials that can be committed by mistake.
Key takeaways
- Exposed .git repositories can reveal historical commits, deleted files and still-valid credentials, so the real risk is broader than source code disclosure.
- The article found 28,000 exposed repositories across 3.5 million active hosts and recovered hundreds of live credentials, showing that the exposure problem remains widespread.
- The most effective control is to combine history-aware scanning with immediate revocation, rotation and offboarding of any secret found in a repository.
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 SP 800-53 Rev 5 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 is about secrets exposed in repository history and still usable by attackers. |
| NHI-07 — Long-Lived Secrets | The recovered keys remained valid long enough to create real abuse risk. | |
| NHI-05 — Overprivileged NHI | The article shows that leaked machine credentials can expose broad cloud, payment and code access. | |
| Recommendation — Scan exposed repositories for leaked secrets and revoke any credential that appears in commit history. Reduce exposure by replacing long-lived keys with shorter-lived credentials and strict rotation. Review machine credential scope so a leaked key cannot reach more systems than necessary. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential issuance, rotation and revocation are central to preventing repository leaks from remaining valid. |
| Recommendation — Apply IA-5 to enforce rotation, revocation and lifecycle tracking for all exposed secrets. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The attack pattern is rooted in harvesting credentials from exposed repository objects. |
| Recommendation — Map exposed repository secrets to credential access and prioritise them for hunting and revocation. | ||
Key terms
- Exposed Repository History: Exposed repository history is the retained record of code changes, branches, and commits that can preserve sensitive material even after a file is corrected. In practice, removing a secret from the latest version does not automatically eliminate earlier copies. Security teams must assume archived exposure remains accessible until it is explicitly addressed.
- Repository History Exposure: Repository history exposure is the situation where secrets, code, or configuration remain recoverable in past commits, reflogs, or packed Git objects after being removed from the current branch. It matters because deletion in the working tree does not equal revocation of access or removal from attack surface.
- Machine Credential: A machine credential is a secret or identity artifact used by software rather than a person. It includes service account credentials, API keys, tokens, and certificates. In practice, the main risk is not just exposure, but unmanaged lifecycle, unclear ownership, and overbroad access.
- Secret revocation: Secret revocation is the process of invalidating exposed credentials so they can no longer be used. In practice, it must include every system that trusts the secret, because a credential that remains valid after disclosure is still an active attack path.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect repository exposure to lifecycle control, privilege reduction and revocation discipline.
Published by the NHIMG editorial team on August 24, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org