> GitHub App keys can still enable takeovers long after they are forgotten

GitHub allows organizations to install GitHub Apps that automate and extend certain functionality on the platform and have access to selected repositories and permissions. But the private keys these applications use to authenticate themselves can remain valid for years unless manually revoked. If leaked, those keys can potentially give attackers administrative control over an organization’s GitHub account, says GitGuardian, which found 474 still-valid GitHub App private keys among 4802 publicly exposed ones it has collected since 2019. In testing the keys for validity, it was also able to determine what access rights they provided, finding that “72% of the compromised Apps could read private repository content, and 207 could write to it, turning one leaked key into an organization takeover,” GitGuardian researcher Gaetan Ferry said in a blog post. Among the GitHub Apps affected by the leaked keys was “Access Tokens for GitHub Actions,” an application used to manage access for GitHub Actions workflows. Its private key was exposed in January 2024 after being accidentally committed to a repository, potentially affecting 300 organizations where the app was installed, including Civica and Sierra Nevada Corp. BuildBuddy, Crusher.dev, and a private application associated with the US Centers for Disease Control and Prevention were among the other GitHub Apps for which GitGuardian found exposed keys. Agnidipta Sarkar, chief evangelist at security software vendor ColorTokens, said the initial abuse is “trivially straightforward” and an attacker can achieve that with a valid private key and the corresponding App ID. For maximum impact, he said, attackers could chain the abuse by “injecting malicious code into the repository and when the code is built or deployed, it can compromise downstream users or production environments.” An attacker might also be able to modify CI/CD runner configurations to execute arbitrary code on the organization’s internal network infrastructure, Sarkar added. GitGuardian said it notified all affected application owners about the exposed keys and noted that its own secret-scanning service uses a GitHub App to monitor repositories for leaked credentials. Leaked keys had varied access When an organization installs a GitHub App, it decides which repositories the application can access and what it can do there. GitGuardian found that 40 affected Apps could administer self-hosted runners, 98 could control workflows, and 44 had organization-administration privileges. For the Apps with organization administration privileges, “An attacker could add themselves as an owner, lock out legitimate admins, and completely hijack the GitHub organization,” Sarkar said. One of the exposed Apps had 303 installations, some had none, and 59% of them had just one installation, pointing to private use. Commenting on these internal, single-installation Apps, Ferry said, “Those are internal automation, CI bots, and one-off tooling that can easily be forgotten, even if no longer used.” Such Apps can keep running and the keys can keep working indefinitely without anybody noticing. GitGuardian also found 156 cases where the leaked private key appeared in an unrelated repository, making the credential harder to associate with the GitHub App that owned it. “The blast radius does not stop at the App’s owner,” Ferry said. “It extends to every organization that installed the App, and, through supply-chain dependencies, to every downstream user of the code that App touches.” Key rotation is the only way Even though GitHub warns in its official documentation that the private keys do not expire on their own and must be manually revoked or deleted, organizations may not be doing so because of incorrect security assumptions about how they work. The private keys are generated in the App’s configuration and are used to sign a short-lived JSON Web Token (JWT), which GitHub accepts and issues an installation access token for. The installation token carries the permissions granted to the App when an organization installed it. The JWT expires within minutes and installation tokens are only valid for an hour, making their abuse window really short and giving an impression that losing control of a key present a limited risk. However, anyone who holds the private key can generate countless JWTs and authenticate as the GitHub App, getting GitHub to generate fresh installation tokens for as long as the private key remains valid. “It is possibly an intentional design trade-off, not an oversight,” Sarkar said, commenting on the implementation of short-lived tokens alongside a permanent key. “This is how machine-to-machine authentication traditionally works and it prevents unexpected downtime.” The “forever” design prioritizes operational simplicity and continuity; the security burden of rotation falls entirely on App owners, he added. 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, said Ferry. “A key committed by mistake in 2020 can still authenticate today, long after the mistake is forgotten,” he said. Sarkar said that manual revocation is extremely rare and almost always reactive, though. “Most IT service management manuals mention its necessity, but rarely demonstrate it unless a security incident, an audit, or a specific change requires it,” he explained. This article first appeared on InfoWorld.