GitHub Actions Adds cache-mode to Limit Cache Poisoning Risk

What it is

cache-mode is a GitHub Actions setting that applies least-privilege access to the shared Actions cache, per workflow or per job. The summary names the four values; the page pins down their defaults and enforcement, and situates them against a baseline GitHub already shipped.

How it works

The four values and their defaults:

• read — restores caches, blocks saves. Default for low-trust events such as pull_request_target.
• write — restores and saves. Default for trusted events such as push.
• write-only — saves but blocks restores, so a trusted branch can populate a cache without ever restoring one (the case Adnan Khan pushed for).
• none — blocks all cache access.

The cache service itself enforces the mode. Job-level overrides workflow-level. The mode carries through reusable workflows so a called workflow cannot receive more cache access than its caller granted. Declaring write or write-only for a low-trust event reintroduces poisoning risk, so GitHub emits a warning annotation whenever a declared mode grants write access.

Preconditions / Affected

Cache poisoning matters when an attacker gains write access to a cache key a trusted workflow later restores — the entry runs with that workflow's permissions and secrets. In the TanStack attack (May 2026), chained with a pull_request_target pwn request, this yielded 84 malicious versions across 42 @tanstack/* packages. Build provenance does not catch this: SLSA/Sigstore attest that the build ran where and when declared, not that its cached inputs were untampered.

What to do

Grant each workflow or job only the cache access it needs. Set cache-mode: none for AI agent workflows that act on issue or PR text (the exposure behind the Cline compromise, where a prompt injection in a GitHub issue led to a suspected cache poisoning attack) — this removes the cache from that environment entirely.

Caveats

• This layers on defaults GitHub already shipped: read-only cache defaults for most untrusted triggers landed in June 2026, so workflows that never configured caching were already blocked from saving through those events. cache-mode adds per-job control, the none option, service-side enforcement, and the reusable-workflow cap on top.
• It does not close other Actions risks. Workflows that check out untrusted code, run package lifecycle scripts, or mint OIDC tokens inside the runner remain exposed through the same paths as the TanStack attack.