Notifications
Clear all
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.
NHIMG editorial — based on content published by Intruder: LLMjacking research on exposed .git repositories and leaked credentials
By the numbers:
- The scan uncovered 400 AWS access keys, 107 Stripe API keys, 123 OpenAI API keys, 80 Telegram tokens, and 17 GitHub personal access tokens.
Questions worth separating out
Q: What breaks when secrets are spread across multiple repositories and tools?
A: When secrets sprawl across repositories and toolchains, organisations lose the ability to find, classify, and revoke them quickly.
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 if their repo-scanning controls are actually working?
A: Look for two signals: untrusted repositories are always cloned into a temporary workspace, and no scanner path shells out to Git on copied inputs.
Practitioner guidance
- Scan commit history, not just HEAD Use repository inspection that traverses historical commits, reflogs, and packed objects so deleted secrets remain detectable.
- Classify exposed credentials by reachable system Map each leaked key or token to the cloud account, code repository, payment system, or API it can access, then prioritise revocation by blast radius.
- Automate revocation and rotation workflows Link secret discovery to owned runbooks that revoke or rotate credentials immediately, including service ownership lookup and confirmation that replacement credentials are deployed.
What's in the full report
Intruder's full research covers the operational detail this post intentionally leaves for the source:
- The repository-walking approach used to inspect commit history in memory at internet scale.
- The exact detection logic for false positives, including entropy checks, placeholders, and runtime-value filtering.
- The patterns behind AWS, Stripe, OpenAI, Telegram, and GitHub credential exposure across real repositories.
- The disclosure and remediation process used after sensitive exposures were identified.
👉 Read Intruder's research on exposed .git repositories and live credential leakage →
Exposed .git repositories: what security teams still miss?
Explore further
24/08/2026 2:01 pm
Secret history is the real attack surface: the risk is not limited to what a repository exposes today, but to everything its history still reveals. That matters because many scanning and review processes still focus on current-state files rather than commit graphs, reflogs, and recovered objects. In identity terms, the credential lifecycle is longer than the visible code lifecycle, and that mismatch is where exposure persists. Practitioners should treat repository history as a governed secrets store and not as archival noise.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
A question worth separating out:
Q: Who is accountable when a compromised action leaks repository secrets?
A: Accountability usually spans platform engineering, application owners, and identity governance, because the failure crosses code integrity, workflow design, and credential lifecycle. The right question is not who owns the incident alone, but which team owns action trust, which team owns the secret, and which team owns the downstream access it enabled.
👉 Read our full editorial: Exposed .git repositories keep leaking live AWS, Stripe and GitHub keys
