How GitHub Actions Workflows Can Leak Secrets

GitHub Actions runs automated jobs that often need access to credentials such as deployment keys and API tokens. Those same workflows can become a path for leaking secrets if they are configured carelessly. GitHub’s own secure use guidance for Actions, published at https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions, sets out where the risks come from and which configuration choices reduce them.

Where Secrets Can Be Exposed

A core warning in the guidance is that automatic redaction of secrets in logs is not guaranteed. Redaction relies on an exact match of the stored value, so a secret that has been transformed will not be hidden. GitHub recommends avoiding structured data such as JSON, XML, or YAML as secret values, because those formats break the matching that redaction depends on. Any value derived from a secret, for example a signed token or a Base64-encoded copy, should be registered as a secret so that it is also redacted in logs.

The guidance also notes that tools invoked inside a workflow may print secrets to standard output or standard error in ways that are not expected. For that reason it advises auditing logs after testing new inputs, and rotating any secret that may have been exposed, since redaction only protects values the runner actually used.

Untrusted Input and Privileged Triggers

Workflows that act on data from pull requests face an additional hazard. Values such as a pull request title are untrusted input, and embedding them directly into a shell script can allow script injection. GitHub suggests passing such values through an intermediate environment variable, or using a JavaScript action that receives the value as an argument, so the untrusted text does not interfere with how the script is generated.

The pull_request_target and workflow_run triggers run with a privileged context. The guidance describes these as a security risk when they are combined with checking out untrusted code from a fork, and recommends avoiding them unless the privileged context is genuinely required. Artifacts produced by other workflows should also be treated with caution.

Limiting What a Workflow Can Do

Two recurring recommendations in the document address the blast radius of a compromise. The first is least privilege: anyone with write access can read all repository secrets, so credentials used in workflows should have the minimum privileges needed. GitHub advises setting the default GITHUB_TOKEN permission to read-only for repository contents, then raising permissions per job only where a workflow requires them.

The second is controlling third-party actions. A single compromised action can reach every repository secret and may be able to write changes through the GITHUB_TOKEN. The guidance recommends pinning actions to a full-length commit SHA, which it describes as the only way to use an action as an immutable release, and auditing an action’s source to confirm it does not send secrets to unintended hosts. Self-hosted runners are flagged as risky on public repositories because they can be persistently compromised by untrusted code.

Supporting Practices

Beyond configuration, the guidance points to features that reduce reliance on long-lived secrets and risky dependencies. OpenID Connect can supply short-lived cloud credentials in place of stored secrets. CODEOWNERS can gate changes to workflow files, while Dependabot, code scanning, dependency review, and OpenSSF Scorecards help surface vulnerable or risky supply chain practices before they reach production.