{"id":9567,"date":"2026-09-23T15:12:48","date_gmt":"2026-09-23T15:12:48","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=9567"},"modified":"2026-09-23T15:12:48","modified_gmt":"2026-09-23T15:12:48","slug":"github-app-keys-can-still-enable-takeovers-long-after-they-are-forgotten","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=9567","title":{"rendered":"GitHub App keys can still enable takeovers long after they are forgotten"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

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.<\/p>\n

If leaked, those keys can potentially give attackers administrative control over an organization\u2019s GitHub account, says GitGuardian, which found 474 still-valid GitHub App private keys among 4802 publicly exposed ones it has collected since 2019.<\/p>\n

In testing the keys for validity, it was also able to determine what access rights they provided, finding that \u201c72% of the compromised Apps could read private repository content, and 207 could write to it, turning one leaked key into an organization takeover,\u201d GitGuardian researcher Gaetan Ferry said<\/a> in a blog post.<\/p>\n

Among the GitHub Apps affected by the leaked keys was \u201cAccess Tokens for GitHub Actions,\u201d an application used to manage access for GitHub Actions<\/a> 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.<\/p>\n

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.<\/p>\n

Agnidipta Sarkar, chief evangelist at security software vendor ColorTokens, said the initial abuse is \u201ctrivially straightforward\u201d 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 \u201cinjecting malicious code into the repository and when the code is built or deployed, it can compromise downstream users or production environments.\u201d<\/p>\n

An attacker might also be able to modify CI\/CD runner configurations to execute arbitrary code on the organization\u2019s internal network infrastructure, Sarkar added.<\/p>\n

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.<\/p>\n

<\/a>Leaked keys had varied access<\/h2>\n

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.<\/p>\n

For the Apps with organization administration privileges, \u201cAn attacker could add themselves as an owner, lock out legitimate admins, and completely hijack the GitHub organization,\u201d Sarkar said.<\/p>\n

One of the exposed Apps had 303 installations, some had none, and 59% of them had just one installation, pointing to private use.<\/p>\n

Commenting on these internal, single-installation Apps, Ferry said, \u201cThose are internal automation, CI bots, and one-off tooling that can easily be forgotten, even if no longer used.\u201d Such Apps can keep running and the keys can keep working indefinitely without anybody noticing.<\/p>\n

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.<\/p>\n

\u201cThe blast radius does not stop at the App\u2019s owner,\u201d Ferry said. \u201cIt extends to every organization that installed the App, and, through supply-chain dependencies, to every downstream user of the code that App touches.\u201d<\/p>\n

<\/a>Key rotation is the only way<\/h2>\n

Even though GitHub warns in its official documentation<\/a> 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.<\/p>\n

The private keys are generated in the App\u2019s configuration and are used to sign a short-lived JSON Web Token (JWT<\/a>), 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\u201cIt is possibly an intentional design trade-off, not an oversight,\u201d Sarkar said, commenting on the implementation of short-lived tokens alongside a permanent key. \u201cThis is how machine-to-machine authentication traditionally works and it prevents unexpected downtime.\u201d The \u201cforever\u201d design prioritizes operational simplicity and continuity; the security burden of rotation falls entirely on App owners, he added.<\/p>\n

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. \u201cA key committed by mistake in 2020 can still authenticate today, long after the mistake is forgotten,\u201d he said.<\/p>\n

Sarkar said that manual revocation is extremely rare and almost always reactive, though. \u201cMost IT service management manuals mention its necessity, but rarely demonstrate it unless a security incident, an audit, or a specific change requires it,\u201d he explained.<\/p>\n

This article first appeared on <\/em>InfoWorld<\/a>.<\/em><\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

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\u2019s […]<\/p>\n","protected":false},"author":0,"featured_media":9568,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-9567","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/9567"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=9567"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/9567\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/9568"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=9567"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=9567"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=9567"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}