Cache poisoning breaks the assumption that a restored workflow artifact is inert. If a privileged job can restore attacker-controlled content, the workflow can execute malicious code under trusted build permissions, inherit publishing rights and seed the next infection without a fresh package install. That turns the CI pipeline into a propagation engine rather than a passive delivery system.
When cache poisoning turns a CI workflow into an infection path
github actions cache poisoning breaks a trust boundary that many build systems quietly rely on: the idea that a restored cache is just an efficiency aid, not an execution source. Once an attacker can influence that cache, the workflow may load hostile content into a privileged job, and the pipeline stops being a passive delivery lane. It becomes a vehicle for code execution and onward spread.
The key change is not just that malware runs once. It runs inside the same automation context that usually has repository write rights, secret access, release permissions, or publishing authority. That is why cache poisoning is a propagation problem, not merely a code-injection problem.
In practice, the compromise path often starts with a lower-trust workflow or an upstream artifact that is allowed to populate cache state. If later jobs restore that state without strict isolation, the poisoned cache can influence build steps, script execution, dependency handling, or package publication. The attack succeeds because the pipeline treats prior build output as if it were inert input.
Why the blast radius grows so quickly
The damage comes from privilege inheritance. A cache hit inside a trusted job can carry attacker-controlled content into steps that can sign artifacts, publish packages, update release assets, or write back to the repository. If the job also exposes tokens or cloud credentials, the poisoned cache can help the attacker move from code execution to secret theft and then to lateral reuse of those secrets elsewhere.
This is why cache poisoning is especially dangerous in CI/CD systems with shared runners, broad default permissions, or long-lived credentials. One compromised restore path can seed many downstream jobs, and a single malicious job can contaminate future runs if cache keys or restore rules are too broad.
In other words, the technical failure is a mismatch between trust and provenance. The workflow assumes the cache reflects legitimate prior work, but the attacker has made the cache part of the attack surface.
What breaks operationally after the first compromise
Once malicious content is restored, several operational assumptions fail at once. Build integrity no longer means the job came from clean source and clean dependencies. Release integrity no longer means published output was assembled only from trusted inputs. Incident response also becomes harder because the same cache mechanism that accelerated builds can hide the point where malicious state first entered the pipeline.
This is why cache poisoning often behaves like a propagation engine. The first run may only execute malware, but later runs may reuse the same poisoned state, spread altered artifacts, or continue exposing secrets until the cache is invalidated and the workflow design is corrected.
Risk and Threat Considerations
Cache poisoning is risky because it weaponises a performance feature to bypass build trust boundaries. The attacker does not need to replace the whole repository, only to influence a restore path that a privileged job will trust.
Failure mechanism: A workflow restores attacker-controlled cache content into a privileged build context, then executes that content or uses it to shape a later publish step.
Impact: The pipeline can leak secrets, sign or publish tainted output, and propagate the compromise into subsequent jobs, releases, or dependent projects.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1056 — Input Capture | Cache poisoning abuses trusted build input handling and workflow execution paths. |
| Recommendation — Map poisoned cache restores to attacker-controlled input paths and hunt for workflow execution anomalies. | ||
| CIS Controls v8 | CIS-5 — Account Management | Privileged CI jobs and publishing accounts expand impact when cache content is trusted too broadly. |
| Recommendation — Restrict privileged workflow identities and rotate any credentials exposed through poisoned builds. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Cache poisoning undermines integrity of build inputs, outputs, and downstream artifacts. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Compromised cache use requires logs to trace restore paths and job execution. | |
| Recommendation — Validate build inputs and artifact integrity before any publish or deployment step. Review CI logs for unexpected cache hits, restore keys, and publish-time anomalies. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The issue is an architectural trust-boundary failure in how build steps consume state. |
| Recommendation — Design workflows so untrusted cached state cannot alter privileged execution paths. | ||
Practitioner Guidance
What to verify: Treat every cache restore rule as a trust decision. Verify which jobs can write caches, which jobs can read them, and whether restore keys can cross branches, forks, or release boundaries.
What good looks like: Cache use is tightly scoped to low-risk build data, privileged jobs do not consume untrusted restore state, and publishing steps depend on fresh, auditable inputs rather than cached execution artifacts.
Decision rule: If a cached object can influence code execution, package creation, or secret exposure, handle it as potentially hostile until provenance and scope are explicit.
Practitioner takeaway: The control objective is not “safe caching” in the abstract, but preventing untrusted restored state from reaching any job that can publish, sign, or exfiltrate.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org