ZIZMOR · CVE-2026-102289 · Package
FIX → 1.28.0
zizmor 1.27.0 prints the GitHub token from GH_TOKEN, GITHUB_TOKEN, ZIZMOR_GITHUB_TOKEN or the matching flags into its debug log when verbose logging is on. Anyone who can read those logs, such as a public bug report or CI log, can take the token and act with its GitHub permissions.
first public Nov 9, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Teams that run zizmor 1.27.0 with a GitHub credential supplied and debug logging enabled, where the stderr output is stored or shared. Runs without a GitHub token, without verbose logging, or with --offline (which clears the token before logging) are not exposed. Version 1.26.1 and earlier are not affected.
Not affected if default-logging, no-github-token, offline-mode, version-1.26.1-or-earlier
Who cares ci, github-actions, python, zizmor
pip show zizmor and confirm the version is 1.27.0.-v, --verbose, or a RUST_LOG directive) is used in CI jobs or scripts that run zizmor and keep their stderr.Upgrade to 1.28.0
zizmor 1.27.0 exposes GitHub access tokens in cleartext when debug-level logging is enabled. Tokens supplied via environment variables (GH_TOKEN, GITHUB_TOKEN, ZIZMOR_GITHUB_TOKEN), or the corresponding command-line options (--gh-token, --github-token, --zizmor-github-token) are included in the debug representation of the parsed application configuration and written to stderr.
The affected logging is enabled by a single -v/--verbose or an applicable RUST_LOG directive.
The issue was introduced in commit 919bea46, merged through PR #2180. Version 1.26.1 and earlier are unaffected. Version 1.27.0 is the first and only affected release.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
zizmor 1.28.0 (fixed version per the product data; upgrading from 1.27.0 is the fix stated by the sources).zizmor accepts GitHub credentials to perform authenticated GitHub API requests for the purposes of retrieving remote GitHub repositories and performing online audits that may require resolving information such as action references, commits, or repository metadata. A GitHub credential is used to avoid unauthenticated API limits and, when applicable, provide access to private repositories.
PR #2180 was intended to improve the experience around zizmor’s implicit offline mode. It also moved the CLI types into a dedicated module and added a debug log of the fully parsed App value:
tracing::debug!("app: {app:?}");
This diagnostic is useful for understanding the effective CLI state, including whether offline operation was explicit or inferred. However, the same commit added derived Debug implementations to App, NetworkArgs, and GitHubToken(String).
Before the debug event is emitted, the compatibility token aliases are merged into app.network.gh_token.
The resulting stderr contains the token verbatim. Explicit --offline clears the token before the debug event, but normal online operation and --no-online-audits retain it.
Using zizmor at v1.27.0:
GH_TOKEN=gho_ZIZMOR_MRE zizmor --verbose example.yml
will emit
DEBUG zizmor: app: App { input: InputArgs { inputs: ["example.yml"], collect: [Default], strict_collection: false }, audit: AuditArgs { fix: None, pedantic: false, persona: Regular, min_severity: None, min_confidence: None, no_ignores: false }, output: OutputArgs { verbose: Verbosity { verbose: 1, quiet: 0, phantom: PhantomData<clap_verbosity_flag::InfoLevel> }, format: Plain, no_progress: false, color: None, render_links: Auto, show_audit_urls: Auto, no_exit_codes: false, naches: false }, network: NetworkArgs { offline: false, gh_token: Some(GitHubToken("gho_ZIZMOR_MRE")), github_token: None, zizmor_github_token: None, gh_hostname: Standard("github.com"), no_online_audits: false, cache_dir: "/Users/shaan/.cache/zizmor" }, args: GlobalArgs { lsp: LspArgs { lsp: false, stdio: false }, config: None, no_config: false, completions: None, thanks: false, help: (), version: () } }
In practice, the impact of this vulnerability should be mediated by GitHub's own layered defenses, including secret redaction in Actions logs and automatic credential revocation in issue/PR/etc. comments. However, zizmor itself should never log sensitive materials, and so the behavior is still considered vulnerable even if compensating controls exist in downstream systems.
An affected user must enable debug logging while supplying a GitHub credential, and the resulting stderr must be available to another party. Plausible disclosure channels include a public bug report, CI log or artifact, or terminal capture. A potential attacker only needs permission to read the disclosed logs.
The resulting impact depends on the token's scopes, repository access, and lifetime. A minimally scoped token may only expose public read-only data, while a broader OAuth token or personal access token may permit private-repository or modification of repositories, packages, workflows, or organization resources. The default informational logging level is unaffected. Exploitation requires debug logging and subsequent log exposure, which limits likelihood.
Notably, because zizmor’s bug-report template asks users to rerun commands with --verbose and paste the complete logs, this can result in credentials being copied into public issues or other support channels.
GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.