GitHub Apps play a vital role for organizations, automating tasks and managing access permissions across repositories. However, the private keys that authenticate these applications can persist for years if not manually revoked, creating a significant security risk.
Recent findings from GitGuardian reveal that out of 4,802 instances of publicly visible GitHub App private keys collected since 2019, 474 were still valid. These keys could provide attackers with administrative control over a GitHub organization’s account, emphasizing a serious vulnerability.
Upon testing these keys, GitGuardian noted alarming statistics: “72% of compromised Apps had the capability to read private repository content, and 207 possessed write access,” stated researcher Gaetan Ferry. This level of access means a single leaked key could allow an attacker to take full control of an organization.
Among the exposed applications was “Access Tokens for GitHub Actions,” which oversees workflows for GitHub Actions. Its private key was unintentionally committed in January 2024, potentially impacting around 300 organizations, including notable companies like Civica and Sierra Nevada Corp.
Other applications with exposed keys included BuildBuddy and a private app linked to the US Centers for Disease Control and Prevention (CDC). According to Agnidipta Sarkar, chief evangelist at ColorTokens, exploiting these keys is alarmingly simple. An attacker can capitalize on a valid private key and App ID to inject malicious code, which could lead to further compromised environments.
There’s also the potential for misconfiguration of CI/CD (Continuous Integration/Continuous Deployment) runners, allowing exploitation of an organization's internal networks. GitGuardian took action by alerting owners of affected applications regarding the exposed keys and emphasized the importance of its own secret-scanning service that monitors for credential leaks on the platform.
Access Rights Reveal Serious Vulnerabilities
When an organization integrates a GitHub App, it specifies what repositories the App can access and the extent of its operational permissions. GitGuardian’s research indicated that 40 of the compromised applications had the ability to manage self-hosted runners, while numerous others could control workflows or hold organization administration privileges.
With admin privileges, attackers can lock out legitimate users and assume ownership of the GitHub organization entirely. Among the affected Apps, one had 303 installations, while a significant proportion had none or just a single installation, suggesting they may have been used for internal automation without regular oversight.
The prevalence of these private-use Apps can lead to situations where they operate unnoticed, especially when an installation key remains active indefinitely. GitGuardian’s findings also included instances where compromised keys appeared in unrelated repositories, complicating the tracking of their origins and associations.
This situation leads to a broader risk profile as the impact of a compromised App reaches beyond just the App’s owner to any associated organizations and their dependencies in the supply chain. "The blast radius expands to every organization that installed the App, affecting numerous downstream users," Ferry highlighted.
Prioritizing Key Rotation for Enhanced Security
While GitHub officially states that these private keys do not expire on their own and require manual revocation, many organizations might be failing to take this precaution due to misconceptions about their security implications.
The keys are initially generated as part of the App’s configuration and are used for signing a short-lived JSON Web Token (JWT). GitHub generates an installation access token based on this JWT, which carries permissions as granted at setup.
The JWT itself is ephemeral, with a validity of just a few minutes, and the installation token expires within an hour. This short timeframe can create a false sense of security, leading organizations to underestimate the risks associated with lost control of a private key.
Anyone possessing the private key can continuously generate new JWTs, thereby obtaining fresh installation tokens as long as the key remains valid. Sarkar pointed out that this could be a deliberate design choice, fostering operational durability at the cost of security. "This design allows machine-to-machine authentication while prioritizing continuity," he explained. However, it also places the burden of security on the App owners to manage key rotation proactively.
To mitigate these risks, GitGuardian advises firms to establish regular practices for rotating or revoking private keys, a process that can easily outlast the people who initially created them. "A key mistakenly committed in 2020 can remain valid today, well after everyone has forgotten about it," Ferry cautioned.
Sarkar noted that manual revocation rarely occurs, typically only prompted by security incidents, audits, or necessary changes. Ensuring adequate security protocols around key management should be a priority to safeguard organizational integrity against potential breaches.
This article first appeared on InfoWorld.
