CISA’s leaked GitHub admin key shows how secret sprawl persists

At a glance

What this is: A public GitHub repository exposed a live GitHub App private key with organisation-wide write access, alongside multiple other valid credentials.

Why it matters: IAM, PAM, and NHI teams need to treat repository exposure as an access event, because takedown alone does not revoke standing privilege or erase downstream abuse paths.

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.

👉 Read TruffleHog’s analysis of the leaked CISA GitHub admin key and exposed secrets

Context

A leaked NHI is only contained when the credential is revoked, not when the file disappears. In this case, a public GitHub repository exposed a live GitHub App private key, multiple other tokens, and predictable passwords, which means the access problem outlived the disclosure event itself.

For IAM teams, the core issue is not secret visibility alone but secret lifecycle control across repositories, vendors, and encoded artefacts. If scanners only classify a file as a generic private key, they can miss the actual privilege attached to it and the operational blast radius it creates.

Key questions

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. Deletion reduces visibility, but it does not remove authority. Teams need an explicit revocation step and a verification step for every exposed secret, including keys embedded in infrastructure code and archived copies.

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: What do security teams get wrong about secret scanner safety?

A: Teams often assume that a security tool is automatically low risk. In practice, any scanner that performs network verification inherits a trust boundary and can become dangerous if it has broad egress, permissive redirects, or weak destination validation.

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.

Technical breakdown

Why secret scanners miss the real privilege attached to a key

A raw secret is only the starting point. In this incident, the GitHub App private key became dangerous because it was paired with an App ID and could be exchanged for a JWT that authenticated to the GitHub API. That means the exposed artefact was not just a credential, but a programmable access path into an organisation. Generic scanners often stop at file type or entropy, which misses the permission model behind the secret. The result is false comfort: a finding looks low context even when it grants write access, runner control, or repository-wide visibility.

Practical implication: verify what each discovered secret can actually do before you triage it.

Why encoded and nested secrets extend exposure beyond standard scanning

Secrets are frequently hidden inside layers such as base64 blobs, JSON strings, Docker configs, or Terraform variables. In this case, the article shows a CrowdStrike credential buried three layers deep, which standard scanning missed until recursive decoding was used. That matters because conventional repository scans often assume the secret is directly visible in source text. Once encoding and archival are involved, discovery becomes a parsing problem as much as a detection problem, and the exposure window stays open until every representation of the credential is found.

Practical implication: expand secret discovery to recursive decoding and archived artefacts, not just plain-text source files.

Why revocation, not deletion, is the real remediation control

Taking down a repository does not revoke a credential, and in GitHub environments it does not necessarily remove all historical copies of the exposure. The article describes cases where secrets remained valid days later and notes that developers often deleted the file but never rotated the key. That distinction is critical: removal reduces discoverability, while revocation removes authority. Without a confirmed invalidation step across every affected system, the secret can remain live even after the source repository is gone.

Practical implication: require proof of revocation for every exposed credential, not just proof that the file was removed.

Threat narrative

Attacker objective: The attacker’s objective is to turn a leaked repository secret into durable organisational access and operational control over development and deployment paths.

1. Entry occurred when a public GitHub repository exposed valid credentials, including a GitHub App private key and additional tokens embedded in infrastructure files.
2. Escalation followed because the GitHub App key could be exchanged for API access with organisation-wide write permissions, including repository settings and self-hosted runner control.
3. Impact would include malicious runner registration, repository tampering, and access to deployment secrets, code, and internal workflow artefacts.

Breaches seen in the wild

• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Credential scanning that stops at file type creates a false control boundary. A private key label does not tell you whether the credential grants org-wide write access, runner registration, or data-plane access. This is why NHI governance has to map artefacts to privilege, not just to syntax. If the control only identifies “a key,” it has not identified the risk.

Recursive decoding is now part of NHI discovery, not a niche enhancement. The article’s layered base64 example shows that secret exposure increasingly happens in nested machine-readable formats rather than obvious plaintext. That shifts discovery expectations for IAM and security operations teams: if the scanner cannot unwrap encoded structures, it is operating below the actual exposure surface.

Predictable passwords and vendor-specific tokens belong in the same governance queue as cloud keys. The article makes clear that a single repository can expose multiple credential classes with different revocation paths, ownership models, and blast radii. The implication is a unified NHI control plane for inventory, ownership, and revocation, rather than separate treatment by system.

Identity blast radius is now the better way to think about repository leaks. The exposed GitHub repository did not only leak secrets, it mapped infrastructure, vendors, and access paths that persisted after credential rotation. That is the governance problem practitioners must account for: the secret is the entry point, but the architecture map is the enduring impact.

From our research:

• 74% were still valid a month later, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, according to The State of Secrets Sprawl 2026.
• From our research: Use the Guide to the Secret Sprawl Challenge to separate discovery from revocation and reduce the time secrets remain live after exposure.

What this signals

Identity blast radius is becoming the more useful operational lens for leaked-secret incidents. When a repository leak exposes keys, runner permissions, and vendor tokens at the same time, the question is no longer whether a secret exists, but how far its authority extends across build, deploy, and data access paths.

The governance shift is toward verified invalidation. If your incident workflow cannot prove that every affected key, token, and certificate has been revoked, then your programme is still optimised for discovery rather than containment. That is a material difference for IAM, PAM, and NHI operations.

Teams should watch for secret sprawl migrating into encoded artefacts and archived data sources, not just source code. The exposure surface now includes Terraform, Docker configs, event archives, and old forks, which means the remediation model must follow the credential wherever it can be reconstructed.

For practitioners

• Require proof-of-revocation for every exposed credential Treat repository takedown as an incident response step, not closure. Build a workflow that confirms each secret was invalidated in the owning system, including GitHub Apps, cloud keys, vendor tokens, certificates, and database passwords, before the case is marked resolved.
• 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. Prioritise secrets that can modify infrastructure or deploy code over credentials that only read low-risk data.
• 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. This is essential when attackers hide credentials in infrastructure-as-code and archived artefacts.
• Separate discovery from authority removal in incident playbooks Make the playbook explicit: find, confirm, revoke, rotate, and verify. Deleting the repository or pull request should never be treated as equivalent to revoking the credential or closing downstream access paths.
• Use a single inventory for all exposed NHI classes Track cloud keys, GitHub App keys, vendor API credentials, database passwords, SSH keys, and TLS certificates in one remediation queue so ownership, rotation status, and expiry can be assessed together rather than by silo.

Key takeaways

• This incident shows that repository cleanup without credential revocation leaves active access in place, which is the real governance failure.
• The evidence points to a much wider exposure surface, with live keys, predictable passwords, and nested secrets all coexisting in one incident.
• Practitioners need proof-of-revocation, recursive discovery, and scope-based triage if they want secret leakage to become a containable event.

Key terms

• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Proof Of Revocation: Proof of revocation is evidence that an exposed credential has been invalidated in the system that issued it, not merely removed from a file or repository. It is the control that separates discovery from containment, especially when the same secret may exist in multiple copies or encodings.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Recursive Secret Discovery: Recursive secret discovery is the process of detecting credentials inside nested or encoded content such as base64 blobs, JSON structures, and infrastructure files. It matters because many real exposures are not plaintext, so a scanner that only inspects surface text misses the actual risk.

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

👉 TruffleHog’s full post covers the validation method, the broader secret inventory, and the revocation timeline.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.