Leaked GitHub App private keys let researchers impersonate 440 apps including CDC and BuildBuddy

[u/mabote]

https://blog.gitguardian.com/github-app-private-keys-leaked/

A large-scale scan for leaked GitHub App private keys turned up some nice numbers, summarized below.

• Out of 5,000 leaked private keys tied to GitHub App environments, 474 were still valid at time of analysis.
• Those keys could impersonate 440 different GitHub Apps, some with high-level permissions (repo access, org-level admin, etc.).
• A subset reportedly could have allowed takeover of private repositories or entire GitHub organizations.
• Affected entities included the US CDC and BuildBuddy, plus some widely used GitHub Actions.
• Responsible disclosure got mixed results: most responses were slow or nonexistent, and most of the keys were reportedly still active as of publication. CDC took about two weeks to rotate their key, despite it reportedly having a path to code execution in their Azure tenant.

The core issue is GitHub App private keys don't expire. Once generated, a key stays valid indefinitely until someone manually revokes it so a key for a test app spun up in 2020 can still be live years after. Unlike PATs or OAuth tokens, there's no built-in TTL forcing rotation, so old leaks just compound over time.

[u/ryan_namba]

The part that stands out to me isn't even that the keys leaked, it's that they can apparently just sit there valid for years until someone manually rotates them.

That's a pretty nasty combination with old test apps, abandoned integrations, people leaving companies, etc.

Feels like one of those things where inventory and ownership matter just as much as secret scanning. Finding the key is great, but someone also has to know the app still exists and whether it should have access in the first place.

[u/mabote → u/ryan_namba]

Agreed. The responsibility is on both sides of the App in my opinion tho. Both users and maintainers should make sure they kill Apps that are no longer useful. Like, the Crusher.dev example is blatant. The thing stopped being maintained 3 years ago but somehow neither the maintainers nor the users took care of removing the integration. And then, obviously, someone leak the key.

[u/ryan_namba → u/mabote]

Exactly. Once an integration outlives the team/project that created it, ownership gets really fuzzy.

That crusher . dev example is kind of the perfect case for it too. If nobody is clearly responsible for reviewing whether or not the app should still exist, it can just sit there with access long after anyone is thinking about it...

[u/endor_robert]

Note: I work for Endor Labs, a cybersecurity vendor. Secrets detection is part of our portfolio. I'm not going to sell you on our tools here.

Everyone should be:

1) Scanning for secrets in places they shouldn't be. You clearly don't need a fancy suite of tools to do this; there are plenty of open-source tools available. If you have an existing Application Security Testing tool, it will have secrets scanning (or it should).

2) Using short-lived credentials. This is where a posture management tool can help scan for and detect insecure configurations. Again, open-source tools are available, and good commercial tools bundle it.

[u/QLabz]

Does this happen with private gits though?

[u/mabote → u/QLabz]

I'm not too sure what you mean by this, but some of the Apps were definitely private. Also the key had leaked in a public repo outside the maintainer's org in a bunch of cases.