474 leaked GitHub App private keys still worked, exposing supply-chain risk
GitGuardian found that 474 publicly leaked GitHub App private keys still authenticated, including keys with repository-write and organization-admin permissions. A CDC-linked key was revoked after disclosure, and no malicious use has been publicly confirmed.
What happened?
Confirmed facts: GitGuardian published research on September 22, 2026, after testing 4,802 GitHub App private keys found within a much larger dataset of publicly leaked RSA keys. The company reported that 474 keys, tied to 440 distinct GitHub Apps, still authenticated to GitHub's API. According to the researchers, 207 affected Apps had permission to modify repository contents, 44 had organization-administration privileges, 40 could administer self-hosted runners, and 98 could control workflows. GitGuardian also documented a private key associated with a CDC-linked organization that had write access to two private repositories. The firm reported the exposure through the U.S. Department of Health and Human Services vulnerability-disclosure portal on September 4; the key was revoked on September 18. GitHub's own documentation confirms that GitHub App private keys do not expire automatically and must be manually revoked. Reported research claim: GitGuardian assessed that the CDC-linked App's permissions and documented role could have enabled code changes and possible access into connected Azure infrastructure. The researchers said they did not enter the private repository or attempt that access. Unknowns: no public evidence reviewed for this article shows that a criminal used the CDC-linked key or any particular key in the dataset, altered code, entered a cloud environment, or caused a confirmed breach. The number of still-valid keys is a verified research result, not proof that every affected App was exploited.
How the technology works
At a safe defensive level, a GitHub App uses a private cryptographic key to prove its identity to GitHub. The key signs a short-lived authentication token, which can then be exchanged for an installation token carrying only the permissions granted to that App. The short life of the token does not neutralize an exposed private key: anyone holding the key can continue generating new signed tokens until the key is deleted. If an App can write repository contents, manage workflows, or administer an organization, a stolen key can inherit those privileges and create a software supply-chain risk. An unauthorized change to trusted source code or an automated build can potentially reach downstream users. This article intentionally omits leaked key material, affected repository locations, and operational instructions for using a key.
Who is affected?
GitHub organizations, developers, maintainers, CI/CD teams, and customers of software built through affected repositories may be exposed. Risk depends on whether a key remains valid, where its App is installed, and what permissions it holds. Internal automation and abandoned one-off Apps deserve particular attention because ownership can become unclear while credentials remain active. The CDC-linked credential has reportedly been revoked, and readers should not assume CDC systems were breached. The broader finding matters to any organization that uses GitHub Apps for builds, deployments, security scanning, project automation, cloud access, or self-hosted runners.
What should you do?
GitHub organization owners should inventory every installed and internally owned GitHub App, identify a current human owner, remove unused installations, and compare requested permissions with actual business need. Revoke and replace any private key that was committed to a repository, exposed in logs or artifacts, shared insecurely, or cannot be accounted for. Store replacement keys in a managed secrets vault, restrict access, and rotate without downtime by creating a new key before deleting the old one. Review GitHub audit logs, App installations, workflow changes, releases, self-hosted runner activity, and cloud identity logs for unexpected behavior. Rebuild sensitive artifacts from known-good source if integrity is uncertain. Developers should never hard-code private keys, even in private repositories. Individuals who only use software built on GitHub do not need to rotate personal passwords because of this research alone; they should keep software updated and follow any notice from a vendor that confirms impact.
My analysis
My analysis and opinion: a credential that never expires is convenient for automation but dangerous when ownership, monitoring, and deletion depend entirely on human memory. The central privacy problem is not only unauthorized reading of private source code. A forgotten machine identity can quietly preserve access across repositories, workflows, infrastructure, and downstream products long after the original project or employee is gone. My inference is that the true risk is larger than the 474 keys tested because private leaks, copied build artifacts, and credentials outside the researchers' dataset would not appear in that number. That is a risk assessment, not evidence of additional compromise. From a privacy-first viewpoint, organizations should minimize every App's scope, separate code access from deployment authority, log machine-identity activity, and make credentials expire or undergo mandatory review. GitHub should consider stronger expiration defaults, automated warnings for long-lived keys, and faster ecosystem-wide revocation paths when secrets become public. Security researchers should continue coordinated disclosure, but affected organizations owe users timely notice if investigation finds that code, personal data, or cloud systems were actually accessed. Transparency should match evidence: the exposure is confirmed; malicious exploitation is not.
Why this matters
Cyber incidents often sound distant or overly technical. The important question is whether the same weakness, behavior, surveillance power, or exposure exists in systems you use. Facts and opinion are separated here so you can judge both clearly.
Facts, claims, and unknowns are separated above. Details may change as the FBI's investigation develops.
GitGuardian: 474 leaked GitHub App private keys still authenticated GitHub Docs: managing and revoking GitHub App private keys Cybernews: CDC-linked key and disclosure timeline