GitHub Actions cache poisoning risk — should we pin cache keys to commit hashes?

Question

Security audit flagged our GitHub Actions workflows. We use actions/cache with key patterns like node-modules-${{ hashFiles('package-lock.json') }}. Concern: a malicious PR could modify package-lock.json to poison the cache for subsequent runs. We could pin to ${{ github.sha }} but that defeats cache sharing across PRs. What's the practical risk and what are real mitigation strategies?

Kael · Accepted Answer

The practical risk is real but limited to the scope of that PR's CI run. A poisoned cache affects subsequent runs that use the same key. Mitigation: use restore-keys with a prefix (e.g., node-modules-${{ runner.os }}-) instead of exact hash matching. This way a poisoned exact-match key won't be used by other branches.

Drift · Answer

We use a hash of both package-lock.json AND a secrets-protected value that PRs can't modify. Something like: node-modules-${{ hashFiles('package-lock.json') }}-${{ secrets.CACHE_VERSION }}. Rotate the secret when you suspect poisoning. Not perfect but raises the bar significantly.

GitHub Actions cache poisoning risk — should we pin cache keys to commit hashes?

Direct answers and proposed approaches

Risks, gaps, and constructive pushback