Exposed GitHub App Keys Pose Long-Term Security Risks
Organizations leveraging GitHub Apps for automation and extended functionalities on the platform might be sitting on a ticking time bomb—unrevoked private keys that can enable unauthorized access to their accounts. GitGuardian's research highlights this vulnerability, revealing that among 4,802 exposed keys since 2019, 474 are still valid. The implications of these findings are concerning, as even a single leaked key could grant attackers extensive control over an organization’s repositories.
GitGuardian’s analysis emphasizes just how devastating such a security compromise can be. "72% of the compromised Apps could read private repository content, and 207 could write to it, turning one leaked key into an organization takeover,” stated GitGuardian researcher Gaetan Ferry. This clearly illustrates the feasible pathways for threats if these keys fall into the wrong hands.
Among the affected applications is the "Access Tokens for GitHub Actions," which is critical for managing access within GitHub workflows. This particular key was inadvertently exposed in January 2024, impacting roughly 300 organizations, including notable entities like Civica and Sierra Nevada Corp. Other applications also found compromised include BuildBuddy, Crusher.dev, and a CDC-associated private app, indicating a broad spectrum of potential impact.
Understanding Access Levels of Leaked Keys
The degree of access that these compromised keys can provide varies. GitGuardian’s findings show that while some applications have extensive access rights, others remain minimally intrusive. For instance, 40 Apps had the capability to administer self-hosted runners, while 98 could manipulate workflows. Particularly concerning are the 44 applications with organization administration privileges, which pose a substantial risk if exploited. An attacker could not only add themselves as an owner but also entirely block legitimate administrators, effectively hijacking the organization’s GitHub account.
The prevalence of these vulnerabilities is stark; one exposed app boasted 303 installations, while many others were used privately with just a single installation. These lesser-visited apps often go unnoticed over time, increasing the potential for keys to remain active without management. Ferry expressed concern, noting, “Those are internal automation, CI bots, and one-off tooling that can easily be forgotten, even if no longer used.” This obliviousness can lead to detrimental security oversights as keys stay valid indefinitely.
GitGuardian’s research also uncovered that 156 exposed keys were discovered in unrelated repositories, complicating their identification and minimizing the perceived risks associated with them. "The blast radius does not stop at the App’s owner," Ferry cautioned. "It extends to every organization that installed the App, and, through supply-chain dependencies, to every downstream user of the code that App touches."
The Imperative for Key Management
The GitHub platform’s approach to key management places a critical burden on organizations, as private keys do not naturally expire. Though GitHub’s documentation alerts users to this fact, organizations may underestimate the necessity of actively revoking or rotating keys due to a lack of awareness regarding their prolonged validity.
Private keys are generated during app configuration and are used to sign short-lived JSON Web Tokens (JWTs), with associated installation tokens being valid only for about an hour. While this seemingly limits the window for exploitation, the reality is that anyone with access to the private key can continuously generate new JWTs and installation tokens as needed, so long as the key is valid.
Agnidipta Sarkar, chief evangelist at ColorTokens, notes this design can be seen as a strategic trade-off. The implementation of short-lived tokens alongside a permanent key allows for easier machine-to-machine authentication but places the onus of proper management squarely on app owners.” There’s a tension between operational stability and security,” he stated.
To stave off potential breaches, GitGuardian advocates for routine key rotation and revocation. “A key committed by mistake in 2020 can still authenticate today, long after the mistake is forgotten," Ferry observed. This underlines a significant gap in security practices within many organizations.
Although most IT management protocols mention the necessity for key revocation, the practice often remains reactive, triggered only after a breach, audit, or other specific events. As the industry grapples with increasing cyber threats, proactive key management will prove essential in protecting sensitive information.
This article first appeared on InfoWorld.
