GitHub Actions Adds cache-mode to Limit Cache Poisoning Risk
GitHub Actions now supports cache-mode, a least-privilege control on the Actions cache aimed at the cache poisoning technique behind recent compromises.
- Sarah Gooding
GitHub has added cache-mode
to GitHub Actions, a new setting that limits how workflows and jobs can access the Actions cache. It targets cache poisoning, the technique attackers used to compromise the Ultralytics PyPI package in 2024 and the TanStack npm packages in May 2026.
Cache poisoning works because an entry written to the shared Actions cache in one context can be restored and run in another. An attacker who gains write access to a cache key that a trusted workflow later reads can plant malicious build artifacts or dependencies that execute with that workflow's permissions and secrets. In the TanStack attack, chained with a pull_request_target
pwn request, the attacker published 84 malicious versions across 42 @tanstack/*
packages.
Build provenance does not catch a poisoned cache. In its design proposal, GitHub noted that SLSA provenance and Sigstore signatures still pass on a build that restored a tampered entry, because the build ran where and when the workflow declared. The attestation covers the build's origin, not the integrity of the inputs it pulled from the cache.
cache-mode Sets Cache Access Per Workflow or Job
cache-mode lets maintainers apply least-privilege access to the cache at the workflow or job level. It supports four values:
read
restores caches but blocks saves. This is the default for low-trust events such aspull_request_target
.write
restores and saves caches. This is the default for trusted events such aspush
.write-only
saves caches but blocks restores.none
blocks all cache access.
Job-level settings override workflow-level settings, and the cache service enforces the mode. The setting also 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 adds a warning annotation when a declared mode grants write access.
GitHub recommends none
as a control for AI agent workflows. In the design proposal, it describes agent-driven workflows that act on issue or pull request text as a case that can execute untrusted input, the exposure behind the Cline compromise, where a prompt injection in a GitHub issue led to a suspected cache poisoning attack. Setting cache-mode: none
removes the cache from that environment.
GitHub Added write-only Based on Public Feedback
GitHub opened the cache-mode design in May 2026 with three values: read
, write
, and none
. Security researcher Adnan Khan, whose cache poisoning research GitHub cited in the proposal, pushed for a write-only
mode so a trusted branch can populate a cache without ever restoring from one. That value shipped in the final release.
cache-mode Does Not Cover Other Actions Risks
GitHub shipped read-only cache defaults for most untrusted triggers in June 2026, so workflows that never configured caching were already blocked from saving poisoned entries through those events. cache-mode adds the configurable layer on top: per-job control, the none
option, cache-service enforcement, and the cap on access through reusable workflows.
It does not close the broader set of 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 seen in the TanStack attack and in GitHub's earlier checkout hardening.
GitHub recommends granting each workflow or job only the cache access it needs, the least-privilege approach cache-mode is built to support.