GitHub Actions cache poisoning

Expanded Definition

GitHub Actions cache poisoning is a workflow compromise pattern in which an attacker influences the contents of a reusable cache so a later job restores untrusted code or artefacts under a trusted build context. It is closely related to broader CI/CD trust failures, but the defining feature is the abuse of cache reuse across jobs, branches, or pull request boundaries.

Definitions vary across vendors and incident write-ups, but the security issue is consistent: a cache is treated as an optimisation layer, then silently becomes an execution path. In NHI security terms, the risk is amplified when GitHub tokens, repository permissions, or build credentials allow write access to cacheable paths without strict branch isolation. NIST SP 800-53 Rev 5 frames this kind of issue through configuration management, least privilege, and software integrity controls, while supply chain guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls helps anchor the governance model.

The most common misapplication is assuming cache scope is harmless when a cache key is broad, branch protection is incomplete, or untrusted workflows can write artefacts that trusted jobs later restore.

Examples and Use Cases

Implementing cache controls rigorously often introduces slower builds and more complex key design, requiring organisations to weigh pipeline speed against provenance assurance.

• A pull request workflow writes a poisoned dependency cache, and the main branch later restores it during a release build.
• A compromised maintainer token seeds a cache with a modified script that is executed when a trusted workflow rehydrates build artefacts.
• An organisation uses shared cache keys across multiple repositories, creating cross-project contamination risk after one runner is compromised.
• An incident response team traces secret leakage in CI after a cache restored malicious tooling, similar to patterns documented in the Reviewdog GitHub Action supply chain attack and the GitHub Action tj-actions Supply Chain Attack.
• A security team hardens cache restore rules after studying the CI/CD pipeline exploitation case study and comparing controls against NIST SP 800-53 Rev 5 Security and Privacy Controls.

These cases show that cache poisoning is not only about code execution. It can also alter dependency resolution, embed malicious build steps, or expose secrets that downstream jobs assume are safe.

Why It Matters in NHI Security

Cache poisoning matters because CI/CD systems often operate with privileged non-human identities such as GitHub tokens, runner credentials, package publishing keys, and deployment secrets. Once a poisoned cache is trusted by an automated workflow, the attacker can pivot from artefact tampering into secret theft, release manipulation, or persistent supply chain compromise. That is why this term belongs in NHI governance, not just application security.

NHI Management Group research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 97% of NHIs carry excessive privileges. In a cache-poisoning scenario, those conditions turn a build optimisation into an identity abuse pathway. The same exposure pattern is visible in the Shai Hulud npm malware campaign and the SpotBugs Token GitHub Supply Chain Attack, where trust in automation became the compromise multiplier.

Organisations typically encounter the real cost only after a release artifact, dependency bundle, or signing step has already been altered, at which point cache poisoning becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams reduce risk from compromised GitHub Actions workflows?
• What breaks when a GitHub Actions workflow component is compromised?
• What breaks when GitHub Actions workflows run untrusted pull requests with write access?
• How do organisations know if GitHub Actions permissions are too broad?