What happened
On September 22, 2026, GitGuardian published its measurement of exposed GitHub App keys after testing their ability to authenticate to GitHub’s API. GitGuardian tested 4,802 GitHub-related private keys and found 474 that still authenticated as 440 distinct GitHub Apps. The source set came from publicly exposed RSA keys associated with GitHub contexts and nearby App identifiers, allowing the researchers to test authentication without interacting with private repositories.
Among the affected Apps, 72% could read private repository content, 207 could write content, 44 had organisation-administration privileges, 40 could administer self-hosted runners and 98 could control workflows. Those permissions can support repository modification, workflow changes, organisational takeover or execution through build infrastructure if a key is abused. The findings covered both broadly installed Apps and internal automation with only one installation, which can be particularly difficult to discover through vendor-management records.
GitHub’s official documentation states that GitHub App private keys do not expire and must be manually revoked. The keys sign short-lived JWTs that can be exchanged for installation tokens carrying the App’s approved permissions. The short token lifetime does not close the exposure because anyone retaining the private key can repeatedly sign new JWTs until the key is deleted from the App configuration.
The cited sources did not publish the private-key material and did not establish malicious exploitation of the measured credential set. GitGuardian said it notified affected application owners and described examples where keys were rotated or applications removed. Attribution posture: GitGuardian identified exposed credentials and affected applications but did not attribute malicious exploitation to any threat actor. The immediate decision is therefore preventive containment of live credentials, not an assertion that every affected App or installing organisation was compromised.
Why this matters now
GitHub App private keys are machine identities that can outlive the automation, employee or project that created them. Anyone holding a valid key can sign a JWT and request fresh installation tokens carrying the App’s granted permissions. Short-lived installation tokens therefore do not reduce the persistence of a leaked private key that remains valid, creating a path into repositories, workflows and self-hosted build infrastructure.
The risk can propagate beyond the key owner. An App installed across multiple organisations may be able to modify code or workflows in every authorised repository, potentially affecting software builds and downstream users. Security leaders need to treat App publishers and internal automation as part of software-supply-chain assurance, with ownership, rotation, permission review and revocation evidence comparable to controls for service accounts and cloud credentials.
The decision for security leaders
Assign application security or developer-platform engineering to build a complete GitHub App register across enterprise organisations. Record the App owner, publisher, installations, repositories, permissions, key fingerprints, storage location, last rotation and business dependency. Prioritise Apps with content-write, workflow, runner or organisation-administration permissions, especially when the owner is inactive or the original use case is no longer understood.
Rotate before deleting so critical automation can be validated without downtime, then revoke the old key and search repositories, build logs and secret-management records for historical exposure. Third-party Apps should receive the same assurance treatment as other software suppliers: confirm the publisher’s key-management process, incident-notification commitment and permission minimisation. Internal one-off automation should not receive a lower standard merely because it lacks a commercial vendor.
Evidence of closure
- GitHub App inventory with owner, installations, permissions and key fingerprints.
- Rotation evidence showing old keys deleted after new keys were validated.
- Repository scan proving no active App key remains in code or history.
- Approved exception record for any App retaining organisation, workflow or runner administration.
The Security.io assessment
The underlying non-expiring-key behaviour was already documented by GitHub; the material change is evidence that hundreds of exposed keys still worked and that many carried permissions capable of altering code or controlling automation. The study does not prove malicious use, and permission capability must not be represented as confirmed takeover. It does, however, invalidate any assumption that an old repository leak has naturally expired.
The development earns inclusion because it adds a software-supply-chain and machine-identity decision absent from the other stories. Its enterprise value is not the headline count alone but the need to connect secret scanning with installation inventory and permission governance. A repository scan that finds a leaked key is incomplete unless the App is identified, its installations are mapped, the key is revoked and downstream activity is reviewed.
Questions for the morning meeting
- Who owns every GitHub App installed across the enterprise?
- Which Apps retain workflow, runner or organisation-administration permissions?
- Can exposed keys be rotated without interrupting critical automation?