← Actions Cache Poisoning Check
GitHub Actions Cache Poisoning Check vs. zizmor
Both name the same risk and check different sides of it. zizmor's cache-poisoning
audit looks at whether a release job is trusting a cache it should not. This tool looks at whether a fork
can write that cache in the first place, and whether restore-keys can adopt a poisoned entry --
in any workflow, free, in your browser, with nothing to install.
What each tool is for
zizmor (github.com/zizmorcore/zizmor) is an open-source, MIT-licensed static
analysis tool for GitHub Actions, installed with pip install zizmor or
cargo install zizmor and run against workflow files or a whole repository. Its
cache-poisoning audit, per its own documentation, detects potential cache-poisoning scenarios
in release workflows: it identifies a job as a release or publish step by its trigger (a tag push, a
release event) or by its use of a known publisher action (pypa/gh-action-pypi-publish,
softprops/action-gh-release, and similar), and flags one that also has a cache-aware action
enabled -- actions/cache and roughly two dozen others, including framework-specific ones such
as actions/setup-node and Swatinem/rust-cache -- on the reasoning that a release
pipeline should not restore a cache an earlier, less-trusted run may have written.
This checker looks at the other side of the same risk, in any workflow rather than only
release ones: you paste the YAML of a workflow file, and it lists every actions/cache or
actions/cache/save write step reachable from a pull_request_target or
workflow_run trigger -- where a fork's pull request controls what gets written -- and every
restore-keys fallback with no explicit scope, which can adopt a colliding entry written by an
unrelated, unprivileged job. It runs entirely in your browser, needs no install and no token, and makes no network call of its own under any configuration.
| Question | Where to answer it |
|---|---|
| I want to know whether a release/publish job in my repo is trusting a cache an earlier, less-trusted run could have written. | zizmor's cache-poisoning audit -- that is exactly the scenario it targets. |
I want to know whether a pull_request_target or workflow_run job in my repo can write to the Actions cache. | This checker -- zizmor's audit does not check who wrote a cache entry, only whether one is active in a job it identifies as a release step. |
I want to know whether my restore-keys fallback can adopt an entry a different, unprivileged job wrote. | This checker -- restore-keys is outside the scope of zizmor's cache-poisoning audit entirely. |
| I want one maintained scanner covering dozens of GitHub Actions security patterns beyond caching -- permissions, credential leakage, injection, impostor commits, and more. | zizmor -- that breadth is its whole job; this tool checks only the two cache patterns above. |
| I don't want to install a CLI (pip or cargo) or add a new GitHub Action just to check one file. | This checker -- it is a page, not a package. |
The two are complementary, not competing: a repository can run zizmor in CI for the release-workflow question and still reach for this tool the moment the question is the write side or restore-keys, which zizmor's cache-poisoning audit does not check.
Common questions
Should I use this checker or zizmor's cache-poisoning audit?
They both name GitHub Actions cache poisoning but check different sides of it. zizmor is an open-source, MIT-licensed static analysis CLI (installed with pip install zizmor or cargo install zizmor) whose cache-poisoning audit, per its own documentation, detects potential cache-poisoning scenarios in release workflows -- it looks at jobs it recognises as publishing a release (a tag-push or release trigger, or a known publisher action such as pypa/gh-action-pypi-publish or softprops/action-gh-release) and flags one still using a cache-aware action there, on the reasoning that a release pipeline should not trust a cache an earlier, less-trusted run could have written. This checker looks at the other side of the same risk, in any workflow, not only release ones: an actions/cache or actions/cache/save write step reachable from a pull_request_target or workflow_run trigger -- where a fork controls what gets written -- and an unscoped restore-keys fallback that can adopt a colliding entry regardless of who wrote it. Run zizmor for the release-workflow question; paste a file here for the write-side and restore-keys questions.
Does zizmor's cache-poisoning audit already catch what this tool catches?
Not the same ground. zizmor's audit is scoped to release workflows specifically and, per its published source, does not inspect restore-keys at all -- it checks whether a cache-aware action (actions/cache and roughly two dozen others, including framework-specific ones like actions/setup-node and Swatinem/rust-cache) is active in a job it has identified as a publish step, and suggests turning caching off there. This tool's two findings -- a cache write reachable from pull_request_target/workflow_run, and an unscoped restore-keys fallback -- are not the release-workflow question zizmor asks, so a clean zizmor run on a repository can still carry either of this tool's findings, and a clean scan here says nothing about whether a release job is needlessly trusting a cache.
Why use a narrower tool if zizmor already covers more ground?
Two reasons. First, zizmor is a CLI you install and point at files or a repository; this tool is a page you paste a workflow into, with nothing to install, which is faster when you want an answer on the one file in front of you. Second, and more to the point, the two catch genuinely different patterns rather than one being a subset of the other: zizmor's audit does not look at restore-keys or at which trigger wrote a cache entry, so a repository can pass its release-workflow check and still have a fork-writable cache or an unscoped restore-keys fallback that this tool exists to name.
Does this tool need a GitHub token the way zizmor sometimes does?
No, never. zizmor documents an optional online mode -- set GH_TOKEN, GITHUB_TOKEN, or ZIZMOR_GITHUB_TOKEN -- for audits that benefit from GitHub API access, and runs offline by default otherwise, which already covers its cache-poisoning audit. This tool has no online mode to opt into: nothing here talks to a server under any configuration, so there is no token to supply.
Is this page affiliated with zizmor or its maintainers?
No. This site is not affiliated with, endorsed by, or sponsored by zizmor, zizmorcore, or its maintainers. zizmor is an independent open-source project, named here only to describe what this checker is and is not, using facts drawn from its own public documentation and source at github.com/zizmorcore/zizmor and docs.zizmor.sh.