GitHub Actions Adds cache-mode to Limit Cache Poisoning Risk

Summary

GitHub Actions has introduced a new 'cache-mode' setting to combat cache poisoning attacks. This feature allows developers to control how workflows and jobs access the Actions cache, limiting the risk of malicious artifacts being injected and executed. The update addresses vulnerabilities exploited in the Ultralytics PyPI and TanStack npm packages.

Full text

BackSecurity NewsGitHub Actions Adds cache-mode to Limit Cache Poisoning RiskGitHub Actions now supports cache-mode, a least-privilege control on the Actions cache aimed at the cache poisoning technique behind recent compromises.Sarah GoodingSep 16, 2026|2 min readGitHub 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 as pull_request_target.write restores and saves caches. This is the default for trusted events such as push.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.

Entities