Yes. If a pipeline or a dependency was compromised, delete the CI caches and rebuild from clean inputs. GitHub's documentation notes cache contents are not signed or verified, so restored files may have been modified and later executed. A cache can keep a bad file alive after the cause is gone.
Why caches are a recovery risk
Caches exist to speed up builds. They hold downloaded dependencies, build outputs and tool installs. In an incident review the cache is easy to forget, because nothing about it appears in source control.
GitHub's documentation on dependency caching says three things worth acting on:
- Anyone with read access to a repository can create a pull request and read cache contents, so credentials should never be placed in cached paths.
- Cache contents are not signed or verified, so a modified file may be restored and executed.
- Some low trust triggers get read-only access to default branch caches, while others, such as push and scheduled runs, can create or overwrite them.
How scope works
A run can restore caches from its own branch or the default branch, and pull request runs can also restore from the base branch. Caches created by pull request runs are scoped to the merge ref. Entries not accessed for more than 7 days are removed, and the oldest are evicted when the repository reaches its limit.
The takeaway: a poisoned entry on the default branch can be restored by many later runs, so it is the one to worry about most.
Steps after a suspected compromise
- Pause pipelines that write to shared caches.
- List caches for the repository and note creation times. Compare with your incident timeline.
- Delete all caches created at or after the earliest suspected time. When unsure, delete them all.
- Rotate any secret that could have been written into a cached path. Do not rely on deletion for that.
- Rebuild from a clean runner with a lockfile install and verify artifact hashes against a known good build.
- Re-enable caching with narrower scope, and confirm only trusted triggers can write default branch caches.
Design caching so it hurts less
| Practice | Benefit |
|---|---|
| Cache only dependency downloads, not build outputs you ship | Shipped files come from a fresh build |
| Key caches on a lockfile hash | A changed lockfile means a new cache |
| Never cache credentials or tokens | Cache readers cannot steal them |
| Build release artifacts without restoring caches | Releases do not inherit cache state |
| Verify hashes after restore | Catches modified files |
Related caches
The same reasoning applies to other stores: container layer caches, package manager caches on self hosted runners, and build tool caches on long lived machines. Self hosted runners keep state between jobs, so wipe or recreate them as part of recovery.
Safeguard can scan lockfiles and dependencies, and its policy gates can block a pull request that adds a risky package. Try the free scan.
Quick check
Does deleting the cache fix the compromise?
No. It removes one place a bad file could persist. You still need to find the entry point and rotate secrets.
Will deleting caches slow my builds?
Yes, for the first runs, until caches are rebuilt. That is an acceptable price during recovery.
Sources
Last reviewed: 19 October 2026.
