Security firm GitGuardian discovered 474 still-valid GitHub App private keys among 4,802 publicly exposed credentials it has gathered since 2019, with some carrying enough permissions to completely take over an organization's GitHub account. The keys can stay active for years unless someone manually revokes them, creating a long-lasting security vulnerability even after the original exposure is forgotten. GitHub Apps are tools that organizations install to automate tasks and extend platform functionality, but their authentication keys don't expire on their own.
Among the 474 valid keys, 72% granted access to read private repository content, while 207 could write to those repositories, transforming a single leaked key into a pathway for full organizational takeover. GitGuardian identified exposed keys belonging to several GitHub Apps, including "Access Tokens for GitHub Actions," whose private key was accidentally committed to a repository in January 2024 and potentially affected 300 organizations where the app was installed, among them Civica and Sierra Nevada Corp. Other affected applications included BuildBuddy, Crusher.dev, and a private app associated with the US Centers for Disease Control and Prevention. The firm tested the keys to check whether they remained active and what level of access they provided. Forty of the compromised apps could administer self-hosted runners, 98 could control workflows, and 44 possessed organization-administration privileges. One exposed app had 303 installations, though 59% of affected apps had just a single installation, suggesting private internal use.
"A key committed by mistake in 2020 can still authenticate today, long after the mistake is forgotten," GitGuardian researcher Gaetan Ferry said. For apps with organization administration privileges, an attacker could add themselves as an owner, lock out legitimate admins, and completely hijack the GitHub organization, according to Agnidipta Sarkar, chief evangelist at security software vendor ColorTokens. The report notes that 156 cases involved leaked private keys appearing in unrelated repositories, making the credential harder to link to the GitHub App that owned it. Ferry explained that the blast radius extends beyond the app's owner to every organization that installed the app and, through supply-chain dependencies, to every downstream user of the code that app touches. GitGuardian notified all affected application owners about the exposed keys.
The private keys remain valid indefinitely because of how GitHub's authentication system works, even though GitHub warns in its official documentation that the keys don't expire on their own and must be manually revoked or deleted. Organizations generate the keys in the app's configuration and use them to sign a short-lived JSON Web Token, which GitHub accepts and then issues an installation access token for. While the JWT expires within minutes and installation tokens remain valid for only an hour, anyone holding the private key can generate countless JWTs and authenticate as the GitHub App, prompting GitHub to create fresh installation tokens for as long as the private key stays active. This design prioritizes operational simplicity and continuity, preventing unexpected downtime, but places the entire security burden of rotation on app owners. With the initial abuse "trivially straightforward" for an attacker with a valid private key and the corresponding App ID, attackers could inject malicious code into repositories that compromises downstream users or production environments when built or deployed, or modify CI/CD runner configurations to execute arbitrary code on an organization's internal network infrastructure.
GitGuardian recommends regularly rotating or revoking the private keys because they can outlive both the people who created them and the reason they did it, Ferry said. Internal, single-installation apps represent internal automation, CI bots, and one-off tooling that can easily be forgotten even when no longer used, with such apps potentially running and their keys working indefinitely without anyone noticing. Manual revocation is extremely rare and almost always reactive, Sarkar noted, explaining that most IT service management manuals mention its necessity but rarely demonstrate it unless a security incident, an audit, or a specific change requires it. The authentication model reflects how machine-to-machine authentication traditionally works, representing what may be an intentional design trade-off rather than an oversight. Organizations that treat short-lived tokens as sufficient protection may be operating under incorrect security assumptions, unaware that the underlying permanent key creates lasting exposure regardless of how quickly the derived tokens expire.