GitHub announced on 10 September 2026 that cache-mode is generally available for GitHub Actions on all plans. The new setting makes cache privileges explicit: a workflow or job can restore caches, save them, do both in controlled combinations, or receive no cache access. That matters because a cache is executable supply-chain input whenever later jobs restore dependencies, build outputs or tool state from it.
What happened: cache access became an enforceable permission
Teams can declare cache-mode at workflow or job level. Read permits restores but blocks saves; write permits both restores and saves; write-only permits saves without restores; and none blocks cache access entirely. A job-level declaration overrides the workflow setting.
The cache service enforces the selected mode. The restriction also carries through reusable workflows: a called workflow cannot gain more cache access than its caller granted. This turns the caller's trust decision into a real boundary rather than relying on conventions inside shared automation.
GitHub keeps secure defaults for workflows that do not declare the setting. Low-trust events such as pull_request_target default to read access, while trusted push events default to write access. If a low-trust workflow explicitly requests write or write-only access, GitHub adds a warning annotation.
Why it matters: a fast build can still consume attacker-controlled state
CI caches often contain dependency archives, compiler output and intermediate artifacts that a trusted workflow later consumes. If an untrusted or over-privileged workflow can replace that state, the next build may execute or publish content that was never reviewed in the source change.
Least privilege narrows that path. Pull-request validation normally needs to read a trusted cache for speed, but it rarely needs to update the cache used by release jobs. A packaging job may need to save a narrowly scoped result without restoring older state. Sensitive signing or deployment jobs may need no shared cache at all.
The new control does not make every cache safe. Cache keys, restore-key fallbacks, action versions, event choice and artifact provenance still determine what state crosses trust boundaries. An explicit write grant on a low-trust trigger remains a security exception even when the platform warns about it.
The practical implication: map trust before setting the mode
Inventory workflows by trigger and consequence. Separate untrusted pull-request checks, trusted branch builds, reusable workflows, release packaging and deployment. For each job, record whether it genuinely needs to restore state, save state, both or neither, then declare the narrowest cache-mode instead of inheriting a broad workflow permission.
Test the effective permission across reusable-workflow boundaries and confirm low-trust jobs cannot populate a cache later consumed by privileged jobs. Review cache keys for branch, platform, toolchain and lockfile separation; avoid broad restore prefixes that silently cross those boundaries.
Roll out with evidence. Record denied cache operations, warning annotations, hit rate and build duration, and keep an approved exception path for the rare low-trust job that must write. Pin third-party actions, review pull_request_target usage and invalidate suspect caches after any workflow compromise—the permission is one layer in a wider CI supply-chain control set.
Key takeaways
Declare the narrowest cache-mode for each workflow or job; do not give pull-request validation write access simply for convenience.
Verify that reusable workflows cannot widen their caller's permission and that cache keys keep trusted and untrusted state separate.
Treat low-trust writes as reviewed exceptions, monitor warnings and denied operations, and invalidate caches during incident response.
Sources
This article is original analysis written by IT Web Builder. The reporting and product details below were used as references and are credited to their publishers.
GitHub Changelog — Control GitHub Actions cache access with cache-modePublished 10 September 2026. Primary announcement for access modes, event defaults, service enforcement, reusable-workflow inheritance, warnings and general availability. Security recommendations are IT Web Builder Editorial analysis.↗GitHub Documentation — Workflow syntax for cache-modeOfficial configuration reference linked from GitHub's announcement; teams should confirm current syntax and supported placement before rollout.↗GitHub Security Lab — Preventing pwn requestsGitHub-authored background on trust boundaries and the risks of privileged workflow patterns when processing untrusted pull-request content.↗IT Web Builder publishes original summaries and practical commentary. We do not reproduce source articles. Product claims and announcements are linked to their original publishers so readers can verify the details.