Notifications
Clear all
Topic starter
14/07/2026 5:23 pm
TL;DR: A leaked GitHub App private key granted write access to CISA’s GitHub organisation and remained active two days after public reporting, while TruffleHog also found multiple other live tokens, passwords, and keys in the same repository. Secret removal alone is not remediation when revocation, discovery, and encoded-secret detection lag behind exposure.
NHIMG editorial — based on content published by TruffleHog: CISA's leaked Admin GitHub Token Remained Live 2 Days After Krebs Reported It Leaked
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- 74% were still valid a month later.
Questions worth separating out
Q: What fails when a leaked NHI is removed from GitHub but not revoked?
A: The credential remains valid even though the file is gone, which means the attacker can still use it until the owning system invalidates it.
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: What do security teams get wrong about secret scanner safety?
A: Teams often assume that a security tool is automatically low risk.
Practitioner guidance
- Require proof-of-revocation for every exposed credential Treat repository takedown as an incident response step, not closure.
- Map each discovered secret to its actual privilege scope Classify whether the credential can write repositories, register self-hosted runners, read deployment logs, or access vendor registries.
- Add recursive decoding to secret discovery pipelines Scan for secrets inside base64, JSON, Terraform, Docker, and other nested formats, then validate the decoded value rather than the wrapper text.
What's in the full analysis
TruffleHog's full article covers the operational detail this post intentionally leaves for the source:
- How the GitHub App key was validated against the GitHub API and what its permissions meant in practice
- The full list of exposed credential types, including vendor tokens, database passwords, TLS keys, and AWS material
- Why recursive decoding exposed secrets that standard scanners missed in Terraform and nested JSON
- The disclosure timeline and rotation lessons across multiple vendor systems
👉 Read TruffleHog’s analysis of the leaked CISA GitHub admin key and exposed secrets →
CISA’s leaked GitHub admin key: what IAM teams should learn?
Explore further
14/07/2026 5:27 pm
Secret exposure without lifecycle revocation is a standing-access failure, not a discovery failure. The CISA case shows that removal of the public file did not immediately remove the underlying authority, because the key remained active after disclosure. That means the real governance gap is the absence of a confirmed invalidation workflow across every credential type touched by the leak. Practitioners should treat exposed NHI material as live access until proven otherwise.
A few things that frame the scale:
- 74% were still valid a month later, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, according to The State of Secrets Sprawl 2026.
A question worth separating out:
Q: Who is accountable when leaked credentials are reused for breach activity?
A: Accountability usually spans IAM, security operations, application owners, and vendor risk management, because exposed credentials cross organisational boundaries. The practical test is whether each owner can prove timely revocation, MFA enforcement, and detection coverage for the identities they control.
👉 Read our full editorial: CISA’s leaked GitHub admin key shows how secret sprawl persists
