A GitHub App installation can mint short-lived access tokens scoped to a repository's granted permissions. An attacker who compromises the App's private key or a runner that carries the installation mints fresh tokens with scopes like contents:write and pull_requests:write, then reads private repositories, pushes code, or opens malicious pull requests. Defend by protecting the App key, minimising installation scopes, and monitoring token minting.
What GitHub App token abuse is
A GitHub App authenticates with a private key and, per installation, mints short-lived tokens scoped to the permissions the installation was granted. Those tokens are powerful automation credentials, so the App's private key and any environment that can mint installation tokens are high-value targets.
How it works and example
The attacker obtains the App's private key or lands on a CI runner that already holds the installation, then mints fresh installation tokens with write scopes. With contents:write and pull_requests:write they list internal repositories, read source for infrastructure details, push code, and open pull requests to trigger pipelines, as seen in a 2026 supply-chain intrusion.
How to defend against it
Store the App private key in a hardware or managed secret store and rotate it, and grant each installation the least permissions and repository scope it needs. Keep token TTLs short, audit installation-token creation and use, alert on unexpected minting or scope, and separate high-privilege automation from environments that run untrusted code.
References
- [1]MITRE ATT&CK: Credential Access (TA0006)(MITRE ATT&CK)
- [2]HuggingFace, Agent intrusion technical timeline(HuggingFace)
- [3]MITRE ATT&CK: Steal Application Access Token (T1528)(MITRE ATT&CK)
An App key is a master key to your repos and pipelines. Talk to a security expert about how yours is stored, scoped, and monitored.