CVE-2026-102289: zizmor: Debug logging prints available GitHub credentials in cleartext

Summary

zizmor 1.27.0 exposes GitHub access tokens in cleartext when debug-level logging is enabled. Tokens supplied via environment variables (GHTOKEN, GITHUBTOKEN, ZIZMORGITHUBTOKEN), 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 RUSTLOG directive.

Details

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.

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:

rust 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.ghtoken.

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.

PoC

Using zizmor at v1.27.0:

GHTOKEN=ghoZIZMORMRE zizmor --verbose example.yml

will emit

text DEBUG zizmor: app: App { input: InputArgs { inputs: ["example.yml"], collect: [Default], strictcollection: false }, audit: AuditArgs { fix: None, pedantic: false, persona: Regular, minseverity: None, minconfidence: None, noignores: false }, output: OutputArgs { verbose: Verbosity { verbose: 1, quiet: 0, phantom: PhantomData<clapverbosityflag::InfoLevel> }, format: Plain, noprogress: false, color: None, renderlinks: Auto, showauditurls: Auto, noexitcodes: false, naches: false }, network: NetworkArgs { offline: false, ghtoken: Some(GitHubToken("ghoZIZMORMRE")), githubtoken: None, zizmorgithubtoken: None, ghhostname: Standard("github.com"), noonlineaudits: false, cachedir: "/Users/shaan/.cache/zizmor" }, args: GlobalArgs { lsp: LspArgs { lsp: false, stdio: false }, config: None, noconfig: false, completions: None, thanks: false, help: (), version: () } }

Impact

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.