The Cache Finally Got a Permission Boundary

EVIDENCE — On 10 September 2026, GitHub made cache-mode generally available on GitHub.com for every plan. A workflow or individual job can now receive read, write, write-only, or no cache access. GitHub says the cache service enforces the choice through scoped cache tokens. When the setting is omitted, trusted triggers such as push receive write access, while low-trust triggers such as pull_request_target, issue_comment, and workflow_run receive read-only access to caches in the default branch's scope.

A CACHE IS PART OF THE EXECUTION PATH — GitHub's security guidance states that cache contents are not signed or verified and that restored files may later be executed by a workflow. That makes cache poisoning a supply-chain problem, not merely a build-performance problem: code running in one job can plant compiler outputs, package data, generated scripts, or other files that a more privileged job restores and trusts. The new modes let maintainers express separately whether a job needs to consume prior state, publish future state, do both, or touch no cache at all.

THE BOUNDARY PROPAGATES ONLY WHEN IT IS EXPLICIT — A job-level mode overrides the workflow-level setting. An explicitly limited caller also caps the cache access of a reusable workflow; the called workflow cannot ask for more and the run fails validation if it tries. But GitHub documents an important exception: when the calling job neither sets nor inherits an explicit mode, a reusable workflow can explicitly request write access even if the caller's low-trust trigger would otherwise default to read. Teams relying on reusable workflows should therefore declare the caller's intended ceiling rather than assume trigger defaults always propagate.

SECURE DEFAULTS CAN BE OVERRIDDEN—AND SKIPS CAN LOOK GREEN — Explicitly setting write or write-only on a low-trust trigger overrides GitHub's read-only default and reintroduces cache-poisoning risk; GitHub adds a warning annotation in that case. Conversely, a disallowed restore or save is logged and skipped without failing the workflow. A skipped restore becomes a cache miss, and a skipped save simply does not happen. Successful job status therefore does not prove the cache operated as intended; rollout checks need to inspect logs and build behavior as well as the final check mark.

WHAT TO CHECK — Inventory workflows triggered by pull_request_target, issue_comment, workflow_run, forks, and other externally influenced events, then identify every direct or implicit cache user. Declare cache-mode: read or none for jobs that process untrusted input; let a trusted push workflow maintain shared caches when performance requires them. Put explicit limits on jobs that call reusable workflows, and reserve write or write-only for tightly scoped producers that do not process attacker-controlled code before saving. Review warning annotations and cache logs after rollout, keep secrets out of cached paths, protect .github/workflows with CODEOWNERS, minimize GITHUB_TOKEN permissions, and pin third-party actions to full commit SHAs.