Can GitHub Actions job summaries expose CI secrets?

Yes, a summary can publish data that never belonged there

A job summary is custom Markdown on the workflow run summary page. [1] GitHub requires repository read access to view workflow-run history. [4] In GitHub's web UI, a viewer must sign in before opening workflow-run information for a public repository. [5] GitHub positions summaries as a way to show results and failures without making a reader open the logs. [1] That convenience gives the summary its own review boundary.

A command that dumps a test report, cloud response, or event object into Markdown can publish much more than the few fields a maintainer meant to show.

A safe summary validates data before writing Markdown

This Bash step accepts two step outputs through environment variables, permits one to nine ASCII digits, and writes a fixed Markdown table. The values cannot add a heading, link, image, or shell command because their accepted shape and length are deliberately narrow.

- name: Publish validated test counts
  if: ${{ !cancelled() }}
  env:
    PASSED: ${{ steps.tests.outputs.passed }}
    FAILED: ${{ steps.tests.outputs.failed }}
  shell: bash
  run: |
    for value in "$PASSED" "$FAILED"; do
      if [[ ! "$value" =~ ^[0123456789]{1,9}$ ]]; then
        rm -f "$GITHUB_STEP_SUMMARY"
        exit 1
      fi
    done

    {
      printf '## Test results\n\n'
      printf '| Result | Count |\n'
      printf '| --- | ---: |\n'
      printf '| Passed | %s |\n' "$PASSED"
      printf '| Failed | %s |\n' "$FAILED"
    } >> "$GITHUB_STEP_SUMMARY"

The status condition follows GitHub's recommendation for a step that should run after success or failure but not cancellation. [6] The earlier tests step must emit both outputs before it exits, including when tests fail.

Use a fixed template. The workflow decides which fields are public enough for the summary, checks their shape and length, and gives each value one intended location. A failure removes the current step's summary file before the step ends, which GitHub documents as the supported way to remove that step's pending summary. [1]

Shell safety and Markdown safety need separate checks

GitHub warns that pull-request titles, issue bodies, branch names, labels, and similar context fields can contain attacker-controlled text. [3] Putting an expression such as ${{ github.event.pull_request.title }} directly inside a run: script can turn that text into part of the temporary shell script before the runner executes it. [3]

GitHub's preferred inline-script pattern places untrusted expressions in intermediate environment variables. [2] That stops expression substitution from rewriting the shell program. [2] [3] Job summary output still renders as GitHub-flavored Markdown. [1] Apply a separate content review: validate a narrow format, encode the Markdown characters the summary permits, or omit the field.

Secret masking backs up the publishing allowlist

GitHub says job summaries automatically mask secrets that were added accidentally. [1] The broader secure-use reference says redaction is not guaranteed when secret values are transformed. [2] Runner redaction also depends on the job using the secret and the runner being able to access it. [2]

Register generated sensitive values with ::add-mask::VALUE before any command could print them. [1] GitHub specifically calls out transformed values, including Base64 or URL-encoded forms, as values that need their own registration. [2] Keep the summary allowlist anyway. Masking is useful when a mistake slips through; it is a weak approval criterion for content the workflow publishes on purpose.

Cleanup changes when the step finishes

Within the current step, > overwrites earlier summary content. [1] Deleting the file referenced by GITHUB_STEP_SUMMARY removes that step's pending summary. [1] After the step completes, GitHub uploads the summary. [1] Later steps cannot modify it. [1] A sensitive uploaded summary requires deletion of the entire workflow run. [1]

• Before the step ends: delete the summary file to remove the current step's pending summary. [1] Stop writing and fail the step if the publishing contract was violated.
• After upload: rotate any credential that may have appeared. [2] Have someone with repository write access cancel the workflow if it is still running. [8] Once the run has completed, that person can delete it. [7] Deleting the run removes its job summaries. [1]
• For oversized summaries: investigate the error annotation. [1] GitHub says the per-step upload fails above 1 MiB. [1] The failure does not change the step or job result. [1]

Review the summary as an explicit CI output

• Every dynamic field has a named owner and a narrow reason to appear.
• Inline scripts receive untrusted context values through environment variables. [2] Direct expression interpolation stays out. [2] [3] Actions receive those values as inputs. [2]
• Each dynamic value has an allowlist, type check, or encoding step before Markdown output.
• No command pipes a log file, complete context, payload, stack trace, or API response into the summary.
• Generated credentials are registered for masking before output or another workflow command could expose them. [1] They are never deliberately written to the summary.
• The workflow has a tested failure path that deletes the pending summary before the step exits. [1]
• Summary-size failures produce an error annotation. [1] They do not fail the job. [1]

Related reviews: GitHub Actions script injection, GITHUB_TOKEN permissions, and five GitHub Actions security risks.

CI Tripwire Editorial has not commissioned independent expert review of this article. Read more about the organization byline at contributors and the source posture at sourcing.

Corrections can be routed through the corrections note. Sources: 8 official GitHub primary-source entries, last reviewed 2026-08-11.